Issue & Reproduction Steps

A user without the permissions can view sidebar icons related to Screens, Processes, Scripts, and other features that should be restricted. This issue exposes elements of the UI that should be inaccessible, potentially leading to unauthorized information access.

Steps to Replicate:

1. Create a new user account.
2. Log in as the newly created user.
3. Navigate to the "Projects" section.
4. Add assets to a project.
5. Proceed to any of the added assets within the project.
6. Navigate to the assets

Observe that the sidebar icons for Screens, Processes, etc., are visible, despite the user not having the appropriate permissions to access these features.

Expected Behavior:

Sidebar icons related to Screens, Processes, and other permission-restricted features should not be visible to users who do not have the required permissions. Only elements and functionalities authorized for the user's permission level should be accessible.

Actual Behavior: Sidebar icons for Screens, Processes, etc., are visible to users without the necessary permissions, indicating a potential permissions handling or UI display issue.

Solution

• Created DEFAULT_PERMISSIONS in the Permission model
• Refactor and centralise userHasPermission function
• Add sidebar menus using the userHasPermission() from core
• Add package menus using the userHasPermission() from core

How to Test

• Follow the reproduction steps and make sure that the sidebar icons are not visible to users who do not have the required permissions.
• From an admin account, add some permissions to the new user like View PM Blocks of View Screens and ensure that the user can see the icons

Related Tickets & Packages

-Ticket FOUR-14092

• package-data-sources
• package-vocabularies
• package-decision-engine
• package-pm-blocks:observation

ci:next
ci:package-data-sources:observation/FOUR-14092
ci:package-vocabularies:observation/FOUR-14092
ci:package-decision-engine:observation/FOUR-14092
ci:package-pm-blocks:observation/FOUR-14092

ci:deploy

Code Review Checklist

• I have pulled this code locally and tested it on my instance, along with any associated packages.
• This code adheres to ProcessMaker Coding Guidelines.
• This code includes a unit test or an E2E test that tests its functionality, or is covered by an existing test.
• This solution fixes the bug reported in the original ticket.
• This solution does not alter the expected output of a component in a way that would break existing Processes.
• This solution does not implement any breaking changes that would invalidate documentation or cause existing Processes to fail.
• This solution has been tested with enterprise packages that rely on its functionality and does not introduce bugs in those packages.
• This code does not duplicate functionality that already exists in the framework or in ProcessMaker.
• This ticket conforms to the PRD associated with this part of ProcessMaker.