How do you set the number of form actions in a security group?

We recently upgraded to TRIRIGA Platform 3.5.3 and we are still in Application 10.3. We have a custom cstWorkTask form and it has 133 form actions. In the “Shop Foreman” security group, we want to give access to over 125 form actions.

But it looks like there is a limit where you can only set 119 form actions. Because as soon as you select the 120th form action, the spinning wheel appears and never completes. We have tried clicking the “Select All” check box, but as soon as you click that, the spinning wheel appears and never completes. If we remove a couple of actions from the 119 already selected, then it lets you check two more without the spinning wheel. Is there any setting that controls how many form actions can be set in the security group? Or is this a known issue?

[Admin: To see other related posts, use the Security Manager tag.]

Advertisements

IV97719: Form action indefinitely spins when form is read-only

When a record is in a read-only state, any form action text links (not a button) on the form no longer run the workflow assigned to the OnClick event for the action. The “busy spinner” comes up and the action is never taken. The only recourse is to close the form window. If the record is editable, the form action text links run their workflows as expected.

The JavaScript in the form field action was losing focus. Moving forward, clicking a form field action when the record is in a read-only state will no longer cause the record to lose focus.

[Admin: To see other related posts, use the OnClick tag or OnChange tag.]

Why are document attachments overwriting each other?

We are using TRIRIGA 3.5.2. We are currently experiencing an issue with lease document attachments. When one user uploads a document that has the same name to two different lease records, the document record is overwritten.

The issue stems from the fact that the upload functionality defaults the path to \ROOT\Object Attachments\[Employee Name]\triRealEstateContract\[File Name]. There is a folder ID parameter in the action URL, but it doesn’t seem to work. Is there a way for TRIRIGA to create a folder based on the current record ID instead of the BO name?

[Admin: To see other related posts, use the Document Manager tag.]

IV95718: Multi-tab sections freeze when user has read-only access

Users are encountering a spinning wheel when clicking on multi-tabs (sub-tabs) other than the main tabs. The system hangs and freezes. Users will then log out or close the application. For some users, it works fine, but for other users, it does not. This is related to a security group issue on the TRIRIGA 3.5.2 platform.

We needed to move the logic of how the platform validates section actions closer to where the actual action is taking place. Moving forward, the user will be able to navigate between multi-tab sections, if they have read-only access on the section.

[Admin: To see other related posts, use the Security tag.]

Why aren’t changes to security groups being saved?

Is anybody seeing this issue in TRIRIGA 3.5.2? The Release Notes say that:

“The inner Save action on the Access tab of the Security Manager is removed. The user can make multiple permission changes, mix them with general changes and member changes, and save all at the end with the Save or Save & Close actions.”

But this doesn’t seem to work. Why not?

[Admin: This post is related to the 03.07.16 post about best practices for managing your security groups.]

IV95185: Reservation food order cancellation charges not applied

If a food order is created within the cancellation time window, cancellation charges are applied while cancelling the reservation. If the reservation is done in advance (i.e. before the cancellation time window starts) and the cancellation is within the cancellation time window, the cancellation charges are not applied.

We needed to correct the action in triCancellationWakeUp. In the workflow “triPurchaseOrder – Synchronous – Food Order – Create Purchase Line Items”, the “triCancellationWakeUp” trigger action task was referencing the wrong action to trigger (triCreateDraft) instead of the correct action (triCancellationWakeUp).

IV95094: Error if query has “Group By” and a record is removed

If a query section exists in a record, that query section has a “Find” and “Remove”. If that query has a “Group By” in it, the “Remove” will issue a MID error (even though the removal actually takes place) if filter criteria are applied before clicking “Remove”.

The problem does not occur if no filter criteria are applied before clicking “Remove”, or if the query associated with the query section does not have a “Group By”. This problem was seen in multiple releases including TRIRIGA 3.4.2.5 and 3.5.2.1.

We needed to change the submit of the page method to “Get” for non-state-changing actions like “Refresh” or “Clear Filter”. The “De-Associate” action on the “Group By” report no longer throws any exception after applying a filter to the query.