IV95219: Section 508 compliance for TRIRIGA login page
Visually impaired users dependent on Section 508 compliance to use TRIRIGA may run into a problem in the login page. They might have difficulty in navigating to enter the ID and Password.
IV95289: Section 508 compliance in Projects page
Keyboard access, style sheet dependence, language, page titles, and images for Section 508 compliance fail test on Projects tab.
IV95290: Section 508 compliance in My Reports page
Keyboard access, web forms have invalid HTML, web links, and user controls. Images have no description in plain text.
[Admin: This post is related to the 10.17.16 post about multiple APARs on Section 508 compliance.]
There is a “Refresh” button on the Project Tasks query section (on the Schedule tab of Capital Projects) which doesn’t appear to do anything. It also doesn’t appear in Form Builder, so we cannot seem to remove this button. Does anyone have any clue: (1) What does it do? No workflows run, as far as I can tell. (2) How can I remove it from the form?
The “Refresh” section-action button will re-run the query, updating the results in the query section. It is intended to show the latest state of the tasks as currently stored in the database.
The platform adds it automatically because there is a Gantt section on the form, and the query section is tied to the Gantt section, with the thought that the two sections show a different view of the same data. When someone updates and saves the Gantt, the query section will not be refreshed automatically, so the button is added to allow them to quickly refresh the data in the section to see the changes made in the Gantt section. At the root, the logic of the platform is…
[Admin: To see other related posts, use the Gantt tag.]
Go to the Projects tab, Capital sub-tab. Click on “Maximize” to maximize the screen to all projects. Click on “Export” and open the exported query, for example, “All Capital Projects.xlsx”. Open in Excel, for example, Excel 2016. Notice that once blank date fields are included, they are included in the total count.
This fix not only resolved the Date, and Date & Time fields, but also the Duration, Time, and System Read Only fields. Moving forward, we resolved a query export to Excel issue where blank values for Date, Date & Time, Duration, Time, and System Read Only fields were not correctly resolving to blank/null in the Excel spreadsheet.
[Admin: To see other related posts, use the Excel tag.]
There are 2 project records that a user is trying to access. Project 1 has read-only access for a particular security group (Security tab of the project). Project 2 security does not have read-only access (Security tab of the project). The user in the security group logs in and accesses Project 1. The record is read only, which is correct. Now, the user accesses Project 2, which should be editable. It is not. It is still read only.
Moving forward, an issue that could cause user permissions to be reduced to read-only after viewing a read-only project record has been resolved. A previous workaround of clearing the security cache to reset the permissions level is no longer necessary.
Our client is asking for the proper way to migrate project templates (the project itself, tasks, dependencies, roles) between instances. Object migration (they use TRIRIGA 3.4.1) doesn’t move (template) associations, so as a result, all records are created separately. Can I ask your recommendation on a right way to do it?
In IE11, when you open a task directly from the Gantt chart, the popup window opens behind the Project form.
With the TreeGrid API, we needed to suppress all next actions to resolve focus issues with IE. Moving forward, an issue has been fixed in IE where the Task popup window appears behind the Gantt Project form.
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.]