Features

The following is a full list of features that were implemented in PTW v1.7.4.0_1.7.4.4 release.

 1.1.1.Site Column added to the Permit List Screen

A new "Site" column has been introduced, allowing for easier identification and organisation of permits by location. In addition, we have streamlined the "Sign Out" sections by merging them into a single column. This new layout displays the pertinent details stacked vertically, similar to the existing "Created" column, for improved readability. To optimise the overall layout and ensure everything fits neatly, we have also made a slight reduction in the font size.

 1.1.2.Handed Back Late Feedback when a Permit is handed back

We have created a setting to disable the "Why is this handed back late?" textbox when handing back a permit after the expiry period.

We added a new toggle under the Permit Version Handback section for:

• Show 'Why is this Handed Back Late' Textbox

Just as originally happened before the setting was introduced, when enabled, the textbox appears on the Hand back screen on a Permit which is handed back late.

When this setting is turned off, the textbox will not be shown on the Hand back screen, regardless of whether it has been handed back late or not.

 1.1.3.Risk Assessment History & Revisions

The following changes have been made in relation to the History and Revisions of a Risk Assessment:

History

• A new button labelled "History" has been added to the RA Edit screen.
  • Clicking this opens the same screen as "Admin -> Pisys Only Items -> Audit", but defaults to show only the records for the current RA.
  • The screen header has been updated to show the RA Reference Number (and Revision No, if not the original RA).
• An attempt has been made to streamline what is added to the audit for RA changes to try to minimise duplication or needless information.

Revisions

• Updated with the following functionality to allow manual locking/unlocking of RAs
  • New button added at the top-right of the Edit page alongside the existing Revision-select dropdown, "Create Revision" button, etc.
  • Depending on the current state of the RA, this will be labelled as follows:
    • RA Unlocked -> Button label = "Lock RA"
    • RA Locked -> Button label = "Unlock RA"
  • Clicking the button regardless of the label will toggle the RA to the opposite locked state
  • The button only displays under the following conditions:
    • User can edit RAs.
    • The RA either has no Revisions or it is the latest Revision.
    • The RA NOT connected to any Permits which have progressed beyond Created.
    • EITHER there is no existing connected Permit OR there is at least 1 Permit BUT editing connected Permits is allowed.
    • NOT a NEW RA.
  • This means that with this addition of manual-locking, the original connected-Permit logic is still in place
    • The User will therefore not be able to toggle the locked state of an RA which is linked to a Permit which has progressed beyond created, i.e. it must remain locked.
  • When an RA is locked, the fields become non-editable, and the "Create Revision" button is available to Users with the appropriate Rights.

 1.1.4.Risk Assessment Screen Selection Changes

The existing methods of navigating from the main RA Edit screen to the various child selection screens have the potential to cause confusion in knowing which element you're adding items against within the hierarchy of a Risk Assessment. We have decided that having everything accessible from the main RA Edit screen makes sense and will allow the User to know what they're looking at in the context of the overall RA, as well as provide a quick method of configuring Risk Assessments without needing to navigate through multiple pages.

The main focus behind these changes are:

• Guide the User logically through the steps of creating Job Steps and their associated Hazards and Risk-Elements
• Avoid the need for drilling-down through screens to get to where the User needs
• Provide a method of keeping individual RA and Admin-Lookup data in-line with one another

Dialogs

