UX: How do you create an editable query by using the UX framework?

What is a way to create an analogue of an editable report using UX framework?

You can accomplish this by doing the following:

• 1. Create the query data source.
• 2. In the code, create an iterator over the data (dom-repeat or iron-list).
• 3. Either add a button for saving, or catch the on-change event in order to commit the data to the database by using the triplat-ds updateRecord method.

In newer platforms, you can look into triblock-table as well. I’ve never used it, but you can definitely create custom components inside the cells in order to make displaying data easier.

[Admin: To see other related posts, use the UX Framework tag or Perceptive tag.]

Why is the lease record stuck in “Processing” during activation?

We are running TRIRIGA 10.5.2 and 3.5.2.2. Some of our lease records are getting stuck in “Processing” status after we try to activate the record. Since it is processing, we have no buttons at the top to Revise, Save, etc. This only happens sometimes, and only to lease records that have payment schedules. From the looks of it, all the payment line items do get created. A couple questions:

• (1) Is there a fix to this to keep it from happening again?
• (2) Can these records that are stuck in processing be pushed to active or do they have to be re-entered?

I was actually able to apply a workflow fix provided by IBM so that this will not happen going forward. So far, it has been working as planned…

With regards to getting the leases “unstuck”, I created an editable query, imported the State Transition Actions (on the Advanced tab in the query form), and ran the report to select and process the “stuck” leases. This worked with no issues and I did not have to delete or retire the leases. They were functioning properly after getting them out of the “Processing” state.

[Admin: This post is related to the 01.12.16 post about records getting stuck. To see other related posts, use the Performance tag or Workflow tag.]

IV97185: User session terminated due to missing security token

In TRIRIGA 3.5.2.2, the user’s session was terminated by the server due to a missing security token on the request when interacting with forms and large queries.

We needed to add a TRIRIGA security token to two locations in the reporting engine. Moving forward, we resolved an issue that could cause a user’s session to be terminated if the user interacts with an editable query before the query has finished loading.

[Admin: To see other related posts, use the Tokens tag or Editable tag.]

How do you change or reset the “System” user password?

We are running TRIRIGA 3.5.2.1 platform and TRIRIGA 10.5 application. We have a requirement from our customer, for Sarbanes-Oxley (SOX) compliance reasons, that we need to change the “System” user password in TRIRIGA. We have done this in the past. However, the old option now appears to have become read-only, so we can’t do it the same way. Any ideas how we can update this password now?

Here are some things that might be preventing you from updating the password:

• 1. The logged-in user does not have security access to update the password, or a workflow has triggered on the record that has modified the metadata, and made the password fields or its section non-editable.
• 2. The record is in a state that only supports read-only actions. This makes the record non-editable.

Therefore:

• If you are logged in as Admin and cannot modify the password, I’d confirm that the System user is still part of the Admin group.
• If you are trying to change the System password as another user that is not an Admin, I would put that user in the Admin group temporarily to see if this gets past your issue.
• If you can confirm that a user in the Admin group cannot modify the record, I would look at workflows that are changing the metadata and the record state.
• If you cannot access the account as the System user, you can temporarily clear the System password to blank (null), so that you can login as Admin and reset the password. For example, via an update SQL script: 
  • update user_credentials set password = null where user_account = ‘system’.

[Admin: This post is related to the 04.18.16 post about resetting a user’s password as an administrator. To see other related posts, use the Password tag.]

Is there a way to set editable fields to be read-only conditionally?

I’ve noticed that if the record is read-only in its current state, we can still edit this record via the editable query. Is it possible to set editable fields, or the whole record, to read-only conditionally? For example, according to status?

Unfortunately, the platform does not handle this requirement. I would recommend adding a request for enhancement (RFE) for consideration in a future release.

[Admin: To see other related posts, use the Editable tag.]

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

IV94670: Read only access carries over to editable records

There are 2 project records that a user is trying to access. Project 1 has read-only access for a particular security group (Security tab of the project). Project 2 security does not have read-only access (Security tab of the project). The user in the security group logs in and accesses Project 1. The record is read only, which is correct. Now, the user accesses Project 2, which should be editable. It is not. It is still read only.

Moving forward, an issue that could cause user permissions to be reduced to read-only after viewing a read-only project record has been resolved. A previous workaround of clearing the security cache to reset the permissions level is no longer necessary.

Why aren’t the locator fields in editable queries populated in 3.5.2?

After upgrading to TRIRIGA 3.5.2, we are facing an issue on editable queries, where the locator fields are not populating after selecting a value from the popup query. Also, it logs out after we select a value, click “OK”, and refresh. Has someone faced the same issue? Or is it a known issue?

This issue is resolved in the 3.5.2.1 Fix Pack and is now available on Fix Central. The readme file for 3.5.2.1 can be found here.

Having an issue with editable queries and SQL queries in 3.5.2

I’m having two issues which I think are related. The environment is running Windows with SQL Server 2016.

• 1. In editable queries, I have a locator field, and I pick from the locator query. But after I click OK, my session times out, and it doesn’t save the changes. This affects all browsers: Safari, Chrome, IE.
• 2. In the Admin panel, if I have comments in my SQL query, the query now fails. For example… “SQL SCRIPT IS NOT VALID SELECT STATEMENT, PLEASE REVISE.”

What I noticed is that I get the same error in the error log when using the locator field in an editable query. Something seems to be failing related to SQL queries. Can anyone reproduce this issue? This is a critical failure in our upgrade tests and I will most likely submit a PMR for a patch.

IV91442: All data is lost when entered into editable query field

Entering too much data into a text field of an editable query, results in the data being lost without warning on the save of the action.

Some aspects of the problem described in APAR IV82511, which were supposed to have been fixed in 3.5.1, are still happening in 3.5.1.2. In the case where too many text characters are specified for a field, it makes sense that the text would be truncated, but that truncated text should be written to the record, regardless of whether it is entered through the record itself or an editable query.