Q&A on 10.8.1 Release Notes

This Article includes questions we have received on the 10.8.1 Release Notes and our responses to those questions.

QMX-737:  Allow users to set timezone to be used in all sections but the process section (QM APPs)

Q. Is it true that an individual user can change the time zone settings for their individual accounts?

A. Yes. A new field (Timezone) was added to user accounts.  Each user can specify their own Timezone, depending on the location from where they operate.

Q. How are date and time stamps being captured in the audit trails and records when this is done?

A. All timestamps are now saved as UTC-0 in the database.  Each timestamp also has an offset value recorded (based on the timezone of the user who has performed the operation).  When a timestamp is displayed to the users, it is shown in the appropriate timezone based on the offset value stored with it.

Ex.:  If a user is in a UTC-5  timezone,  and performs an approval on 2020-02-02 10:00 (her time), the value stored in the database will be 2020-02-02-15:00 (UTC-0), and the offset will be -5.  When viewing the approval cycle in QM, the timestamp will be displayed as 2020-02-02 10:00 (UTC-5).

Q. What if users have different time zones on the same approval cycle?

A. Each step of the approval cycle will display its own specific timezone.

Ex.:  If a user has approved a document on 2020-02-02 10:00 (her time in UTC-5) and the next user has approved on 2020-02-02  9:00 (his time in UTC-8), the approval cycle will display as follows:

user A   - approved -  2020-02-02 10:00 (UTC-5)

user B   - approved -  2020-02-02  9:00 (UTC-8)

Q. What happens with data sets in regards to UTC changes?

A. Since all timestamps are now stored as UTC-0, every timestamp in the data sets is in UTC-0 making it easy to perform calculation and visualization of data regardless of each individual UTC used to record these operations. Customers can also choose to create custom reports with columns converting the timestamp values to the time zone of their choice.

Q. What about data that was recorded before the update?

Entries made before the update to 10.8.1 will retain their original value (which was recorded with the system UTC (UTC-5)).  The difference is that no "offset" is stored alongside, which means that no time zone conversion is made when these values are displayed in SOLABS QM. They are displayed "as is" with the UTC-5 time zone.

The only real impact this has on the data sets (reports) is that it creates a cut-off point where timestamps recorded before the 10.8.1 update are in UTC-5 and timestamps recorded after the update is in UTC-0. This could be handled using custom reports and applying time zone modifiers to either convert previous timestamps to UTC-0 or new ones to UTC-5, depending on the customer's preference.

Q. Can this feature be deactivated so that users do not have this choice?

A. Currently, it is not possible to disable this feature.  Users could all be attributed the same time zone as the system (UTC-5) to make it behave like it previously did.

Q. Does the time zone feature affects the core and document datasets only, or will this apply to the process-related datasets as well?

A. The changes were made for the core datasets and P0007 Document control process datasets only.

Q. How are date and time stamps being captured when the system does an operation?

A. All timestamps are saved as UTC-0 in the database.  Each timestamp also has an offset value recorded (based on the time zone of the server.  All servers are currently in UTC - 5). 

QMX-995: Correct an issue with the default assignment handler for QM APPs.

Q. Can you give more details on this one?

A. When a process task was assigned through the default assignment handler, a "Reassigned Task" entry could sometimes be created in the Audit Trail (which was not true since it was the original task assignment).  It is good to note here that since most QM APPs use their own Task Assignment Handler, very few QM APPs are impacted by this. (Customers impacted by this specific change will be informed.)

Q.  does this change impact my current QM APPs?

A.  No this handler is new and not currently used by any released QM APPs.

QMX-1045: For clients using the Auto-Populate Feature, a Date Picker & Plain Text content control has been added.

Q.  What do the Date picker and plain text control do?  

A. This is for customers using the Auto-Populate feature.  When creating a template document, Date picker and plain text controls can be added to a document in order to be auto-populated based on values entered in the system.  Date picker would handle values that are saved as dates and timestamps in the system, while plain text controls would be for most other types of data (strings, numbers, etc.).

Refer to the documentation on the Auto-Populate feature for more details.

QMX-1152: Correct indentation issue in value display for Multi-item Selection fields.

Q. Wasn't this already fixed in our environments?

A. This was fixed through the corrective release 10.7.0-2 which was done during the development of 10.8.1. Every customer already on 10.7.0 was updated with the fix, but the fix also had to be applied to the main branch of the Core files to make sure it is included in versions 10.8.1 and above.

QMX-1156: Update to Retire cycle. (Approved, Not Effective versions of documents would be
lost when the documents reached the Awaiting Retire Date state.)

Q. What does "lost" mean?  What was the update that was made to address this issue? 

A. When a document enters the Awaiting Retire Date state, all the "In Process" versions for this document (retiring history) were cleared up.  Since an "Approved, Not Effective" version of a document is also considered "In Process", it was cleared up at the same time.   The fix simply made sure not to remove the "Approved, Not Effective" version if one exists.