• A major change in how the Edit screen works is that, instead of clicking a 'Select/Add' button and being taken to a new screen, that button-click now opens a dialog
• Although there are minor differences depending on the Item-Type associated with the dialog (e.g. Job Step, Hazard, Control Measure, etc.), the following core functionality is shared:
  • Default List
    • When initially opening, the full list of records for the Item-Type will be listed
  • Existing Selections
    • Any items already assigned to the parent (e.g. Job-Steps against the RA, Hazards against a Job-Step, etc.) will be shown in italics and say "Added"
  • Select/Deselect buttons
    • For any non-"Added" items, a button labelled "Select" is provided
    • Upon clicking this:
      • The row is highlighted in green, signifying that it will be added upon Confirming the selections
      • The button label changes to "Deselect", to allow toggling on/off whether the item is to be included
  • Wildcard Searching
    • The Texbox at the top of the dialog allows the User to filter the list of results to those containing whatever text is input
    • The results refresh upon each keypress with the corresponding data
    • Any selections made using the "Select" buttons prior to searching will remain in the results list regardless of whether they match the search-text
  • Create New
    • When clicked, this opens a further dialog window with a single textbox allowing input of the Description of any new item which is to be added
    • As is the case when adding an item via the corresponding Admin screen, the appropriate validation is carried out before the new item is created i.e.
      • Input cannot be blank
      • Description cannot be a duplicate
    • If there are any issues, the error message is displayed below the textbox to inform the User
    • Whether clicking "Save" or "Save & Add Another", the new item is automatically flagged as "Selected" in the list ready for the User to click Confirm
  • Confirm
    • Clicking the "Confirm" button proceeds to add the selections to the parent
    • After this has been done, the screen is refreshed to reflect the changes
    • The screen also focuses on the Parent item to which the new selections were added i.e.
      • When adding Job Steps to a RA, this is a simple refresh of the RA Edit screen
      • When adding Hazards to a Job Step, the Job Step appears expanded and scrolled into view
      • When adding Risk-Elements to a Hazards, the Hazards appears expanded and scrolled into view

RA Edit

• The following minor formatting changes have been made to the Edit screen:
  • Alternating light/dark Job Step row colours now all display as 'dark'
    • This (hopefully!) gives a better visual indication that all Job Steps are 1 colour and within them the Hazards are contrasted with white rows
  • Hazard-Heading Column-Titles have been shortened in order to prevent those Header-rows displaying as double the size of the Job-Steps Header and therefore drawing the Users focus:
    • Who/What is At-Risk -> At-Risk
    • Hazard Effects -> Effects
    • Control Measures -> Controls
  • Hazard child Risk-Element items now displayed as alternating light/dark rows within their respective 'boxes' instead of the original bullet-point lists
    • The font-size in the box-headers have also been reduced to be less than the Hazard-Heading
  • The original 'bin' delete-icons have been replaced with 'X' icons
    • This hopefully gives the User an indication that they are removing something from being assigned to a RA, as opposed to it being deleted from the system

Job Steps

• The following buttons have been removed:
  • Add Custom Job Step
  • Select Job Steps
  • 'Open Job Step' i.e. folder-icon
• A new button has been added labelled "Add Job Steps"
  • This opens a Dialog with the core functionality described above
• A new 'Edit' icon-button has been added per Job Step row
  • This opens a basic, single-textbox, Edit dialog allowing the editing Job Step Description
  • The following basic validation checks are applied:
    • Input cannot be blank
    • Description cannot be a duplicate

Hazards

• The following button has been removed:
  • 'Open Hazard' i.e. folder-icon
• A new button has been added labelled "Add Hazards" against each Job Step row
  • This opens a Dialog with the core functionality described above, but with the following differences
    • Hazard Category
      • Dropdown provided to allow filtering by a specific Category
      • Column displayed showing the Category for each Hazard
    • Create New
      • This is the standard 'Create New' functionality described above, but contains an additional dropdown allowing selection of the Category
      • A "Create Category" button is also provided to allow adding of any new Category which doesn't currently exist in the system
        • This is a standard 'Create New' dialog, but without the "Save & Add Another" button
        • The only other difference with this dialog is that, when clicking "Save", instead of the new item being flagged as "Selected" on the list, it is set as the Category dropdown selection on the "Create Hazard" dialog
• A new 'Edit' icon-button has been added per Hazard row
  • This opens a basic, single-textbox, Edit dialog allowing the editing Hazard Description
  • The following basic validation checks are applied:
    • Input cannot be blank
    • Description cannot be a duplicate within a Hazard Category
