I installed a new version of TRIRIGA Platform 3.5.3 and Application 10.5.3. I set up the IBM TRIRIGA Connector for BIM (Autodesk Revit) and CAD Integrator, and the environment is localhost:8001. But when I try to login to TRIRIGA from Revit, I get an error. Any ideas what’s going on here? It can’t be an issue with naming, because this is a fresh unconfigured application.
Verify the OSLC_BASE_URI. You can also turn on Fiddler, and verify that the URLs being sent over are valid URLs (including any port numbers) to connect to TRIRIGA from Revit.
[Admin: To see other related posts, use the BIM tag, Revit tag, or Fiddler tag.]
We turned on the SSO in our environment. (1) If we want to connect to one of the forms on our system, it shows us that we need to login first. (2) But if I use the link in the email notification that TRIRIGA sent out, it will login and open directly. What’s the difference between these two methods? Is there a way to open a form directly without login?
Because the URL that is being used is an “anchor” (it uses the # character to define the parameter), it isn’t possible to use that in an SSO environment. So you need to determine what the underlying WebProcess.srv call is to that form. For example…
[Admin: To see other related posts, use the SSO tag.]
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 18.104.22.168 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 22.214.171.124. To see other related posts, use the Filter tag.]
It looks like TRIRIGA 126.96.36.199 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.]