In January 2020, IBM developerWorks displayed the following banner message:
“The developerWorks Connections Platform is now in read-only mode and content is only available for viewing. No new wiki pages, posts, or messages may be added. Please see our FAQ for more information. The developerWorks Connections platform will officially shut down on March 31, 2020 and content will no longer be available. More details available on our FAQ.“
Where is the Compatibility Matrix going to be relocated?
(1) In February 2020, the Compatibility Matrix and several related pages were officially relocated to IBM Support as follows:
(2) Since January 2020, the above information is also available in the independent (or backup) wiki:
- TRIRIGAFEEDIA Wiki
- Note that this wiki may or may not contain the latest updates, but it strives to do so.
[Admin: This post is related to the 11.14.14 post about the latest Compatibility Matrix. To see other related posts, use the Matrix tag.]
Continue reading →
When trying to upload a file type that should be allowed based on the contents of the INCLUDE_EXTENSIONS and EXCLUDE_EXTENSIONS lines, the user gets a message stating that uploading a file of that type is not allowed. Why?
Adding spaces in the extension list will invalidate any other defined value after the first one listed. In the TRIRIGA 3.5.2 and later releases, more variables were added to the TRIRIGAWEB.properties file, for more-precise control over what can be loaded as an attachment to a record, or added to Document Manager. These variables are documented in the TRIRIGA Release Notes, but to give the basic information, these are the two new sets of variables:
- COMPANY_FILE_UPLOAD_EXCLUDE_EXTENSIONS and COMPANY_FILE_UPLOAD_INCLUDE_EXTENSIONS
- IMPORT_CONTENT_EXCLUDE_EXTENSIONS and IMPORT_CONTENT_INCLUDE_EXTENSIONS.
Any file extensions can be added here, but the format of the list needs to be properly set. Use only comma-separated values (CSV) without spaces to build the string. If there are any spaces in the list, remove them…
[Admin: To see other related posts, use the “include_extension” search phrase.]
Is there a way to clear server caches without logging into the Admin Console?
Beginning in IBM TRIRIGA Platform 3.5.1, TRIRIGA delivered an enhancement for this to be done via workflow. The pertinent release notes can be found from this wiki page. Here is an excerpt from the release notes on the topic:
A custom task class has been added for workflow which triggers a global cache clear across all servers.
You can create a custom task and specify the following in the class field: com.tririga.platform.admin.cache.web.CacheProcessingCustomTask $RefreshAllCache
The custom task will perform a global cache clear on the server where the workflow runs as if it were triggered from that server’s Administrator Console. (Tri-211723)
[Admin: To see other related posts, use the Admin Console tag or Cache 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 currently using TRIRIGA 10.5.1/18.104.22.168. 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 22.214.171.124 and 126.96.36.199. 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 188.8.131.52, 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.]
Is anybody seeing this issue in TRIRIGA 3.5.2? The Release Notes say that:
“The inner Save action on the Access tab of the Security Manager is removed. The user can make multiple permission changes, mix them with general changes and member changes, and save all at the end with the Save or Save & Close actions.”
But this doesn’t seem to work. Why not?
[Admin: This post is related to the 03.07.16 post about best practices for managing your security groups.]
How do you run the MS SQL “SetVarcharColsToNumeric_MSSS.sql” and “SetVarcharColsToNumeric_MSSS_Publish_BO.sql” scripts after upgrading to TRIRIGA 184.108.40.206? According to the TRIRIGA 10.5.2 and 3.5.2 release notes:
- “There are two scripts for MS SQL, SetVarcharColsToNumeric_MSSS.sql and SetVarcharColsToNumeric_MSSS_Publish_BO.sql. Run SetVarcharColsToNumeric_MSSS.sql first. When it completes, run SetVarcharColsToNumeric_MSSS_Publish_BO.sql.”
- “Run the script PRIOR to installation of IBM TRIRIGA Application Platform version 3.5.0. NEVER run the script after upgrading to 3.5.0.”
Our application is 10.4 and platform is 220.127.116.11. How can the SQL script be applied to update the system fields with the sub-attribute type of CreatedDateTime to CreatedDateTime (Number) and ModifiedDateTime to ModifiedDateTime (Number)?