• A new 'Define Risk Scores' icon-button has been added per Hazard row
  • This takes the User to a slightly reformatted version of the original "Hazard Edit" screen with the following differences:
    • Heading relabelled as "Define Risk Scores"
    • Inputs for "Description" and "Hazard Category" replaced with a single, read-only textbox showing the concatenated Category and Hazard
    • Child 'Risk-Elements' tabs (originally allowing selection/removal of items) replaced with read-only versions of the same 'boxes' displayed on the main RA Edit screen
    • The 2 "Return" buttons (i.e. 'to Job Step' and 'to RA') have been replaced with a single button
      • This takes the User back to the RA Edit screen, showing the Hazard expanded and scrolled into view
  • Therefore, instead of the screen allowing full changes to be made to the Hazard, it now only allows selection of "Initial" and "Residual" Risks in order to keep things simple

Risk-Elements

• A new "Add" button has been included in each of the 'box' headers
  • This opens a Dialog with the core functionality described above
• Each row within a 'box' has an 'X' icon, allowing it to be removed

Admin -> Settings & Access Rights -> Risk Assessment Settings

• A new setting has been added for "Changes made within Risk Assessments Auto-Update Admin-Lookup data"
• When selected, any of the following actions performed in a RA will be reflected in the linked Admin item:
  • Job Step
    • Description changed
    • Hazards Added
    • Hazards Removed
  • Hazard
    • Description changed
    • Risk-Elements Added
    • Risk-Elements Removed
• Any changes made in the RA which affect the associated Admin item are recorded in the Audit, keeping track of who made what change and when.

 1.1.5.Risk Assessment Edit Screen UI Changes

To provide some flexibility in how RA Edit displays Hazards and their associated child Risk-Elements, we will introduce a slightly modified 'in-line' layout.

The main difference will be that, instead of having to expand each Hazard, the child Risk-Elements sub-lists will be displayed as columns in the Hazard row, with the columns reordered into a logical sequence.

RA Edit

• Add a new button alongside existing 'Expand' Job-Step/Hazard buttons, labelled "Show ??? View"
• The "???" text is replaced with one of the following, depending on the current 'View':
  • Summary
  • Table
• Clicking the button refreshes the screen to show to Hazards in the opposite view to what is currently displayed
• When switching view, the Job Steps are automatically expanded, with the screen focussing/scrolling to the first Job Step

Settings & Access Rights -> Risk Assessment Settings

• Added a new setting labelled "Default Hazard-Display to Table-View Format"
• If selected, when opening the RA Edit screen, the Hazards within each Job Step are displayed in the in-line, table format (as opposed to the original, expandable 'Summary' format)

Admin -> Matrix Edit

• Add a new toggle labelled "Display Header-Text As Score" with the following supporting text:
  • Display the selected X & Y-Axis Header-Text under Hazard 'Score' columns on Risk Assessments using this Matrix
• NOTE: We can reword the title and text to something else, just thought I'd get something down for now attempting to describe what the setting does

RA Edit

• If "Display Header-Text As Score" has been selected against a Matrix, then instead of the original Cell-Text (e.g. numeric score) being displayed in the coloured 'Initial' and 'Residual' Risk cells, this is replaced with the corresponding X & Y axis row/column header information
  • Another way to look at it is that the Cell contents and tooltip have been swapped, with the tooltip slightly reformatted to have less line-breaks
• If the setting is enabled, the width of the 'Initial' and 'Residual' Risk cells is increased slightly in the "Summary" view to try to accommodate the potentially longer lines of text

Print Layout

• The "Summary" print format has been updated to follow a similar format as the onscreen version i.e. columns added for 'At-Risk' and 'Effects'
  • Instead of the onscreen shaded-row format, the print uses bullet-points as per original
• The "Detailed" print has also been updated so that the child Risk-Elements also display in the bullet-point format

Job Step Date

