The query engine is calling multiple SQL statements that check permissions for module and form-level access for each row returned.
A sample report runs pairs of duplicated SQL statements with very similar bind variables. It first selects the SERVICE_ID using 3 bind variables, then repeats the process, checking for a Template ID of -1 with otherwise identical binds to the first statement. We see appsec.getValidSecurityServiceIds calls to the APP_OBJECT_PERMISSION that data should be cached.
The query engine was looking up security group tab information for every BO in the report crossed with every group a user is assigned to. Moving forward, we reduced the number of calls to the database for non-admin users when checking security by adding a new cache.
Even when new-style 3.2+ licenses (LICENSE_IBM_TRIRIGA_<feature>.properties files) are in place, and no old-style pre-3.2 license (single TRIRIGALICENSE.properties file) is present, the Admin Console “System Manager” panel still contains a “TRIRIGA License” choice, which, when clicked, displays what appears to be an encrypted TRIRIGALICENSE.properties file.
If there is no old-style pre-3.2 license file present, it is confusing that the system makes it look like a TRIRIGALICENSE.properties file is still present and being used. Is it possible to disable the “TRIRIGA License” link within the “System Manager” panel? Or redirect the display to the Admin Console “License Manager” panel?
[Admin: This post is related to the 02.08.16 post about finding information on TRIRIGA licenses. To see other related posts, use the License tag.]
The project context can be set to a project where the user does not have Capital Project security access. A user cannot modify or update data inside the project when they do this. However, the TRIRIGA platform should prevent the setting of this context from ever occurring in the first place.
Users can set the project container through direct URL manipulation. Moving forward, the privilege escalation vulnerability has been resolved.
[Admin: This post is related to the 03.01.17 post about a privilege escalation vulnerability in the Report Manager, and the 02.13.17 post about the relationship between project context and security.]
If the Gantt chart updates the planned start date of a task while you correct the invalid dependencies in the Gantt chart, then the actual start date value gets cleared.
[Admin: This post is related to the 06.10.16 post about finding information on the Gantt scheduler. To see other related posts, use the Gantt tag.]
Scheduled events are not being removed by the Cleanup Agent from the table T_SCHEDULEDEVENTS after the scheduled events are completed. This causes this table to grow immensely, especially for companies that use recurrence events in their calendar. Identifying the records can be done via SQL…
The deletion of these records are currently not automated by the Cleanup Agent.
Moving forward, the completed scheduled events older than the value specified in the property CLEANUP_AGENT_SCHEDULED_EVENT_COMPLETE_DAYS will
now be marked for deletion.
When you retire a workflow from the manager, selecting OK signs you out of the application. Meanwhile, selecting the Retire action within the workflow works fine.
The IBM TRIRIGA application is vulnerable to a privilege escalation vulnerability. Specifically, IBM TRIRIGA Report Manager contains a vulnerability that could allow an authenticated user to execute actions to which they should not have access.