We are encountering an odd issue with TRIRIGA SSO and Active Directory with Personal Identity Verification (PIV) cards for authentication. The issue occurs after a session timeout, when a Windows Authentication dialog box would prompt a user to enter either their pin code or their Active Directory login, in which the Windows security does not accept their credentials, even though the right pin code or username/password is used…
Upon clicking on the Cancel option in the Windows Authentication dialog box, a second window with a “401 – Unauthorized Access” error is displayed to the user with a link that allows the user to regain access to the REMS application. We do not see any significant errors regarding authentication on the TRIRIGA side. At this point, I am not sure if this is a IIS, Active Directory, or a TRIRIGA configuration issue, but any suggestions would be great…
The issue is that the user’s old session on the app server is invalid, and the app is passing a 401 header back through IIS, and onto the browser. The solution is to tell the app server not to send the 401 header. In TRIRIGAWEB.properties, set:
Scheduled events are not being removed by the Cleanup Agent from the table T_SCHEDULEDEVENTS after the scheduled events are completed. This causes this table to grow immensely, especially for companies that use recurrence events in their calendar. Identifying the records can be done via SQL…
The deletion of these records are currently not automated by the Cleanup Agent.
Moving forward, the completed scheduled events older than the value specified in the property CLEANUP_AGENT_SCHEDULED_EVENT_COMPLETE_DAYS will
now be marked for deletion.
If you run a report that has a Group By, the server settings to display button links will be ignored and display the OK-Export-Cancel as text links. The text is too small to read for some users on the environment.
We needed to be able to update the styles to action buttons. Action buttons in Group By queries will now honor the TRIRIGAWEB.properties setting for SYSTEM_ACTION_STYLE.
[Admin: The same article is also posted in the IBM Support Portal as a technote.]
When using Connector for Business Applications (CBA), the users are still being tracked in the SESSION_HISTORY table even though in the TRIRIGAWEB.properties file, there is a property SESSION_HISTORY_TRACKING, that when set to WEB_USER, is supposed to remove sessions from that table.
The user that is being used for CBA has a user count that is set to 50. When the user count = 1, everything works the way it is supposed to work. The issue shows itself when the user count = 50. As a result, there is a buildup of records inserted into the database, which causes the database to run out of space. So you have to manually delete the users from SESSION_HISTORY.
When you create a reservation, for example, a Location Reservation, some of the resources do not display on the Find Available Times tab of the reservation.
By default, only 50 rows display when the Find Available Times tab of the Availability section of a reservation is rendered. If there are too many results, a warning about exceeding the row size is displayed. Your administrator can change the maximum number of rows that display by changing the AVAILABILITY_SECTION_ROW_LIMIT property in TRIRIGAWEB.properties. As noted above, the default value is set to 50 rows. If set to 0, -1, or other invalid value, the default number will be used.
Warning: If the property is set too high, performance issues might occur when rendering. Large values might cause memory issues. It is recommended that you update the backing reserve queries to reduce results or design filters that keep the number of record results under this value. Any value above the max value of 500 will be set to 500.
I am running TRIRIGA Platform 3.5.2 (Build Number: 252769) and I have created a custom view called “njw-login”. This is listed in both the Web View Designer and the listviews command in WebViewSync. I have created some files for the view using the logintemplate command and pushed/pulled the files to make sure my local copy is in sync with the server. So, njw-login.html, njw-login-ui.html and the three images are listed as View Files for njw-login in the Web View Designer.
I updated TRIRIGAWEB.properties with the following line and restarted the app server (as the instructions placed in “njw-login” by the logintemplate command):
I checked that ALTERNATE_UX_LOGIN_VIEW only appears once in TRIRIGAWEB.properties, and I have also checked for white space at the end of the line. However, when I navigate to any of our UX apps, the standard TRIRIGA login screen is displayed. Additionally, the following line is added to server.log:
2017-01-02 15:06:46,463 WARN [com.ibm.tririga.platform.view.web.controller.WebSigninController](Default Executor-thread-16) The alternate UX login view njw-login does not exist.
Have I missed anything obvious?
[Admin: This post is related to the 03.22.16 post and 03.21.16 post about using an alternate login.]
A large export to Microsoft Excel may cause an out-of-memory crash on the JVM or server, or cause a zero-byte or seemingly-corrupted Excel (XLSX) file. When analyzing the heap dump file, you will see the following classes taking the most of the JVM heap dump space:
- (A) “com.tririga.architecture.web.process.useresponse.ExportExcell$2”, loaded by “<system class loader>”
- (B) “org.apache.poi.xssf.usermodel.XSSFRichTextString”, loaded by “<system class loader>”