• While checking the various RA Admin settings, I'd forgotten to take the "Display Job-Step Date" option into consideration when moving away from the original "Job Step Edit" screen i.e. we now use a dialog to allow editing the Job Step Description
• Have therefore now added similar functionality for the Job-Step Date to allow it to be set via a dialog
• When "Display Job-Step Date" is enabled, an additional 'calendar' icon is displayed alongside the 'edit' icon
• Clicking this then works in the same way as Edit Description, except the provided input is a date-picker
• Checks are made for blank data or an invalid date, and the User is warned if there is an issue.

 1.1.6.Conditional Questions Enhancements

We have made enhancements to our conditional questioning functionality within PTW to offer a more tailored experience for parent questions. Now, when the parent question is answered in a specific way, the follow-up questions they encounter will vary based on the response. For example, if the parent question is answered "YES" to the initial question, a targeted set of follow-up questions designed to gather further relevant information will be presented. On the other hand, if the parent question is answered with a "NO," an alternative set of questions will be displayed, focusing on different aspects pertinent to the response. This approach not only streamlines the process but also ensures that the questions are more relevant and specific to the situation.

PARENT

• Question Edit -> Parent Question
  • The "Config" button now only displays when there are NO Child-Questions with individual Visibility / Required conditions defined
  • Alongside the checkbox/button, the supporting text will display one of the following:
    • When NO conditions have been applied at either Parent or Child-level:
      • Define Visibility / Required conditions for ALL Child-Questions under THIS Parent-Question
    • When conditions have been applied at Parent-level:
      • CHILDREN are VISIBLE & REQUIRED when < Parent Question > is set to { "Yes" }
    • When conditions have been applied at Child-level:
      • This Parent-Question has at least 1 Child-Question with defined Visibility / Required conditions. Please therefore define any further conditions against each individual Child-Question.
• Config screen
  • Added a checkbox labelled "Apply Logic to ALL Child Questions" with supporting text:
    • Setting "Apply Logic to ALL Child Questions":
    • Set ON if ALL Child-Questions should follow the SAME Visibility / Required conditions defined on this screen
    • Set OFF if EACH Child-Question has DIFFERENT Visibility / Required conditions based on the Parent value

CHILD

• Question Edit -> Child Question
  • Similar to the existing "Parent Question" row, one has now been added for "Child Question"
  • This is only visible if the Question is a Child-Question, with the checkbox always being read-only
  • The "Config" button only displays when Parent-Question does not have Visibility / Required conditions defined
  • Alongside the checkbox/button, the supporting text will display one of the following:
    • When NO conditions have been applied at either Parent or Child-level:
      • Define Visibility / Required conditions for THIS specific Child-Question based on its Parent's value
    • When conditions have been applied at either Parent or Child-level:
      • < Child Question > is VISIBLE when < Parent Question > is set to { "Yes" }
• Config screen
  • New screen added allowing definition of Visibility / Required conditions for the individual Child-Question based on the Parent-Question responses.

 1.1.7.Isolation Workflow Enhancements

Isolations, much like permits, adhere to their own distinct workflows. In recognition of this, we have made significant updates to enhance the isolation workflow. These improvements now enable users to be specifically selected for approvals or requests at various stages of the isolation process. This ensures a more streamlined and efficient progression through the workflow, allowing for better accountability and clarity in the approval process. By incorporating user selection, we aim to facilitate communication and collaboration among team members involved in isolation tasks, ultimately improving the overall management of isolations.

Isolation Workflow

• The following 'request' screens have been updated to include an "Email Actions" section above the existing one for "Email Isolation"/"Send an Information-Only Email":
  • Request Approval
  • Request Deisolation
  • Request STT
  • Request Long-Term
