Why is a cost code path corrupted when applying a template?
We have an issue where sometimes after applying a cost code template to a project, the hierarchy path will not be complete. It will be missing all of the parent path and only shows the name. This issue is only visible in the app by viewing the System Path field inside the form or by using a SQL query, because the system path in the T_TRICOSTCODE table is correct, but the object path field in the IBS_SPEC table is the one that’s not complete. The issue does not have much consequence unless you are using the rollup fields, in which case the corrupt cost code path will cause a posted transaction to fail.
If there are customers who use cost codes heavily, you can try running the following SQL, and if you get any results back, then that means the issue is present at some level in your environment. It is not necessary that you use the Apply Template to create your cost codes, as I have heard of others having the issue where their cost codes are created via an integration. This SQL is for Oracle and may need a tweak for SQL Server. If any customers can run this, and see if they have the issue, it may help us identify how it happens.
How do you add another level in the Geography hierarchy?
We are on TRIRIGA 3.5.2 and 10.5.2. We have a business need to add another level in the Geography hierarchy (under City). Technically, it is possible to change the hierarchy to add another BO associated to the triCity object. But we wonder if there is an impact on the standard behavior of TRIRIGA? If not, then what is the best method? To create a new BO? Or to create a city hierarchy under the city like a space under space? Has someone already done this kind of modification?
Creating a new BO would be the usual method. You would need to be sure that you create the parent/child association so that you locate the new BO type in the hierarchy. For the most part, the workflows in Location are BO level, but it would be useful to review your environment to see if any customizations have been made.
What is the best practice for deleting or retiring records?
I have some records in the classifications hierarchy. These classifications are now associated to several BOs, like building equipment and tasks. I want to delete some of the values in the classification hierarchy because they are values we do not want users to use in the future. I understand that the best practice is the change the status of the record to “Retire” for audit purposes. But if we decided to just delete those records, what is the impact to any of the associated BOs? Would I have to create a workflow to remove the associations?
There are certain classification records that are used in forms, workflows, and/or queries. If you delete one of these records that are used in the application, you will in effect, lose some application functionality. Take, for example, “triClauseType” (Lease Clause), where several of these classification values are used on the Lease Clause form to determine which sections of the clause to unhide.
I suggest a best practice would be to look in the Data Modeler for the business object of the classification you want to delete records on. Select the triNameTX field and click ‘Where Used’. If nothing comes back you should be pretty safe to make changes to that classifications record list (add, delete, modify). If you see any workflows, queries, forms, etc., come back as using this field, you’ll need to analyze each to determine if your business needs them. However, I’d suggest pushing back against the business and advise that the application requires the values in question.
Why can’t a non-Admin user see reservable spaces in organization?
We have some reservable spaces with system geography and system organization settings. A non-Admin user also has the same geography settings. There are security groups for reservations, and organizations and geography security groups are assigned to him. The geo and org security groups have the same geo and org as the space and profile. But the non-Admin user still isn’t able to see spaces.
He is only able to see them when the first level of the org hierarchy is provided in the group (i.e. \Organization). But as soon as the second level is given in the group, he isn’t able to see them. Can anyone help me on this? I think there is some issue in the org, but I don’t know exactly where it is.
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.
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.
Users navigating to a hierarchical query of building and asset records have experienced user kickout (or timeout) behavior when entering or clearing filters.
We needed to prevent the load of a large hierarchical query with runtime user filters in a portal section that kicks the user out. Moving forward, we resolved an issue that could cause a user’s session to be terminated if the user interacts with an hierarchal query before the query has finished loading.