We are using TRIRIGA 3.5.2. We are currently experiencing an issue with lease document attachments. When one user uploads a document that has the same name to two different lease records, the document record is overwritten.
The issue stems from the fact that the upload functionality defaults the path to \ROOT\Object Attachments\[Employee Name]\triRealEstateContract\[File Name]. There is a folder ID parameter in the action URL, but it doesn’t seem to work. Is there a way for TRIRIGA to create a folder based on the current record ID instead of the BO name?
[Admin: To see other related posts, use the Document Manager tag.]
In this day and age, security is a very hot topic. As soon as one vulnerability is addressed and mitigated, another one is found. It is a vicious circle of identifying and addressing vulnerabilities that does not seem to let up. In our fix pack release notes, information regarding the mitigation of vulnerabilities that were addressed without an APAR is listed. And sometimes, a vulnerability is addressed as an APAR.
The reason I am mentioning security vulnerabilities is that sometimes, when they are resolved, there is an impact on existing functionality, which may not always be clear. Sometimes, the result of fixing vulnerabilities can “change” functionality. As an example, in the TRIRIGA 3.5.2 release, external URL navigation items will now open in a new window to avoid cross-origin scripting vulnerabilities…
As the product develops and security vulnerabilities are found and addressed, it could mean a change in how something works. Reading the release notes can be a source of information, but it may not always be clear why something changed. We all know change is hard, especially when we are so used to it working in a certain way. I don’t know about you, but if the change was made to address a security vulnerability, I can live with that and accept the change.
[Admin: This post is related to the 04.07.17 post about APAR IV94912 where “External URL” navigation items may no longer work. To see other related posts, use the Security tag or Vulnerability tag.]
We are looking for an approach to the above issue which will keep the page alive. We have tried alternatives such as explicitly calling a data source. And we are looking at handling session cookies.
The UX app can make sure it does not time out by making a call to a specific end-point. You can make an Ajax call to the following URL, which will update the last access time and keep the session alive:
[Admin: This post is related to the 05.08.17 post about keeping the UX app session alive and connected. To see other related posts, use the Timeout tag.]
After applying the TRIRIGA 184.108.40.206 fix pack, if you have an editable query with at least 10 filter columns, when you filter on the report, you will get the URL error.
We needed to implement the same code from viewPageReport.jsp to viewPage.jsp. Moving forward, we resolved an issue, where filtering on an editable query will make the URL big enough to break the specified limit for URLs on Internet Explorer.
[Admin: A similar article is also posted in the IBM TRIRIGA blog. This post is related to the 05.18.17 post about reports with filters creating long URIs in 220.127.116.11. To see other related posts, use the Filter tag.]
It looks like TRIRIGA 18.104.22.168 changed the way that reports are generated. After we enter a user filter and refresh, a very long URI is generated, which causes an error on the IBM HTTP Server: “Request-URI Too Large”. Previously, with an OOB query, the URL might look like: /html/en/default/reportTemplate/viewPageReport.jsp. But now, the URL is excessively long.
It looks like the filter details were sent in as headers to the server. But now, they are included in the URI. This is a major change for a fix pack and I believe that it shouldn’t have been included. This pretty much limits the number of columns and user filters that a report can have. Our environment is hosted by IBM and we don’t have access to the back-end server.
We will be addressing this issue in our next fix pack.
[Admin: This post is related to the 05.26.17 post about getting an error that the URL is too large for queries with filters. To see other related posts, use the Filter tag.]
Some of our Admin users need access to the Admin Console to monitor different parameters from there. On the other hand, they must not login to TRIRIGA (or access direct URLs) with business data with Admin access. Is there a way to do this?
Currently, a user must be part of the Admin Group to access the Admin Console page. Please create a request for enhancement (RFE) with business justification and it will be reviewed by the TRIRIGA team.
I have installed TRIRIGA 10.5.2/3.5.2 OOB in Sandbox 1. One thing I noticed is that I used to be able to run the TRIRIGA service as “SVC-CBRES-IWMS-DEV” and I used to display the following in a web page, but in 3.5.2, I am not getting the expected “Sign In Required” error.
In TRIRIGA 3.5.2, a security change was filtering out the Performance Monitor (Single Values) URL. We needed to remove the filtering of monitor.jsp. Moving forward, a security issue was fixed which made the performance monitors unable to work externally from the TRIRIGA Admin Console.
[Admin: This post is related to the 04.08.15 post about performance monitoring tools.]