| Field/Security permission key | Purpose | ||||||||||
| ATTACHMENT | This key controls the overall ability to create attachments. Write permission to this key is needed by the user role, for attachments to be able to be created or maintained. If there is no read permission, the attachment layout is not visible. This field is the only field that should be placed on reports where you want to display attachments, such as the detailed report. The remaining fields for the attachment will be placed onto the report by ExtraView, according to whether the field has read permission. When you have read permission to attachments on reports, a View attachment button is automatically placed on the report, allowing you to view the contents of all attachments to an issue directly. | ||||||||||
| ATTACHMENT_ADD | This controls the Add button for attachments. Write access is needed to control this | ||||||||||
| ATTACHMENT_DELETE | This is to enable and disable the delete attachment button | ||||||||||
| ATTACHMENT_EDIT | Controls whether a user role may edit the attachment description of a previously uploaded attachment. Write permission is needed for this | ||||||||||
| ATTACHMENT_HIST | Controls the presence of a History button on the edit screen within the attachment. This button presents a window with a layout defined in the layout editor and named ATTACHMENT_HISTORY, which presents the historic records showing the updates and accesses to attachments. Normally, this layout is defined in the global area, and inherited by all business areas and projects. | ||||||||||
| ATTACHMENT_VIEW | Controls whether a user role may view a previously uploaded attachment. Read or write permission is needed for this | ||||||||||
| ATTACHMENT_SAVE |
Ths button invokes the browser's ability to download and save an attachment, as opposed to viewing the attachment with the ATTACHMENT_VIEW button. Note that this button behaves differently within different browsers:
|
||||||||||
| ATTACHMENT_ID | This is an internal ID used by ExtraView. It is not likely that you will give permission to this key for any user role. | ||||||||||
| ATTACH_CONTENT_TYPE | This is the mime content type of the attachment. You can control the visibility of this key with read permission. You cannot write to this field. | ||||||||||
| ATTACH_CREATED_BY_USER | This is the name of the user who created the attachment. Once again, you cannot write to this field, and its presence or absence is controlled with the read flag. | ||||||||||
| ATTACH_DATE_CREATED | This is the date that the attachment was created. Once again, you cannot write to this field, and its presence or absence is controlled with the read flag. | ||||||||||
| ATTACH_FILE_DESC | This is the description of the attachment that the user enters. Both write and read operations are allowable on this field. | ||||||||||
| ATTACH_FILE_NAME | This is the name of the file that is attached to the issue. Once again, you cannot write to this field, and its presence or absence is controlled with the read flag. | ||||||||||
| ATTACH_FILE_SIZE | This is the size, in bytes, of the attachment. Once again, you cannot write to this field, and its presence or absence is controlled with the read flag. | ||||||||||
| ATTACH_PATH | This is the path in which the file was originally stored on the local file system of the creator’s computer. Once again, you cannot write to this field, and its presence or absence is controlled with the read flag. | ||||||||||
| ATTACH_THUMBNAIL | This previews the attachments of image types (JPG, PNG and GIF) at a small size, in order that the user may see the image while they are inserting and updating issues, as well as seeing the field on reports when they are looking at attachment records. |
There is a default layout in the Global Area, Master Project that defines the layout for file attachments. This layout is named ATTACHMENT_SECTION. This may be embedded within any add or edit layout. Before any alterations, this looks like the following:
The security permission keys PR_ADD_PROBLEM.ATTACHMENT and PR_RESOLUTION.ATTACHMENT control the overall visibility of the layout, and the following security permissions control the ability to place attachments from within the add and edit screen layouts. Security permission entries exist for both the PR_ADD_PROBLEM set of keys and the PR_RESOLUTION set of keys, except for ATTACHMENT_DELETE, ATTACHMENT_EDIT, ATTACHMENT_HIST, and ATTACHMENT_VIEW which only exist for the PR_RESOLUTION set of keys.
If you are configuring mobile layouts, consider saving the ATTACHMENT_SECTION layout as a mobile layout and removing fields which are going to clutter up small screens, especially on phone targets. You can configure the fields on the layout vertically as opposed to horizontally, similar to this:
Multiple attachments can be added to issues, on both the add screen and the edit screen, if the user role has permission. However, attachments cannot be deleted from the add issue screen. If the user incorrectly adds an attachment during the add issue process, they should continue, add the issue to the database, edit the issue and then delete the attachment. Note that if an attachment is added to an issue when you are updating an issue, the issue itself is immediately updated.
Portion of edit screen showing attachments
Portion of detailed report showing attachments
A behavior setting named THUMBNAIL_MAX_SIZE controls the size of the thumbnail. This is the maximum number of pixels in either the horizontal or vertical direction to which thumbnail images will be generated. The aspect ratio of the original image will be retained. Thumbnail images are generated for file attachments and for fields with a display type of image. If you change this value, existing thumbnail images will remain at their original size and new thumbnails will be generated at the changed value.
You should not embed the ATTACHMENT_SECTION layout within Detailed Report layouts. Instead, there is a field with special properties, named ATTACHMENT. This field should be placed on the Detailed Report layout. You then can control the presence or absence of the individual fields that comprise the attachment information with their security permission key. This leads to a layout for detailed reports that looks similar to this:
