I have a few questions from our customer about TRIRIGA reports:
- Question 1: We want to create a report to show the triProperty which has more than one triBuilding as children. By using an association filter, we can only show the triProperty which has at least one triBuilding. By using a summary report, we can group by triProperty to show the number of triBuilding it has, but we can’t add another criterion based on the “Number” column. So, both two solutions above don’t work.
- Question 2: How can we do something like a “left join” in a multiple-BO report? We have noticed that the behavior of multiple BOs in a report acts more like an “inner join” query. The filter based on the secondary BO will also impact the primary BO result. Do you know any way to get a “left join” result in TRIRIGA?
- Question 3: How can we share a list of reports with users who are members of a specified security group? Our customer doesn’t want to grant the access of the “My Report” application for those groups, and they would like a solution that is more dynamic than adding those reports into the portal of the user. I don’t know if there is way to do this. Can the Admin user define a favorite list for the end users?
[Admin: To see other related posts, use the Reports tag or My Reports tag.]
Users navigating to a hierarchical query of building and asset records have experienced user kickout (or timeout) behavior when entering or clearing filters.
We needed to prevent the load of a large hierarchical query with runtime user filters in a portal section that kicks the user out. Moving forward, we resolved an issue that could cause a user’s session to be terminated if the user interacts with an hierarchal query before the query has finished loading.
[Admin: This post is related to the 06.19.17 post about a user session terminated due to a missing security token. To see other related posts, use the Filter tag.]
When using a query and applying filters to classification or business object type fields, there are instances in which the data may not filter as expected. This can happen when the referenced classification or business object records are renamed, and the query is filtering on those name values. To summarize the scenario:
- (1) A user creates a record that contains a classification field, and populates that classification field with a value.
- (2) Another user changes the name of the classification record, which was used to populate the field in #1.
- (3) A user then runs a query that contains the field referenced in #1, and tries to filter values…
In order for filters to take effect for the most current value of a classification or business object type record when changed, records referencing those values in their fields must be updated. One approach to doing this is writing a simple workflow that updates the referenced data:
- Start Task: Workflow triggers on the classification object.
- Task 1: Gets the associated referenced object.
- Task 2: Clears the classification value.
- Task 3: Maps the classification field as the “Source” to the target field.
Note: For every object that the classification field references, the 3 tasks must be repeated. The workflow should only be triggered as an asynchronous process, since the workflow processing time will vary with how many records need to be updated.
[Admin: This post is related to the 06.08.17 post about SQL data not matching the viewed application data, and the 01.04.17 post about filters failing when using changed classification values. To see other related posts, use the Filter tag.]
Is anyone doing anything with barcodes in Facility Management Software (FMS)? We want to increase our efficiency in closing out TRIRIGA work orders. So we thought that if we put a barcode on every work order and somehow have it pop up the work order, then you wouldn’t have to search in a query filter.
[Admin: To see other related posts, use the Barcodes tag.]
Is anyone using the system organization for their security groups? We have noticed a problem to which IBM doesn’t seem to be giving enough any attention, and I’m wondering how many clients have even found this yet.
I posted the following statement in IBM developerWorks hoping to get some attention. We are starting to notice a few areas where the SQL data doesn’t match what is viewed in the application. Here is an example:
- (1) First, you need a query that displays a list of leases and one of the columns is the system org. (Make sure that column has a user filter.)
- (2) Now, note the system org name on one of the records.
- (3) Go to that org record. Edit the org name (for example, add “test” to the end of it), and activate the org record.
- (4) Go back to that query.
- (5) The system org displays the new value on the lease and in the query.
- (6) Enter a user filter for “test” in the system org column. But the query doesn’t recognize the edit…
[Admin: The same question is also posted in the main Application Platform forum. This post is related to the 01.04.17 post about filters failing when using changed classification values. To see other related posts, use the SQL tag or Filter 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.]