Why are document attachments overwriting each other?


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.]

Continue reading

Advertisements

Changing functionality in TRIRIGA to fix security vulnerabilities


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.]

Continue reading

IV96587: Getting error that URL is too large for queries with filters


After applying the TRIRIGA 3.5.2.2 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 3.5.2.2. To see other related posts, use the Filter tag.]

Continue reading

Why do reports with filters create long URIs in TRIRIGA 3.5.2.2?


It looks like TRIRIGA 3.5.2.2 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.]

Continue reading

Is there a way to set Admin Console access without TRIRIGA access?


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.

Continue reading