I need some clarification about the state transitions in an object. How do we decide that a record must be in “Read Only” mode for a particular state?
- (1) Check the “Read Only” property for all the transitions coming into that state.
- (2) Check the “Read Only” property for all the transitions going out from that state.
- (3) Both 1 and 2.
Let me know about this, or if there any other situations which can put a record in read-only mode for that state.
[Admin: To see other related posts, use the Read-Only tag.]
If you attempt to revise a project from the Schedule tab, where the Gantt chart is visible, your session is expired and you receive an invalid session error. The issue was observed in Internet Explorer and Chrome, but not in Firefox.
An analysis from a Fiddler trace shows that when revising the project in Chrome, this POST to GanttDataUpload.jsp seems to kill the session. In Firefox, for whatever reason, this POST doesn’t occur, and the state transition is successful. To confirm that this is the scenario you are experiencing, use the following technote to run a Fiddler trace and check for the same GanttDataUpload.jsp call: IBM TRIRIGA using Fiddler for tracing web browser traffic.
As a temporary fix, use Firefox. When the record is in a read-only state, no Save action should be called on the Gantt. Moving forward, we resolved the session-kill issue when the user performs a Revise action on a project in the Schedule tab.
[Admin: This post is related to the 08.18.15 post about using Fiddler to trace TRIRIGA web traffic. To see other related posts, use the Gantt tag or Fiddler 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.]
We are running TRIRIGA 220.127.116.11 platform and TRIRIGA 10.5 application. We have a requirement from our customer, for Sarbanes-Oxley (SOX) compliance reasons, that we need to change the “System” user password in TRIRIGA. We have done this in the past. However, the old option now appears to have become read-only, so we can’t do it the same way. Any ideas how we can update this password now?
Here are some things that might be preventing you from updating the password:
- 1. The logged-in user does not have security access to update the password, or a workflow has triggered on the record that has modified the metadata, and made the password fields or its section non-editable.
- 2. The record is in a state that only supports read-only actions. This makes the record non-editable.
- If you are logged in as Admin and cannot modify the password, I’d confirm that the System user is still part of the Admin group.
- If you are trying to change the System password as another user that is not an Admin, I would put that user in the Admin group temporarily to see if this gets past your issue.
- If you can confirm that a user in the Admin group cannot modify the record, I would look at workflows that are changing the metadata and the record state.
- If you cannot access the account as the System user, you can temporarily clear the System password to blank (null), so that you can login as Admin and reset the password. For example, via an update SQL script:
- update user_credentials set password = null where user_account = ‘system’.
[Admin: This post is related to the 04.18.16 post about resetting a user’s password as an administrator. To see other related posts, use the Password tag.]
I’ve noticed that if the record is read-only in its current state, we can still edit this record via the editable query. Is it possible to set editable fields, or the whole record, to read-only conditionally? For example, according to status?
Unfortunately, the platform does not handle this requirement. I would recommend adding a request for enhancement (RFE) for consideration in a future release.
[Admin: To see other related posts, use the Editable tag.]
Since TRIRIGA is new territory for a lot of you out there, and I have already received various queries about this, let’s take a brief look at the correct sequence to create a new TRIRIGA classification as follows:
- 1. Create a new BO within the Classification module, and add other fields, if needed.
- 2. Set up the Publish Name (BO Mapping). Tip: For classifications, you use the Name field as the lone field in the Publish Name to prevent entering duplicate classification entries. The Name field is in the Record Information section when you click Find in the BO Mapping tool.
- 3. Save the BO.
- 4. Create an association between the new BO and itself by using Is Parent Of. This action creates an Include. Note: Create this association from within the Data Modeler, not within the Association Manager. Also, when creating Includes, ensure that the Parent BO is in the Revision in Progress state before you create the association. Otherwise, the Include is not created properly.
- 5. Publish the BO.
- 6. Revise the Classification BO.
- 7. Create an association between the Classification BO and the new BO that was created in Step 1 using Is Parent Of. This action creates an Include.
- 8. Publish the Classification BO.
- 9. Copy the triClassification form and assign the new form to the BO that was created in Step 1. Add at least the Name field to the form.
- 10. Change the label of the new form to match the label of the new BO.
- 11. In the State Family, click Find to import the other states and transitions.
- 12. In the Includes/Forms tab, add the newly created form to the Includes list. (Add it to itself.)
- 13. Publish the form.
- 14. Revise the triClassification form.
- 15. In the Includes/Forms tab, add the newly created form to the Includes list.
- 16. Publish the triClassification form.
Thus far, we have the Classification definition metadata and no Classification records exist yet. In order to create records, follow the last 2 steps as follows:
- 17. From the Classification Hierarchy Master detail view, create the local parent for the new Classification as a child of the Hierarchy root record.
- 18. Create the actual new Classification records under the local root for the new Classification.
[Admin: To see other related posts, use the Classifications tag.]