Restrict user access to the Edit button
We noticed an issue where readOnly custom fields still showed the Edit button. This would only affect clients who have requested customised fields where certain users are denied access from editting the information in the fields. The fields would still display as in-editable once the user went into edit mode which eliminated any risk of users altering data they shouldn't be allowed to but the fact that the Edit button was available to be clicked on would give the wrong impression to certain users.
The issue has now been fixed.
If you a group of custom fields are all readOnly to the user, the Edit button will not appear:
If within a group of custom fields, there is even one field that the user has permission to edit, the Edit button will appear. Once in Edit Mode, the user will still only be able to edit any fields they have permission to edit.
[All Accounts] "Merged" records aren't Read Only
Where records are Merged, the "archived" (old) record was not made readOnly which meant that after the merge, users had the potential of still updating the data in the old record.
Moving forward, similar to Transferred and Converted records, Merged records are now readOnly.
[JCDecaux] Global Messaging not respecting Selected Branches function
When sending Self Service Messages, users are allowed to select specific branches for the message to be applicable to. Unfortunately, we had an issue where messages would appear in branches even if the branch was not explicitly selected during the drafting of the message. This issue would occur where the parent branch was selected but the children branches may not be explicitly selected. In this scenario, because the parent branch was selected, the system almost assumes that the message would also be applicable to the children as well which is not always the case.
Moving forward, when selecting a branch during the drafting of the message,
[VetPartners] "Return to Checklist" button for recordlink checklist item types
This was an improvement suggestion raised by our client, VetPartners Australia Pty ltd. As a part of our Online Performance Review (OPR) checklist, one of the steps tells the user to View the Employee Profile and provides a button that redirects them to the Details page of the employee undergoing the process. The client suggested a Good-To-Have functionality to allow users to be re-directed to the original checklist in one click.
The Return to original Checklist button has been added to the system where the View the Employee Profile type steps are involved. There will now be a button at the top and bottom of the screen which will re-direct the user back to the checklist they were performing previously.
Additionally, these buttons have also been added to the following checklist step types:
Remove extra PDF file extension
This was a cosmetic issue but was impacting all accounts system-wide where we noticed that whenever documents generated via our templates were signed as a part of using our checklists, the system would automatically add the file extension (.pdf) to the name of the document. The problem was that upon generation, the document would already have the file extension in the name. This resulted in documents generated from our system being renamed "Employment Agreement - Casual - Award Covered for Employee Name.pdf.pdf” which did not have a detrimental on the usability of the document (it was still visible and still had the signature captured as expected) but did look a bit silly.
We have fixed this issue so that the system will no longer add the extra (.pdf) to any documents signed using our eSignature capability.
Automatically expiring candidates admin config leaves candidates with 2 conflicting statuses
As a result of our functionality to "expire" (make Not Current) candidate records which have been active for a certain length of time, it was brought to our attention that certain candidates had the ability to be given conflicting statuses (where it would say "Not Current - Current", "Not Current - Converted" or "Not Current - Unsuccessful" in the case of candidates)
Moving forward, where the record's Status is concerned, the field will only ever show one status (whether that be Current, Not Current, Terminated/Terminating, Suspended, Converted, Transferred, Merged or otherwise)
Closed Hazards does not show graphs in the WHS Dashboard
There was an issue raised by our client, Australian Nursing Home Foundation with regards to the WHS Dashboard for the WHS (Legacy) module not displaying "Closed" (Not Current) hazard records. This was an issue only affecting the usage of the WHS (Legacy) module and not the Work, Health and Safety (Updated) Module. Functionality of the reporting dashboard remained working for clients utilising the updated module.
Some maintenance had to be performed on the code behind how the "Closure Date" is recorded for hazard records in the WHS (Legacy) module. Moving forward, the issue is now fixed and the dashboard report for the WHS (Legacy) module will now display "Closed" (Not Current) hazard records. Additionally, the maintenance of existing records will mean that historical records which were "Closed" will now appear on the report as well.
Have more questions? Submit a request