I’m getting some issues with the people record. Once created, it is not getting associated with the triPeople object, nor the My Profile object. This prevents a new user from logging into the environment. The associated My Profile is also missing even after making the user an active TRIRIGA user. Any reasons for this?
I have a few questions from our customer about TRIRIGA reports:
- Question 1: We want to create a report to show the triProperty which has more than one triBuilding as children. By using an association filter, we can only show the triProperty which has at least one triBuilding. By using a summary report, we can group by triProperty to show the number of triBuilding it has, but we can’t add another criterion based on the “Number” column. So, both two solutions above don’t work.
- Question 2: How can we do something like a “left join” in a multiple-BO report? We have noticed that the behavior of multiple BOs in a report acts more like an “inner join” query. The filter based on the secondary BO will also impact the primary BO result. Do you know any way to get a “left join” result in TRIRIGA?
- Question 3: How can we share a list of reports with users who are members of a specified security group? Our customer doesn’t want to grant the access of the “My Report” application for those groups, and they would like a solution that is more dynamic than adding those reports into the portal of the user. I don’t know if there is way to do this. Can the Admin user define a favorite list for the end users?
The user template of the source environment replaces the user template of the destination environment of the same person record after an OM import. In TRIRIGA 3.5.2, when a triPeople user template is migrated from one environment to another, if a user’s people record is associated with the string “Applied Template” in the source environment, the most-recently applied template will be applied to same user’s people record in the target environment.
For example, user James Sullivan has a Project Team Member template applied in the test environment. In the CERT environment, user James Sullivan has a Facilities Manager template applied. But when the Project Team template is migrated to the CERT environment, the template is applied (instead of the Facilities Manager template) to James Sullivan’s people record.
This is working as designed. The root of the issue is that when an OM that has a people template is imported from the source environment to the target environment, and when the published name of the user profile record is the same in both the source and target environments, it will NOT replace, but create additional associations from source to target. All of these associations can be seen in the Associations tab of the user record. However, the form will show that latest template that was applied.
[Admin: To see other related posts, use the Templates 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.]
In TRIRIGA 10.5.1, if you navigate to Home > Projects, and have the “Projects – Projects Landing Page – Default” portal in place, the primary locations for any projects you have listed in the “My Active Projects” portal section are flagged in the “My Project Locations” portal section.
But in TRIRIGA 10.5.2, this does not happen. No project locations appear with a flag in the “My Project Locations” portal section. There appears to be a problem introduced between 10.5.1 and 10.5.2 due to a reverse association filter being removed.
The “Location – Navigation – GIS – Buildings, Structures, and Retail Locations – Project Manager Query” was configured with an incorrect forward association string, that prevented capital project locations from displaying on a GIS map. Moving forward, the Advanced tab > Geography Module > triCity Business Object association filter had its forward association string updated to “Geography Contains” from “Geography Belongs To”.
[Admin: To see other related posts, use the GIS tag.]
In a Gantt section, the section is not honoring the associated report sort order.
The issue was caused by the dynamic ordering that was implemented by the project tasks’ internal tree set. The BO query comparison was performed by using the string form of the columns. Moving forward, we resolved an issue where the default Gantt sort ordering, and the sort ordering immediately after importing an MPP project file, did not correctly order by the sequence ID based on the Gantt section query configuration.
The “Apply Record” and “Apply Template” methods use current time stamps, instead of source-record time stamps when mapping to the created tasks.
We needed to make modifications to use a Query task to grab all associated tasks and task templates on the target record, and call two workflows against each to force updates to the Planned Start and Planned End dates within the context of their associated calendars. Moving forward, the application now correctly applies the task calendar hour restrictions to the tasks and task templates when using the “Apply Template” and “Apply Record” functionality with capital projects.