If you create a location and it already exists, the hierarchy path originally created remains the same. Go to Locations and enter a location that already exists. Note the hierarchy path. You will receive a message that the record already exists. Change the location name. The hierarchy path does not change. It remains with what existed before.
When entering a location that already exists, the hierarchy path remains the same when the name is changed. The issue is that the System Date field is not being correctly marked as “dirty” (modified) from user changes to correct record name conflicts. Moving forward, we resolved an issue for certain hierarchy records where the path field was not being correctly updated when correcting name conflict errors.
[Admin: To see other related posts, use the Hierarchy tag.]
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.]
Manually typed dates do not take into account the user’s date-time preference in the Gantt scheduler.
We needed to specify the EditFormat element, in addition to format, when applying the left-column metadata to the date fields. Moving forward, manually editing dates will now take into account the user’s date-time preference in Gantt.
[Admin: To see other related posts, use the Gantt tag.]
When the user go through the Object Label Manager to access a form and change the name. The system allows you to name it the same as another form, resulting in duplicate form names. There is currently no error handling for this. Meanwhile, if you access the form from the Form Builder itself and try naming it the same as another, the system will give you an error.
The issue was that the link into Form Builder from Object Label Manager’s Labeled Objects tab was not passing in the module ID and the BO ID for the form, thus the unique name validation for the module was failing to occur. This fix obtains the the module ID and BO ID for the form selected and correctly passes it to Form Builder. Moving forward, we resolved an issue in Object Label Manager, where opening a form from a link under the Labeled Objects tab would allow a user to change the name of the opened form to a name that already existed in the form’s module.
[Admin: To see other related posts, use the Object Label Manager tag.]
When trying to edit the mapping of a locator field within Data Modeler, the spyglass next to the field does not pop up the mapping window.
[Admin: To see other related posts, use the Firefox 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.]