How do you populate the request class drop-down in work task?


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

Continue reading

Advertisements

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

Why is the root classification set to the ~ (tilde) symbol?


In my current TRIRIGA 10.3.2 / 3.5.2.1 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 / 3.5.2.1 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.]

Continue reading

Why can’t “Create” state transition be triggered through OSLC?


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

Continue reading

IV95367: Blank date and time fields are counted by Excel after export


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

Continue reading

IV95426: Non-English user typing minus in currency causes error


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.

The null check must also check for “Not a Number” (NaN) in JavaScript when validating numbers. Moving forward, we resolved an issue where entering a currency value as a non-English user would throw an error.

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

Continue reading