Is there a way to configure the rights for an admin account to create new workflows in Workflow Builder?
The user must have the LICENSE_IBM_TRIRIGA_Application_Builder license. This license is required to create a new workflow or BO. The core licenses can modify workflows and BOs, but not create new ones.
[Admin: To see other related posts, use the License tag or Workflow tag.]
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.]
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.]
I have an issue where it is not possible for non-Admin users to trigger the Create state transition through our OSLC interface. Instead, we get the following error:
2017-06-27 13:08:10.301 UTC ERROR [com.tririga.platform.integration.oslc.OslcRequestDispatcherImpl](Default Executor-thread-34280) Failed to read message: null
2017-06-27 13:08:10.301 UTC ERROR [com.tririga.platform.integration.oslc.OslcRequestDispatcherImpl](Default Executor-thread-34280) Exception in OSLC call: com.tririga.platform.integration.oslc.OslcException. message=java.lang.ClassCastException: com.tririga.platform.metadata.domain.BoStateTransitionId incompatible with com.tririga.platform.metadata.domain.gui.GuiStateTransitionMetadata
The fact that I am able to create and associate the record using an Admin user says to me that this is related to permissions, but I’ve made sure that the user has full security access for both the BO/form it is trying to create, the BO/form that it is attaching it to, and all other BOs/forms that are associated to it, and it still gives me the error above.
When I open the created record that my Admin user created, it looks to be correct. But when I open the one that the non-Admin user tried to create, it shows an empty record. None of the fields are saved in a null state, which of course is because it didn’t get created, the Create state transition was not triggered. Any idea of what is causing this issue? And how to resolve it?
[Admin: To see other related posts, use the OSLC tag.]
A user is unable to create a document and gets the following error “User does not have permissions to create a document”. How do you resolve this error?
The proper security access has not been granted to the Document object. Login as an Admin user. Go to the Security Manager. Select the Document object. In the right-hand panel, look at the access level. Make sure that “Read, Update and Create” is selected.
[Admin: This post is related to the 05.10.17 post about the 3.5.2 Security Manager. To see other related posts, use the Security Manager tag.]
There may also be an issue where the menu does not load, unless you use the CUILOAD command directly to load the TrgaAcad_en.cuix directly from the install directory. Then, attempting to login results in a _TRGA_LOGIN Unknown command “TRGA_LOGIN” message. The cause of this issue is that the CAD Integrator/Publisher (CI) is not initializing correctly…
Assuming NETLOAD works, the main issue is that probably the CI installer does not have permission to update the registry. CI actually uses the JVM and the command line to update the registry, so on certain secure systems, it may not be allowed to update the registry as needed to tell AutoCAD to load CAD Integrator…
The main issue is a permission issue where the CI installer cannot update the Windows registry to enable automatic loading, which is outside the control of the CI installer. If the CI installer cannot update the registry, then see the workaround…
[Admin: To see other related posts, use the Integrator tag or AutoCAD tag.]
If you are an administrator for TRIRIGA, chances are you have access to Security Manager, which is responsible for granting access to the TRIRIGA applications through the security groups. Prior to TRIRIGA 3.5.2, the only way to view security access was to go to the Access tab and then view the Access Configuration. That is where you would grant (or remove) access. However, in TRIRIGA 3.5.2, on the Access tab, a new Access Summary sub-tab was added.
The Access Summary sub-tab will show you in a column format, the permissions of the tool/module, form, tab, and section. You are able to filter by each of those fields. Once you see the data, you can start using the filters to look at the access…
This tab should now make it much easier to identify what a security group has access to. If you find yourself limited with what you want to do within the tab, there is an Export button, that will export the data into a tab-delimited .txt file…
[Admin: A similar article is also posted in the IBM Support Portal. This post is related to the 03.07.16 post about best practices for managing your security groups.]