TRIRIGA has the notion of project-based security scope, also called project context. At the upper right-hand side of the main TRIRIGA portal, there is a toggle to switch between Company and Project-level security, as well as a query to find and select in which project to operate.
To see and select a project, the user must be given specific security access to a project. This is done by adding the user’s group or the specific user to the Security tab of the project. Once the user or users have been granted access to the project, and they select the project from the project selector on the portal, they are then in the “context of the project.”
Any records created in the project context are then owned by that project, and security is restricted to those records, so the records are only visible and editable to those people that have access to the project, and have also switched their scope to run in that project context.
Items like documents and folders within Document Manager will also operate in a project context. You may notice that files uploaded to the Notes & Documents tab of records in the project context have a different folder path within Document Manager. Because the entire Document Manager tree is also in the project context, it is necessary to have the parent folder created in the project context as well. This folder’s path will be different than the uploads on records at the company level.
[Admin: This post is related to the 04.08.16 post about where your documents go in TRIRIGA, and the 08.25.16 post about an issue with selecting child projects.]
When the user (triPeople, My Profile) has the primary geography or organization defined, after force-resetting his password, the user doesn’t have enough permission to change his password after the next login. This issue is caused by the Org or Geo settings of the security group “TRIRIGA Password Change”. Any newly created password change record (which is filled with the system Org or Geo settings of the user) is not visible by this group.
[Admin: The same article is also posted in the IBM Support Portal as a technote.]
Is it possible to create a security group where the users can only login via any UX apps that they have been granted permission to see? But without access to the main TRIRIGA application?
At the moment, it’s not possible to create a security group where users can only log into a UX application and no access to main TRIRIGA.
Metric reports cannot be saved as PDF, JPG or PNG after applying Fix Pack 18.104.22.168:
- 1. Saving a metric report cannot be done due to security reasons.
- 2. By using IE F12 Developer Tools, we have found out that when saving a metric, data is posted at export.anychart.com.
- 3. Adding export.anychart.com to the Trusted Sites allows the user to save the metric report.
When attempting to make a connection through the CAD Integrator 22.214.171.124 client (with TRIRIGA 10.5/3.5), we are seeing the following error in the security log:
2016-11-18 10:37:55,142 INFO [com.tririga.architecture.security.logger.SecurityLogger] Login Attempt -- To: [/pc/ci/dispatch] Account: [null] From: [10.3.x.xxx] Status: [FAILED]
2016-11-18 10:37:55,705 INFO [com.tririga.architecture.security.logger.SecurityLogger] Login Attempt -- To: [/pc/ci/dispatch] Account: [jackie.lu] From: [10.3.x.xxx] Status: [SUCCESS]
2016-11-18 10:37:55,720 WARN [com.tririga.XSS] XSS potential: Request did not come in with TRIRIGA security token: /pc/ci/dispatch From: 10.3.x.xxx [MID-485378064]
The client fails to establish connection. Any thoughts on what could be causing this? We do not have SSO configured, and the FRONT_END_SERVER setting has been checked.
[Admin: The same question is also posted in the TRIRIGA Around the World Facebook group.]
If you open a record with no preview available, you cannot download the record at times. The legacy document security prevents the download link from appearing as an action. If you do have access, the action isn’t visible if the parent is set to read-only anyway.
A user that was previously able to accept action items, now receives the message “TRIRIGA Security Warning: You do not have permission to access this page. Contact your TRIRIGA administrator. Thank you.” when clicking “Accept”.
We needed to set up the accept task action to follow the correct security. Moving forward, the issue was resolved where a user was getting no access when trying to accept an action item.