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.

[Admin: To see other related posts, use the Geography tag or Organizations tag.]

Continue reading

Advertisements

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.

[Admin: To see other related posts, use the Classifications tag or Hierarchy tag.]

Continue reading

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.

[Admin: To see other related posts, use the Geography tag or Organizations tag.]

Continue reading

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

IV97468: Location hierarchy path does not update if location exists


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

Continue reading

IV97203: Hierarchical query for buildings with assets ends session


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.

[Admin: This post is related to the 06.19.17 post about a user session terminated due to a missing security token. To see other related posts, use the Filter tag.]

Continue reading

Do you need to clear server cache if floor plans aren’t visible?


After performing a TRIRIGA platform upgrade, some of the floor plans are not visible in the forms. Why aren’t they visible?

The TRIRIGA server cache needs to be refreshed. In other words, you need to clear the caches and restart the server. Here are more-detailed steps to clear your TRIRIGA cache and log folder:

  1. Login to the Admin Console.
  2. Go to the “Cache Manager” managed object.
  3. Click on the “All Caches (Global)” link and then “Hierarchy Tree Data – with rebuild” link. The process might take some time.
  4. Go to the “Database Manager” managed object, and click on the “Reprocess published drawings” link. Give the process some time to finish. Go to the current server log, and look for a related entry saying that the reprocess published drawing actions are finished. You will find a message similar to the following:
    “INFO [com.tririga.platform.graphics.vector.drawing.DrawingService](http-0.0.0.0-21001-7) Finished re-processing drawings”
  5. Logout of the Admin Console.
  6. Stop the TRIRIGA JVMs via the WebSphere Admin Console.
  7. Delete the logs in the <TRIRIGA install>/log folder that has server.log.
  8. Clear the WebSphere temporary cache folder.
  9. Restart the TRIRIGA JVMs via the WebSphere Admin Console.

[Admin: This post is related to the 07.15.16 post about floor plan graphics disappearing after an upgrade, and the 09.29.14 post about clearing the TRIRIGA application server cache area. To see other related posts, use the “floor plan” or “clear cache” search phrase.]

Continue reading