I’m having issues with request classes on work tasks. We created a project (including work location). But now, when we create a task from the project, very few of the values (including work location) are mapped onto the null work task. The drop-down that comes from the request class depends solely on this work location.
Also, the work location of the task gets its value from the project (as mapped). But now, when we try to get the drop-down for the request class based on work location, random values are shown. When I reselect the same work location, and then go back to the request class, I see the correct values. Any thoughts on this behavior? How do you get the request class list for the very first time without reselecting the work location in a work task that was created from the project?
[Admin: To see other related posts, use the Mapping tag or Work Tasks tag.]
In my current TRIRIGA 10.3.2 / 220.127.116.11 environment, I see that some of the classification fields have a root classification value set to ~ (tilde) symbol. This seems strange to me, because classification fields can’t be created with a blank value or any such symbol.
And when I migrate the BO with such fields in another TRIRIGA 10.5.2 / 18.104.22.168 environment, it’s automatically populating the classification value (e.g. Expenditure Type) in the root classification. Has anyone seen a scenario where the root classification is set to the ~ symbol?
[Admin: To see other related posts, use the Classifications 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 22.214.171.124 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.]
Go to the Projects tab, Capital sub-tab. Click on “Maximize” to maximize the screen to all projects. Click on “Export” and open the exported query, for example, “All Capital Projects.xlsx”. Open in Excel, for example, Excel 2016. Notice that once blank date fields are included, they are included in the total count.
This fix not only resolved the Date, and Date & Time fields, but also the Duration, Time, and System Read Only fields. Moving forward, we resolved a query export to Excel issue where blank values for Date, Date & Time, Duration, Time, and System Read Only fields were not correctly resolving to blank/null in the Excel spreadsheet.
[Admin: To see other related posts, use the Excel tag.]
A non-English user puts a negative sign on the existing currency amount. Save the record. Navigate away and go back to the tab. A MID error occurs.
[Admin: To see other related posts, use the Currency tag.]
This issue happens when you create a simple chart report, of “Pie Chart” type, which displays all employees grouped by status. This in itself works fine. However, the user then adds a filter on Status = “Active User”. Now, instead of displaying a pie chart with a full 100% view of all “Active User” employee records, the chart says “No data to display”. If a second status is added to filter the chart, it displays as expected.
An issue with chart displaying data when filtered to a single record set. The issue is that the chart type reports GraphDataSource “hasData” method had a check of the “currentItem” value when the data size is equal to 1. However, “currentItem” is always null at the point when “hasData” is called, causing the method to return false.
The “currentItem” check is an artifact from before the AnyChart 7 upgrade. The fix is to modify the “hasData” check to go directly at the data when the data size is 1, instead of using “currentItem”. Moving forward, we resolved a chart type report issue, where charts having only one data result indicated that no data was found.