• Regardless of which Request screen you are on, the sub-header will read "Select who should Approve this Request" with a sub-grouping labelled "Site Users By Role"
• The Users available for selection under "Site Users By Role" will be those with the Isolation Rights applicable to the current Isolation
  • A summary of the underlying logic is:
    1. Get the full list of Isolation-Rights where the overall 'Approve' flag is enabled for the current Action/Operation e.g. "Can Approve Deisolation", "Can Approve Long-Term"
    2. Get the list of Point-Types used across any rows in the current Isolation Details/Point-Type table
    3. For each Isolation-Right found in step 1, check if there are ANY of the current Isolations selected Point-Types which are NOT FLAGGED to allow for Approving
    4. Finally, get the list of Users who have been assigned to any of the Isolation-Rights which can Approve the specified Action/Operation for the Site of the current Isolation
• Upon selection of the User(s) and clicking the button to proceed with the Request, the following happens:
  • An email notification is sent to each User containing the standard Isolation-email details along with customised Subject and body-header text informing them why they are receiving the message e.g.

• • • Subject: Isolation#:000058 Approval Requested [Action Required]
    • Header-Text: Isolation 000058 has Requested Approval by yourself or another approver

• A record is added for each User to a new table for Isolation Email-Actions
  • This links to the Isolation, the selected User and the Action/Operation being Requested

Home -> My Actions

• Upon login, if the current User has been selected as an Approver for any of the 4 'Request' Actions listed above, they will see the applicable Isolations listed under one of the following new tabs:
  • Isolations - Approval Required
  • Isolations - Deisolation-Approval Required
  • Isolations - STT-Approval Required
  • Isolations - Long-Term Approval Required
• Opening the Isolation from one of those tabs and clicking "Return" will take the User back to the appropriate "My Actions" tab
• Similar to how the existing Permit "Request Approval" User notification/Actions work, any Isolation, My Action 'Request' items will only be listed for the logged in User while that Action/Operation is appropriate e.g.
  • An Isolation will only be included under the "Isolations - Approval Required" list while the Isolation has a Status of "Approval Requested"
  • Once the Isolation is Approved (i.e. either by the User who was requested to do so, or another User with the permitted Rights), as well as the Isolation moving on to "Approved", the Email-Action record(s) for that Isolation and Action/Operation are also updated accordingly i.e.
    • The date/time of the Approval as well as who Approved are recorded against the Email-Action record(s)
    • Note that this is done at either the Approval or Reject for the particular workflow-step as it prevents a situation where a historic Request lingers in the system and then reappears after a subsequent new Request.

 1.1.8.Isolation Close Types Archiving

At present, there is no method for archiving isolation close-type records within our system. This limitation means that any records that have been utilised in the past cannot be deleted, resulting in them remaining in the selection list indefinitely. To address this issue, we have implemented a standard 'Archive' functionality within the Administration section. This new feature allows us to mark records as archived, and we will utilise this flag to filter the available Close-Type options during the Permit workflow. As a result, users will only see relevant and active options, improving the overall user experience and maintaining a cleaner, more efficient selection process.

 1.1.9.OKTA Integration within PTW

Okta is a widely used identity and access management solution that provides secure authentication services. We have integrated Okta authentication into PTW, which enhances security by enabling Single Sign-On (SSO), multifactor authentication (MFA), and user management.

For more information, please contact Pisys Support.

1.1.10. Timed-Lockouts for Failed Logins

We have implemented an important update to our system regarding user account security. In the previous setup, a user would be permanently locked out of their account after reaching a specific number of failed login attempts, referred to as X invalid attempts.

To enhance user experience while maintaining security, we have revised this protocol. Now, instead of a permanent lockout, users will experience a temporary lockout period of Y minutes after their last unsuccessful attempt. During this time, users will not be able to access their accounts.

Once the Y-minute lockout period expires, the user can attempt to log in again and will be allowed X additional attempts to enter their credentials correctly. This change aims to provide a more flexible approach to account access while still safeguarding against unauthorised access.

1.1.11. Contractor Management Competencies can now be enabled by default on Panels

Contractor Management Competencies can now be automatically activated by default when using specific Panels.

