Feeding your TRIRIGA information needs

Tag Archives: Geography

We are on TRIRIGA 3.5.2 and 10.5.2. I’ve recently noticed that in our security groups, there is now a “Location Name” field which is hidden. Is this a placeholder field for a future release? Or can we actually use this field to control data access?

No, record security is currently only supported on Geography and Organization. I am not aware of any current enhancements to add Location-based security.

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.

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.

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

We have a problem when we open a reservation from the calendar. It seems that when the user has a primary organization and he opens a reservation from My Calendar, the reservation window is opened, but it doesn’t show any information. However, if the user doesn’t have a primary organization, the reservation window is opened and it shows the information correctly.

When dealing with an organization, geography, and project security, you should use the user’s groups, not override groups. In Reserve, My Calendar, a user with an organization or geography is unable to open a reservation that was created. The security was not using the organizations or geographies from the user’s profile (groups) when determining the user’s access. Instead, it was using the overridden Reserve security group.

We manage properties globally so some of our locations are measured in Imperial and some are in Metric. What is the best way to manage this type of scenario so that our drawing and graphics section labels are not incorrectly sized when they are viewed from other global geographies?

The best way to address this situation is to have 2 sets of labels for your drawings, and 2 sets of labels for your TRIRIGA graphics section. You will need to adjust the height of the label elements to work for both situations. We are considering an enhancement to automatically scale according to the drawing units.

[Admin: To see other related posts, use the Graphics tag or the Labels 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.