The update of the progress history is intended to make it more logical to view the actions performed upon an issue in a chronological order. This is achieved but having a single 'progress' table in which is stored the progress records for all issues. Each record in the table relates to one specific activity performed. Each record will obviously possess a unique identifier but also an incrementing counter for each issue.
The records are shown as a separate panel in the issue display (front end and back end) in a tabular format similar to that already present for issue attachments.
The intent is that only the 'Issue administrators' will be able to edit 'old' progress records, and a link will be provided upon each progress record for the issue administrator to click upon to edit the record. After editing the record the intent is to return to the issue display itself. This may change in later revisions subject to experience.
Each progress record has controls upon who can view that specific record. The 'access' field will enable only users within the assigned group to view the specific record. This will enable 'issue administrators' or 'staff' members to be able add 'private notes' to an issue recorded in the progress history, in this way avoiding the need to implement a separate 'notes' feature.
This also changes the former storing of 'additional' information entered into an issue by the raiser on the front end such that this is also entered and stored as a 'progress' record, instead of as formerly being appended to the end of the issue description.
An additional feature to add details of emails sent to a progress record is also under consideration and may be implemented in a later release.
For simplicity the existing front end form where one enters new progress information is retained, and upon saving the data stored in the new progress table.
There is no facility (or currently any need?) to edit previous progress records from the front end. They can be edited in the back end. Changing (or deleting) of a progress record does not cause the sending of an update notification email.
When an issue is trashed the individual progress records are not impacted, and it is only when the issue record is 'deleted' (i.e. the trash is 'emptied') that the progress records are deleted. The progress records can be edited by an issue administrator (in the back end), and the published state and access modified as required. These fields can also be specified when a progress record is created, with the defaults being that the progress record is unpublished and the access set to 'registered' users.
An individual progress record can have its own 'access control group', an individual published state, and also an individual privacy setting. This enables the site to use the progress records in any way they deem suitable. So for example a site might use the progress access control group setting such that the issue identifier never sees certain progress records, which are not in their assigned access groups. In this way internal update actions might be available to different support staff associated with an issue and only viewable by those support staff.
Use of the individual 'privacy' setting would enable only the issue identifier to 'see' progress records marked as private, so in the event of an issue being published the general public would not see these 'private' marked progress records, even if the progress record itself is 'published'.
Release 1.6.4 introduced a change in the email sending of progress records such that only the 'last' progress record is attached to a 'user update' email. If the last progress record is not within the users assigned groups then no update email would be generated.
With the design of the partitions table and its implementation into the component it was decided to create a hidden view in the back end of the component. As is common with Joomla views back end displays are generally of a form where there is a 'list' of items and then individual 'item' displays accessed from the 'list' display. Progress records do not quite fall into this 'category'. This is because any given Issue record may have many different progress records associated with it. These 'historic progress records' are displayed as a small grid as part of the Issue detail display. These 'small progress grid records' can be edited in the back end, but no mechanism is given for removing the records individually. This is mainly by design, with the reason being that each progress record builds up the 'historic knowledge base' of information about issues/problems encountered and it is not (usually) desirable to lose such information. If the Issue record is deleted then all associated progress records (along with all attached files) are automatically removed at the same time.
We recognised that occasionally it may be desirable to remove some possibly contentious progress records, and that is why we created the additional list display available in the back end of the site. This 'list' display is of all of the progress records. It provides a sortable and filterable list of every entered progress record together with the ability to edit them, delete them, publish/unpublish, etc. All of the classic tasks are familiar to the existing 'list' displays. Since this is a display that is not likely to be required very often (if at all) there is no immediate link to the display. Instead it is necessary to enter the URL directly in the browser address bar. The name of the view is 'pactions' (progress actions). It is a fully functioning view as explained above.
One benefit of the view is that it allows a quick and easy way to view progress records and if necessary edit them to correct layout or grammatical errors in the text.