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?
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.
After changing the name and copying a template, the name change is saved in the database for the copied template. However, it displays a “Copy of” the original name. In other words, the name stored in the database is different from what is being displayed in the TRIRIGA interface. So when you copy a template, it fetches a different name from the database and concatenates “Copy of” with that name. This seems incorrect from the front end.
Moving forward, we fixed an issue where the capital project template name was modified and then copied, but the copied template was not created with the modified name. This happens only for non-US English users only.
[Admin: To see other related posts, use the Templates tag.]
A non-English user puts a negative sign on the existing currency amount. Save the record. Navigate away and go back to the tab. A MID error occurs.
[Admin: To see other related posts, use the Currency tag.]
Our client’s tabular metric reports, which are set to show the tasks of service requests, seem to have some issues. Although the tasks are found by the report, they don’t always show up or aren’t displayed on the list.
Here are two examples below: (1) In the first case, 6 tasks are found, but only 2 of them show up. (2) In the second case, 3 tasks are found, but none is displayed. Any ideas on what could be happening?
It seems that the user’s language (set in his profile) and the existence of a contract for the tasks affect their visibility one way or another on the tabular report. Here’s an example below: (1) When the user’s language is set to EN (English), all of the tasks show up fine. (2) When the user’s language is set to FR (French), only tasks which have a contract show up (in this case, only 1) even though all 8 are found…
Changing the language of the “System-Help” form breaks it…
This is because the new language is appended to the end of the publish name. This means that when it looks for the publish name of “System-Help”, it can’t find it. Additionally, changing it back to US English does not resolve the problem, since it appends yet another language name to the publish name.
A query generates multiple SQL statements that translate the UOM for every line in the report, when the user is in British English. The report template executes the exact same SQL over 3000 times.
The report runtime engine needed to make a call to get UOM data from the cache, not query the database. Moving forward, UOM values used in queries and reports are now read from the cache. Previously, they would be queried from the database, leading to a slight performance hit.