Each competency will have an associated checkbox that allows administrators to set the competency to be enabled by default. When creating a permit and selecting a particular panel type, the competency will automatically be turned "on" if the checkbox is selected. This feature streamlines the permit creation process, ensuring that essential competencies are always included without needing to manually adjust settings each time.

We have added a checkbox under "Admin -> Competencies -> Edit" for "Selected by Default" with supporting text:

• Automatically select this Competency under the Panel-Type when first creating a Permit

When initially creating a Permit, any Competencies with the new setting ON will appear as pre-selected in the corresponding Panel-Type.

Enhancements

The following is a list of enhancements that were implemented in Pisys PTW 1.7.4.4. The list includes bug fixes, security updates and new functionality.

1. PTW-1915 - Risk Assessment Screen/Selection Changes.
2. PTW-1904 - Introduce Timed-Lockouts for Failed Login-Attempts.
3. PTW-1906 - Allow User-based Customers the ability to delete their permits.
4. PTW-1908 - Redesign the Login screens/Reset Password screen, etc., to remove mentions of Pisys for all customers that are using a custom footer.
5. PTW-1891 - Default Competencies to "On".
6. PTW-1921 - Risk Assessment - Edit Screen UI Changes.
7. PTW-1923 - Allow Archiving of Isolation Close-Types.
8. PTW-1903 - Custom Job Steps and Custom Hazards.
9. PTW-1909 - Rename "Whole Site" area drop-down option to "Applicable to All Areas".

Bug Fixes

10. PTW-1922 - Archiving a permit version removes the Suspend workflow checkboxes when used.
11. PTW-1931 - Reminder Emails Bug.
12. PTW-1952 - Console Error when trying to delete an Area.
13. PTW-1934 - RA Matrix Headers/Cells Max-Length.
14. PTW-1953 - Site: on permit list, not permit printout.
15. PTW-1947 - "View Companies" button for an archived Company Type is not filtering as expected.
16. PTW-1944 - The "Include Archived" dropdown filter is not working as expected on the CM Company List screen.
17. PTW-1950 - Review Date is auto-enabled to print even if not in use.
18. PTW-1946 - Headers on Printouts.
19. PTW-1951 - Management Overview Screen Timing-Out.
20. PTW-1941 - Inconsistent Labelling Between System and Printout.
21. PTW-1949 - "View User" hyperlink/button for an archived Company is not filtering as expected.
22. PTW-1940 - 'Hide if Empty' Attachments.
23. PTW-1933 - Remove all references to Method Statements.
24. PTW-1936 - Approve permit w Review Date Limit of 1mo failure.
25. PTW-1910 - Technip Review-Date Validity Period.
26. PTW-1932 - Table View for an RA does not persist when its edited.
27. PTW-1929 - Review Date Limit (Months) decimals values ignored.
28. PTW-1928 - Review Date left empty defaults to today.
29. PTW-1925 - When adding a child to a parent question, the "Save & Add Another" button treats the second question as a standalone instead of linking it to the original parent question.
30. PTW-1916 - Control Panel - Total Permit Allowance Calculation.
31. PTW-1926 - Modify all single-line textboxes associated with RAs to be expandable.
32. PTW-1924 - Non-editable RAs are misaligned.
33. PTW-1914 - Issue when saving Permit with a cleared mandatory Attachment.
34. PTW-1918 - API changes to exclude Panels using the same check as the Handback screen on the web app.
35. PTW-1927 - Adding a child to a parent question that already has children with visibility setup removes that visibility.
36. PTW-1902 - Site Emails - Additional Approver Change.
37. PTW-1907 - Red Box Around Controls.
38. PTW-1913 - OKTA and Microsoft AzureAD re-authentication issue.

Security Fixes

39. PTW-1904 - Introduce Timed-Lockouts for Failed Login-Attempts.
40. PTW-1912 - Okta Integration with PTW.

For an overview of our update process, please click here: https://pisys.co.uk/our-update-process/