Retrieve user logs to determine why error occurred when re-sending a employee contract
Within the system, for documents signed electronically through Self Service, users who have access to the checklist where the document was generated have the ability to resend the document to Self Service for signature again (after the initial signature has been attained).
Before resending the document, the user has the option of inputting a Reason for resending / additional instructions: (optional) which we found would throw an error if the contents of the text box exceeded 255 characters.
A hard stop has been coded into the text box. Now, users are forced to limit the contents of the Reason for resending / additional instructions: (optional) to under 255 characters as the system will not allow any further input beyond that. A warning has also been added to the bottom of the text box which says max 255 characters.
Note Details CSV report incorrectly displaying all notes as FALSE for 'sensitive',even if they are notes marked as 'sensitive'
Our Note Details CSV report has a column which is made to indicate whether or not a note is marked as sensitive or not (Sensitive: TRUE/FALSE)
A client advised us of an issue where the Note Details CSV report would indicate notes were not sensitive (Sensitive: FALSE) when they were actually sensitive which would mean that the report was giving incorrect information.
The report has been fixed and will now properly display any notes marked as sensitive as (Sensitive: TRUE)
Issue when adding 'Doc Type - Form' to Competencies
Where Training & Qualification Competencies are concerned, users of the system can upload documents against competencies to support the attainment of the item. When uploading a document, you can choose a document type for the document which helps mark the document for control of access permissions and reporting.
We were advised by a client that when uploading a document for a competency and choosing the document type "Form", the system would throw a Server Error message and say "Error: unable to complete the request (more information not available)."
We've fixed this issue and moving forward, the above error message will no longer appear when uploading a document as a part of a competency and where the document type: Form is selected.
Letterhead not attaching to document
We had an issue lodged by a client where even though a branch didn’t have a specified branch level letterhead, the system wasn’t going up to the account level to source the letterhead to use (which, we had expected it to).
Further investigation revealed that in this client's case, the branch in question did at one stage, have it’s own branch level letterhead which was removed.
And, where that happens, it broke the ability for the system to look further up to account level for a letterhead to use.
As a resolution for this issue, we have now added a flag on the Branding tab of each branch:
If ticked (TRUE), the branch is made to use any letterhead it’s parent uses. As an example, if a branch is two levels down, it will use the letterhead settings specified by it’s parent one level up. Continuing this example, a branch which is one level down (the parent in the previous example) will source it’s letterhead from it’s parent (the account, in this case).
In summary, if ticked, this setting makes the branch keep looking upwards along the chain until it finds a letterhead it can use (whether that’s on a parent hub somewhere above them or on the account)
If unticked (FALSE), the branch will always look to use whatever letterhead is defined at that level. If there isn’t a letterhead defined, no letterhead goes onto generated documents from the branch.
KRA Result Report Broken
An issue was lodged which advised us that the KRA Results Report was broken in a way where the resulting report wouldn't contain any results.
Further investigation revealed that the issue was with the KRA Group selection, in particular, the “Individually Assigned” group. We found that we couldn’t generate the report with any results when that group got was selected. This is the default grouping that KRAs are assigned get where they’ve been added to records one-by-one. Additionally, the KRA Group selection "All" wouldn’t work either (because it includes “Individually Assigned”)
(Global Messaging) Attach Documents option ignored "Branches Allowed"
This issue would affect any clients that use both the Self Service Messaging function and the Branch Restrictions on documents heavily. When sending a Self Service Message, you have the option to include (as an attachment) any document that’s uploaded to the system and is eSS visible (of a document type that is visible to eSS users).
The issue was that to the sender, when looking at the list of documents available, the system wouldn’t apply the branch restrictions meaning the sender could potentially see documents they didn’t have branch permissions to otherwise see.
As a fix to this issue, we’ve added branch permission checks to the Attach Documents page when sending an eSS message.
Moving forward, the Attach Documents page will apply branch permission checks and only show the user (the sender) documents that they have branch permission to see.
Please be aware: just because the user (sender) has access to see the document, doesn’t necessarily always mean the recipient has access to view the document. If the sender chooses a document that the recipients do not have branch access to see, the message will still contain the document attached but when the users who don't have access click on the document, it will likely display an error message that says "“We can’t display the page: /api/documents/documentUUID. This is most likely due to a problem at our end. If this persists, please contact Support”
To mitigate this issue, we have altered the message at the bottom of the Attach Documents page to say this:
Unable to Generate Hazard Note Detailed Report
We were advised of an issue involving the Note Details CSV report not generating for records such as hazards (the ones in the Legacy module).
Whenever the client would try to run this report on hazards, it would show a Server Error page and give a very specific error message.
Further investigation revealed that it was a because the Note Details CSV report has a section where it tries to get the record’s First Name to put into the report, which works for people based records such as Employees and Candidates but less so for records like Hazards or Incidents which don’t have that field.
We have since fixed the report and it will now run regardless of the record type.
Have more questions? Submit a request