Deprecated: Joomla\Input\Input implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/vendor/joomla/input/src/Input.php on line 41

Deprecated: Return type of Joomla\Input\Input::count() should either be compatible with Countable::count(): int, or the #[\ReturnTypeWillChange] attribute should be used to temporarily suppress the notice in /homepages/13/d380392445/htdocs/Jlive/libraries/vendor/joomla/input/src/Input.php on line 170

Deprecated: Joomla\CMS\Input\Input implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Input/Input.php on line 31

Deprecated: Joomla\CMS\Input\Cookie implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Input/Cookie.php on line 21

Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Uri/Uri.php on line 141
Issue Tracker Guide :: New Progress Design Considerations

Deprecated: F0FInput implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/f0f/input/input.php on line 35

Deprecated: Joomla\CMS\Input\Files implements the Serializable interface, which is deprecated. Implement __serialize() and __unserialize() instead (or in addition, if support for old PHP versions is necessary) in /homepages/13/d380392445/htdocs/Jlive/libraries/src/Input/Files.php on line 21

New Progress Design Considerations

Issue Tracker release 1.6.0 introduced a change in the storage of issue progress records within the database. These records now have their own separate database table, which provides the ability to assign individual control over the records such as access groups and separate publishing state. This change has resulted in some changes to how the information is recorded and displayed to the users.

When creating an issue there will be no 'progress' information and hence there will be no area upon the input form or the issue display to show this information. When an issue is edited by the user who created the issue, they are presented with the 'additional information' area, which when the issue is saved is stored as a record within the progress table. If an issue administrator or staff member edits an issue, then a progress input area is displayed, along with options to specify the access group and publishing state of the progress record being entered. This record is then added as a new record in the progress table when the issue is saved.

When the user who created the issue performs an edit any previous 'progress' records will be displayed to them, providing the progress record are marked as published.

When the issue is displayed, then whether the progress information records are displayed will depend upon the component setting 'show progress record'. In addition the access group to which the viewer belongs, must match, and also the published state of the progress record has to be set.

Issue administrators (and staff members) will see all progress records and will also see the sequential line number of each progress record.

There are a number of options that control the display of progress records in the front end of the site. These are as follows:

  • The component option as to whether to display individual progress records in the front end.

    If the option is not set then issues viewed in the front end will not be visible to anyone other than issue administrators/staff.

  • Whether the progress record is marked as 'public' or 'private'.

    Private records are only visible to the raiser or creator of the issue (and progress) record and Issue administrators/staff.

  • The access group assigned to each progress record.

    In all cases the access group is checked to ensure the viewer is permitted to 'see' the record.

  • The published state of the progress record. i.e. 'published' or 'unpublished'.

    Generally unpublished items will only be visible to Issue administrators/staff and the issue creator.

  • The particular user viewing the information.

  • Whether an edit is being performed or whether this is a view only.

    When an issue is being edited, which is only possible in the front end by the issue creator and issue administrators/staff additional progress records may be visible if all of the other criteria are met.

All of the above criteria is used to determine whether a specific progress record is visible to the 'viewer'. As can be seen this can be quite complex and the following table attempts to show what may be visible is an easier manner.

Table 8.5. Table providing details of front end progress record display criteria.

User

Edit

View

Creator

Can see all progress records that have the same access group as the creator whether published or unpublished.

If it is desired that the creator does not see some progress records for whatever reason, then a different access group should be assigned to the specific progress record. i.e. This might be the case where a progress record is intended solely for other Issue administrators or staff members.

Can see progress records marked public and private.

The creator has to be logged in to be able to edit a issue.

Cannot edit previous progress records.

Can see all progress records that are published and which have an access group which matches that of the registered user, whether published or unpublished.

Requires the creator to be logged in, other wise as shown for the guest user below.

Can see progress records marked public or private.

Can see published and unpublished progress records.

Issue Administrator

Can see all progress records, provided Issue administrator has the appropriate access group assigned to them.

Cannot edit previous progress records.

Can see all progress records which have an access group that is one of those the issue administrator.

Does not check the publishing state or the privacy flag.

Issue Staff Members

Can see all progress records provided staff member has the appropriate access group assigned to them.

Cannot edit previous progress records.

Can see all progress records which have an access group that matches one of those of the staff member.

Does not check the publishing state or the privacy flag.

Public

No editing possible.

Views progress records if the component is configured to display progress information, and the progress record is published, has an access group of 'public' assigned.

Must also have the component configured to display progress information.

Cannot see progress records marked 'private'.

Logged in Registered User

No editing possible.

Can see all progress records that are published, marked as public and which have an access group which matches that of the registered user.

Must also have the component configured to display progress information.

Cannot see progress records marked 'private'.


This is correct as of release 1.6.0.

Go To Top

Joomla! Debug Console

Session

Profile Information

Memory Usage

Database Queries