I’m seeing issues within report results, where if the user profile language is in US English, the results are of one type, but if the user profile language is in German, it is showing some other data. The record while checked is the same for both cases. While opening and checking the record, the ID and name of the record varies from what it showed as a result in the report. While investigating, what we observed is that these fields are marked as “Localizable” in Data Modeler. What is the use and impact of the “Localizable” field property? Any suggestions?
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.
[Admin: To see other related posts, use the Reservation tag.]
Various existing users with non-US English language profiles are getting the following error when they click on the System tab on each form:
An Error Occurred. Contact your System Administrator. – [MID-3402867005]
When translating object references, the platform needed to catch the “smart object not found” error, and follow the path as if it was non-translated. Moving forward, when invalid data is contained in a reference field (like System Geography), the platform will no longer throw a MID error, and will now show the field as blank, since the referenced record does not exist.
I am trying to configure SSO with WebSphere Liberty (on RHEL 6.8 and TRIRIGA 10.5.0/3.5.0) with Active Directory. Once configured, I get the Windows authentication popup. It accepts my domain credentials, but instead of taking me inside the application, it takes me to the login page, where I have to input my local TRIRIGA profile login details. Can someone help me with this?
After removing a security group from the user profile, the user can still be found listed in the security group when you check it on the Security Manager.
We needed to delete the smart section, not just the BO. Moving forward, an issue has been fixed where the Security Manager “Members” tab is out of sync with the user profile “Security” tab when the user is removed from a security group via the user profile.
How do I address the cause of currency conversion exceptions that are appearing in my TRIRIGA server.log file so they stop being logged? The exception can occur as a result of currency conversion being done when a user profile has a different currency than the base currency. Here are some examples of the exception seen in the log:
Error in Conversion from >CHINESE YUAN RENMINBI< to >US Dollars< . Using conversion rate of 1.
Error in Conversion from >NIGERIAN NAIRA< to >US Dollars< . Using conversion rate of 1.
There are generally two ways to resolve this:
- 1. Add currency conversion values to allow the currency conversion to take place. The documentation can be found in the IBM Knowledge Center: Currency.
- 2. Confirm every user profile has the same currency as the base currency. The base currency is defined in the TRIRIGAWEB.properties file.
Also, check for duplicate UOM values for currency. This could explain the exception if the first two options fail to resolve the problem…
When a user cuts-and-pastes a location from one hierarchy parent to another, it still references the old hierarchy path. This happens to other languages, for instance, British English. However, when you change the user profile setting from British English to US English, the hierarchy path is updated correctly.