Front End Issue Edit Screens

The screen that is displayed upon the front end for issue editing will depend upon the role of the person performing the edit. It an issue administrator is performing the edit they have access and the ability to edit ALL of the issue details. If the person editing the issue is the person who raised it in the first place as indicated by the ‘identified_by_person_id’ field within the issue record, they are presented with a slightly different screen display.

The specific issue shown is one that was raised internally whilst developing the feature and some of the text is just for example purposes.

The following figures illustrate the difference. In each case the same issue is being edited, first by an issue administrator, and the second by the person who raised the issue who is not an administrator. (For the example the issue administrator privilege was removed from the user to generate the second set of figures.

[Note]Note

The following information relates to releases prior to 1.6 of Issue Tracker.

If you look carefully at the issue description you will/may see several lines similar to the following:

username 2012-08-16 13:00:04: Test of checkin

The line represents the information of the user that performed the editing (which is always expected to be the user who identified the issue), followed by the date and time when the additional information was received, and finally the information provided. The fact that there are several lines just indicates that several updates have been performed by the raiser upon the issue.

These lines may be present also in the progress history record, only in this situation the entries would have been created by a version of Issue Tracker prior to release 1.6, and they would have been placed in the progress history when the component was upgraded.

In release 1.6 and later any additional information entered by the user who opened the issue is added to the progress history information. This additional information may or may not be displayed in the front end depending upon the settings upon the additional information progress record.

[Note]Note

Any edits performed by the issue administrator are written directly to which ever field is updated. The assumption is that the issue administrator will retain any information that is relevant. Adding information into the progress field adds the entered details into the 'progress history'.

The raiser of the issue has only a restricted set of things that they can change or add and these are detailed in section Front Editing Permissions.

You will also observe that there is an ‘Image’ button’ just below the editor. This is to enable the insertion of images into the editor text fields. This feature is a ‘stop gap’ measure until such time as the attachments feature is implemented permitting the association of files of any time with an issue. See the notes section more information.

NOTES:

  • The ACL permission to ‘EDIT - OWN’ has to have been granted to the registered users to enable them to edit issues in the front end. Each site may be different so it is worth checking if your users are experiencing difficulties.

  • The ACL permissions may not have been set if the issue was created in a pre- 1.2.0 release of Issue Tracker, and it will be necessary to edit (in the back end by an issue administrator) any pre-existing issues which may be required to be edited in the front end. See section ACL Permissions for more details.

  • There are a number of editor available for installation upon a site, and include the installed default Tiny. MCE, and Code Mirror, but also JCE and JCK etc. We have shown JCE as the editor in the figures since that is our own editor of choice but you are not restricted. We are not that familiar with the other editors so can assist in their configuration. In particular we found difficulties in getting JCK in use as a front screen editor, whether this is a problem with our particular template or some other reason we do not know. There are numerous reports on the web about problems with all editors so it seems we are probably not alone.

Figure 4.59. Front End Issue Edit - Administrator (Part 1)

Front End Issue Edit - Administrator (Part 1)

Figure 4.60. Front End Issue Edit - Administrator (Part 2)

Front End Issue Edit - Administrator (Part 2)

Figure 4.61. Front End Issue Edit - Administrator (Part 3)

Front End Issue Edit - Administrator (Part 3)

If the person editing the issue is the person who raised it in the first place as indicated by the ‘identified_by_person_id’ field within the issue record, they are presented with a slightly different screen display.

Figure 4.62. Front End Issue Edit - Raiser (Part 1)

Front End Issue Edit - Raiser (Part 1)

Figure 4.63. Front End Issue Edit - Raiser (Part 2)

Front End Issue Edit - Raiser (Part 2)

[Note]Note

Release 1.2.1 modified the Front end edit screen layout for registered users entering additional information. The reason for this was to ensure that the form displayed the same upon both Chrome and Firefox browsers. This is not shown in the figures above.

Issue administrators and staff members are presented with the ability to access and update most of the fields associated with an issue. One nice feature introduced in 1.6.7 was that when an identifying user is chosen/changed from the drop down list a check is made that the chosen individual is configured to receive notifications. If they are not then a message id presented and also a button that can be clicked to update the users notification flags to the system defined default.

Depending upon the configuration there may or may not be a section displaying the issue progress history. Likewise there may or may not be a section for the entry/edit of custom fields.