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.]

Continue reading

Can you use system location in groups to control data access?


We are on TRIRIGA 3.5.2 and 10.5.2. I’ve recently noticed that in our security groups, there is now a “Location Name” field which is hidden. Is this a placeholder field for a future release? Or can we actually use this field to control data access?

No, record security is currently only supported on Geography and Organization. I am not aware of any current enhancements to add Location-based security.

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

Continue reading

How do you control security settings in Document Manager?


I am looking for any resource that will provide information on how security for the Document Manager works with Company level views and Project level views. A couple of preliminary questions. (1) Can security group settings control what action displays or not? I cannot seem to get consistent results when changing settings in a particular security group. (2) Next, when the user is in Project level view, how do you control security settings for the Document Manager in this view?

The Document Manager actions are controlled by access given on the Permissions tab of the folder/document. Access can be: View, Modify, Download, Create, or Full Admin access. (Admin users have access to all actions by default.) For the user who creates a document record, all access to the document is given implicitly.

Similarly for the Project container: Only documents of the project for which the user is the author have all access. Access to other documents in the project is controlled by the access given on the Permissions tab of the folder/document.

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

Continue reading

Can you disable the IBM TRIRIGA “System” account?


We are considering the disabling of the default System account for security reasons. We are currently protecting the account with a long strong password. Does anyone have any experience with this? Is this System account used in internal system processes where disabling it will not work or will wreck havoc on the system?

I don’t think you can “disable” the System account. Typically, what you have done already is as far as most people go. I’ve heard of one company having an executive type in the password and keeping the password secret until it’s needed for some justifiable reason.

Through the application or database, you could populate a random number which then no one would know. But I’d highly recommend taking a copy of your database before you start testing, changing the password, or anything else down that path. You could corrupt the database by trying to disable the System account.

[Admin: To see other related posts, use the Admin Group tag or Password tag.]

Continue reading

Why do queries that are expected to display data show nothing?


When running queries against records within the application, expected record results are not displayed. Why do queries that are expected to display data show nothing at all?

Within the application, we have a variety of different settings that can restrict a user’s access to record data. The user’s Security Group can restrict access to records at the module and BO level, but each use case is slightly different. 

Within every user-facing record, on the System tab, there are fields for System Organization, System Location and System Geography. These values operate in conjunction with similar fields on the Security Group and the User’s People record to allow and restrict access to records. 

The key is that as soon as the user is given a defined Organization, Location, and Geography, the fields on the System tab of their People record are populated. Once that happens, each record they create will be seeded with that information as well. So far, all is well and good, but those users who lack similar settings are now unable to see those newly created records, unless their System fields are the same as or located at a higher point in the hierarchy.

Another area to consider is the Security Group settings for Organization and Geography. If a user has no values set on their People record, the application can still restrict access by using the Security Group values. This can cause a problem as the Organization and Geography Security is defaulted to null in the as-shipped application. This essentially gives the security code no starting point for determining access and will not display records.

To recap, if the record data does not align with the data in the user’s People record, or the data in the user’s Security Group, the record will not be displayed. As mentioned, there are a couple of things to look for. As an Admin user, compare the user’s record data with the record that should be displayed, and correct any misaligned data. Also, in the Security Group, set the Organization and Geography to the root of each hierarchy by default. For additional details, please review the following TRIRIGA wiki article: Security Overview.

Continue reading

IV97599: “Grant Security Access” workflow does not filter properly


The “Grant Security Access – MASSUPDATE” workflow does not filter the groups and licenses correctly, because various tasks in this workflow are not set correctly.

The “Update Records” action on the Grant Security Access form was creating a duplicate of Groups/Licenses on People and My Profile records if the Groups/Licenses selected were the same as the ones added on People and My Profile. Moving forward, we resolved the issue by modifying the workflow “Grant Security Access – MASSUPDATE” to not create any duplicate Groups/Licenses if they are already added to People and My Profile. We also fixed another issue, to create new Groups if the “Clear Existing Security?” check box is checked.

[Admin: To see other related posts, use the Groups tag or License tag.]

Continue reading

How do you add or remove access to the “Form” action of a report?


I’d like to grant or revoke the access to the “Form” button of a report according to the security group of users. But I haven’t find any options related to this button in the Security Manager.

If you can find the action in the business object when it is selected in Security Manager, then you can control it there. If you cannot find the action, you will not be able to manage it there. Some objects are system objects and cannot be modified. This may be one of them.

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

Continue reading