A navigation item whose target is set to “External URL” and whose URL links directly to a folder no longer works. An error such as the following might occur: “An error occurred, please contact your system administrator: [MID-4077624314].”
The Java applet that uploaded documents based on the navigation item target in earlier TRIRIGA versions is deprecated due to security concerns. Most browsers no longer support Java applets. The applet upload function is replaced with an HTML5 upload function.
As a result of these changes, “External URL” navigation items in earlier TRIRIGA versions that successfully uploaded documents via portals to upload documents to a folder might no longer work. The Document Upload widget was redesigned to be used only in the context of either Document Manager or a record, not a portal. Use Document Manager directly to upload documents.
[Admin: This post is related to the 04.07.17 post about “External URL” navigation items that may no longer work, and the 07.10.15 post and 04.10.15 post about the document upload enhancement. To see other related posts, use the Document Manager 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.
The “Location – Navigation – GIS – Buildings, Structures, and Retail Locations – Project Manager Query” was configured with an incorrect forward association string, that prevented capital project locations from displaying on a GIS map. Moving forward, the Advanced tab > Geography Module > triCity Business Object association filter had its forward association string updated to “Geography Contains” from “Geography Belongs To”.
[Admin: To see other related posts, use the GIS tag.]
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.]
The pie chart labels should actually be hidden, and not appear at all for the smallest portal section. Users should rely on tooltips for the smallest portal section. The reason labels were always meant to be hidden is because they make many pie charts unusable in the smallest portal section, due to labels bunching together in the small space. The smallest portal section should always hide the pie chart labels.
The hiding of the pie labels for the smallest portal section broke when AnyChart was upgraded in TRIRIGA 3.5.0. Moving forward, we resolved a metric report and chart report issue, where pie chart labels were chopped off in the smallest portal section. This fix hides pie chart labels when the TRIRIGA component that displays the chart falls below a height of 280px and a width of 280px, such as the smallest portal section. Pie labels become unusable when pie charts get too small. So users should rely on pie chart tooltips for the chart details, when the labels are hidden.
[Admin: This post is related to the 04.14.16 post about changing the AnyChart label settings. To see other related posts, search “Pie Chart“.]
Sometimes, a user that supposedly has licenses for a form or portal is not able to see the form or portal. So how do you determine if some license is missing, or if the licenses you have are enough? This question often comes up when users start reporting that they cannot access portions of the application and call in to complain.
The best way to check it is to login as an Admin user, and follow these instructions:
- Go to Tools > Administration > License Manager.
- Click on the “Matrix View”.
- Use the browser’s “find” function to look for the form or business object.
- The necessary licenses are marked with a check (or R for read-only).
[Admin: The same article is also posted in the IBM Support Portal as a technote. This post is related to the 02.08.16 post about finding information on TRIRIGA licenses. To see other related posts, use the License tag.]
We are currently using TRIRIGA 10.5.1/220.127.116.11. If a particular portal section with a report has a result set of more than the property “Max Records Displayed”, then the results are not shown, and the portal section just keeps loading. Why?
However, the behavior is fine if the results returned are within the limit set in the portal section. Also, when the section is maximized, we can see all the results. It works in the case of a hierarchy query too.
We had a defect/APAR where the Max Records Displayed parameter was being ignored, and the entire result set was being pulled back. The issue is resolved in 18.104.22.168 and 22.214.171.124. Here is the release note: “Portal section queries display the maximum results that are specified in the Portal Builder. (Tri-237640-IV87771)”
I believe this fix will resolve your problem. In 126.96.36.199, queries are returning the entire result set, and are not stopping at the max count. My recommendation is to upgrade to the the fix pack with this fix, and see where you stand after that.
[Admin: This post is related to the 08.16.16 post about portal sections not showing the defined number of results. To see other related posts, use the Portal tag.]
Panels that didn’t have vertical scrolling in-frame now have vertical scroll bars. That is, they are not presenting the whole information within the visible area as before. Frames and portal sections are not sized correctly and some clickable areas might not work until some other action is performed. This is a change in behavior from TRIRIGA 3.5.1 to 3.5.2 when this behavior could be observed for customized forms.
Internet Explorer does not correctly calculate the new height of the content internal to the portal. We needed to rework the logic to resize to the actual content size. Moving forward, an issue that caused an extra scroll bar to appear when rendering a record in the portal has been resolved.
[Admin: To see other related posts, use the Portal tag.]