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

Why can’t you view document upload screens in TRIRIGA?

A navigation item whose target is set to “External URL” and whose URL links directly to a folder no longer works. An error such as the following might occur: “An error occurred, please contact your system administrator: [MID-4077624314].”

The Java applet that uploaded documents based on the navigation item target in earlier TRIRIGA versions is deprecated due to security concerns. Most browsers no longer support Java applets. The applet upload function is replaced with an HTML5 upload function.

As a result of these changes, “External URL” navigation items in earlier TRIRIGA versions that successfully uploaded documents via portals to upload documents to a folder might no longer work. The Document Upload widget was redesigned to be used only in the context of either Document Manager or a record, not a portal. Use Document Manager directly to upload documents.

[Admin: This post is related to the 04.07.17 post about “External URL” navigation items that may no longer work, and the 07.10.15 post and 04.10.15 post about the document upload enhancement. To see other related posts, use the Document Manager tag.]

What are the minimum permissions for TRIRIGA to function correctly?

In a standard OOB installation of TRIRIGA on Windows Server 2012 R2, it gives the user group the “Execute” and “Special” permissions to the TRIRIGA folder. We are concerned from a security perspective: Why are the “Execute” and “Special” permissions needed for a standard installation? What are the minimum permissions needed for TRIRIGA to function correctly?

You can remove the user group “Execute” permission on Windows. Only the service user needs permissions to read from the install directory, and/or execute WebSphere Liberty under the TRIRIGA install directory (if so installed).

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

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

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

Verdantix: Will LED-based Li-Fi replace Wi-Fi technology?

Li-Fi is an exciting emerging technology that’s got the communications technology world talking. By transmitting data by modulating LED lights and using a light detector as a receiver, Li-Fi is extremely fast compared to Wi-Fi, being able to stream up to 224 gigabits per second compared to 100 gigabits achievable by the world’s fastest Wi-Fi network.

It also has great security benefits as it is harder to intercept the signal outside of the building (or smart building). There are potential cost advantages too as ordinary LED lights can be used lowering operational and maintenance costs, although this will depend on the router and receiver costs once production at scale is reached…

Only in 2017, we have witnessed three significant acquisitions and partnerships.

• Back in February, technology provider Philips Lighting acquired the French Li-Fi start-up Luciom.
• In September Scottish Li-Fi firm PureLiFi partnered with LED lighting provider Wipro Lighting, to provide products for the Asian market.
• Also in September, French Li-Fi specialist Lucibel partnered with Citelum, part of EDF, to provide a range of LED-based lighting solutions that deliver incremental benefits from better energy performance and Li-Fi communication…

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

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

How do you set up a Group object to leverage query sections?

In the IBM TRIRIGA 3.5.3 and 10.5.3 release, the Group object was redesigned to leverage query sections, instead of a single large smart section. The query sections improve the performance and usability of the Members tab by paginating the results, and providing filtering capabilities. These application changes are a part of the IBM TRIRIGA 10.5.3 application upgrade object migration (OM) package, but can be applied to systems running older application versions.

To help anyone who would like to apply the Group enhancements to an environment not running 10.5.3, the Group_Query_Enhancement_10.5.3.zip can be downloaded from this wiki. This is an unsupported object migration (OM) package that includes the Group form, queries, and workflows that were created to enhance the application. This OM package can be imported into an environment running on the 3.5.3 platform release.

Note: This enhancement requires the 3.5.3 platform release for the “Add” and “Delete” functions to work within the query section. There are new custom tasks that are called by workflows that handle the adding and removing of group member records, when users or groups are selected. Before applying this OM to a production system, the OM package should be tested in a test or development environment first.

[Admin: This post is related to the 03.07.16 post about best practices for managing your security groups. To see other related posts, use the Security tag.]

Why can’t a non-Admin user see reservable spaces in organization?

We have some reservable spaces with system geography and system organization settings. A non-Admin user also has the same geography settings. There are security groups for reservations, and organizations and geography security groups are assigned to him. The geo and org security groups have the same geo and org as the space and profile. But the non-Admin user still isn’t able to see spaces.

He is only able to see them when the first level of the org hierarchy is provided in the group (i.e. \Organization). But as soon as the second level is given in the group, he isn’t able to see them. Can anyone help me on this? I think there is some issue in the org, but I don’t know exactly where it is.

[Admin: To see other related posts, use the Geography tag or Organizations tag.]

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