Release 1.2 introduced the ability to edit existing issues in the front end of the site. Certain criteria have been applied to control who and what can be edited.
There are a few settings that need to be applied before an issue can be edited on the front end.
-
The component must have the ‘edit Own’ ACL permission assigned.
-
The issue to be edited must have the correct ACL permission. See ACL permissions in the next section.
-
There is a component option to prevent front end issue editing if it is not required upon a site, which must be enabled.
-
The issue to be edited has to have been ‘identified by’ the specific user before it can be edited unless the person performing the edit is an issue administrator. (setting in the people table.)
-
Ensure that the use of the editor is permitted within your chosen edit and assigned to the ‘Registered’ group, to whom all issue tracker users are assigned. Failure to do this may result in the presentation of a blank data entry box with no editor toolbars etc.
The editor used will depend upon the site default and the setting for the user in their own profile. We are familiar with the JCE editor and all of our testing has been performed using this WYSIWYG editor. Other editors are available but we cannot necessarily assist with editor problems. We discovered a few editor problems in our testing, which are not related to the Issue Tracker component itself. For that reason there is an option setting to provide a simple text area for input of details, until such time as any WYSIWYG editor problems have been resolved on your site.
An issue is edited by clicking on the ‘edit’ icon on the issue display.
Note | |
---|---|
If an issue is unpublished the icon is slightly different. |
Unpublished issues are displayed upon the Menu items created with the ‘Show own issues’ option.] If front end editing is disabled then the icon will not be shown either for issue administrators OR for registered users.
An issue administrator can edit any issue and is presented with all of the same editing capabilities as in the back end of the site. The administrator can create and close an issue in one complete step, an ability that is not possible with any other user.
A registered (and logged in) user can edit their own raised issues only. The registered user can add additional information to the issue description, thus providing updates, but this is achieved by completing the ‘additional details’ panel, NOT by editing the issue description directly. Upon user save the issue description is updated.
Guest users cannot edit existing issues.
The following criteria are used to define the possible field entry or display in the front end issue screen.
Table 8.4. Table providing details of issue editing abilities per user group.
Ability |
Create |
Editing |
|||
---|---|---|---|---|---|
Administrator |
Staff |
User |
Guest |
||
Change Issue title (summary) Field |
Y |
Y |
Y |
N |
N |
Change issue description details |
Y |
Y6 |
Y6 |
N6 |
N6 |
Complete Additional Details Field3 |
N |
N |
N |
Y |
N |
Change Identified by |
N1 |
Y |
Y |
N1 |
N1 |
Change Issue Type |
Y |
Y |
Y |
Y |
N |
Change Issue Status |
N |
Y |
Y |
Y2 |
N2 |
Change progress details |
N |
Y6 |
Y6 |
N |
N |
Change actual resolution date |
N |
Y |
Y |
N |
N |
Change resolution summary |
N |
Y6 |
Y6 |
N |
N |
Change Identification date |
Y |
Y |
Y |
N |
N |
Change project |
Y |
Y |
Y |
Y |
N |
Change user notification |
Y |
Y |
Y |
Y |
N |
Change published field |
Y |
Y |
Y |
N |
N |
Change issue priority |
N |
Y |
Y |
N |
N |
Change target resolution date |
N |
Y |
Y |
N |
N |
Delete Issue9 |
N |
Y |
N |
N |
N |
Reopen Closed Issues9 |
N |
Y |
N10 |
N10 |
N |
Audit fields4 |
N |
N |
N |
N |
N |
Captcha challenge5 |
Y |
N |
N |
N |
N |
User Details5 |
Y |
N |
N |
N |
N |
User Email5 |
Y |
N |
N |
N |
N |
User Website5 |
Y |
N |
N |
N |
N |
Notes:
-
The identified by field is automatically entered as being the user who is creating and/or editing tee issue. Only the administrator can change the field.
-
The Issue Status can be changed by the user within certain criteria, such as being able to close (and possible re-open) and issue. All other status changes are only performed by an administrator. Note - not yet implemented.
-
The additional details field is only displayed for users editing their own raised issues. It is not displayed for an administrator who would update the appropriate table field directly.
-
Audit fields are not displayed and are therefore not editable in the front end.
-
Details of the entering user and the captcha challenge are only required for a new issue creation where the user has not identified themselves by logging onto the site. Updating of theses details is expected through the additional info field if the user updates the record. Captcha details are not currently presented for registered users. (This is a possible future enhancement.)
-
The choice of editor to be used for users and the administrator is configured within the standard Joomla users profile. Non registered users are not presented with the choice and are presented with a simple text editor.
-
The front end editing allows for the ‘checkin/checkout’ functionality already implemented in the back end. This means that the issues list display will show a padlock icon next to the issues being edited in the front end. Once the front end edit is completed, either by the saving or the cancelling out from the editor, the padlock would be removed from the back end issue list display against the specific issue id.
-
The ACL permissions applicable to the specific issue being edited are applied. See section ACL Permissions for more details.
-
Version 1.3.3 and above only.
-
Version 1.3.3 component option.
Release 1.3.0 introduces the attachments feature which permits user (if configured) to upload files and images which can be associated with specific issues. Release 1.2.0 allows ‘images’ to be inserted into issue description, progress and resolution field using the features of most WYSIWYG editors. All three can be updated by issue administrators, where as only the issue description can be used by registered users. This feature is retained as an alternative mechanism for those who do not wish to enable the attachments feature.
Most WYSIWYG editors implement image inclusion using the ‘Joomla Media Manager’. Depending upon the specific editors installed upon a site, will determine the control of the placement of the ‘uploaded’ images on the site. For example the JCE editor only offers limited placement, where as the CK editor is a lot more configurable.
This specific capability will be modified in later releases.
To disable the loading of images it is necessary to modify the form XML file in the front end and configure the editor on the site to prevent image upload. See your specific editor documentation for details.