Q&A on 10.8.0 Release Notes

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

QMX-923; QMX-988; QMX-989: New Single Sign-on for hosted clients. 

Q. How big is the impact here when the client is using OKTA? (Need additional info because currently, OKTA is SSO only for the software, not for SharePoint and eRoom. Need more details to be able to understand the impact.)

A. Not many impacts. OKTA implementation remains the same. i.e.: The users will access the system via OKTA authentication and e-Signature validation will be performed against OKTA, but accessing other SOLABS services like SharePoint and eRoom will still have to be done using the SOLABS QM Account.

QMX-1002: Administrators are now able to reset passwords for users with Database Account Types from within the application. This will facilitate password resets for users in Trial, Sandbox, and Validation instances.

Q. Client Validation instances are set to use Database mode. Then what is the impact for all clients?

A. No impact other than providing the ability to reset the passwords for accounts that are set to Database. Currently, it was not possible, and it needed to be done either via intervention or through a workaround (deactivating/reactivating users, or switching them to another authentication type, etc.).

QMX-814: Terminology changes.  

Q. Changes in Doc Control from "New, Review, Withdrawal” to “New, Revision, Retire”: Will these changes be applied to previously selected values in the database or only moving forward? What is the impact on reports and datasets?

A. “New, Revision, Retire” is only applied for DOC processes started in v3.1.0. Processes started in v3.0.0 won’t see “New, Revision, Retire” but the old choices "New, Review, Withdrawal”. Reports and datasets retrieve what is stored in the database. i.e.: Value of "Type of Change" of v3.0.0 would have "New, Review, Withdrawal” and value of "Type of Change" of v3.1.0 would have “New, Revision, Retire”.

Q.  Will my downstream reports be affected by this change?

A. They will be impacted if you have conditions that are using the values of these columns in your downstream report.

QMX-1042: The SSRS reports for Employee Training Compliance and Employee Training Compliance History are updated to add a column indicating which training confirmations are associated with a Cosmetic Change to a document.

Q. Does this change impact previously recorded data? 

A. Yes. The Cosmetic Change field not being a new field, the data already exists, it was just not displayed in the report.

QMX-1042: New Login Page layout.

Q. Does this impact clients using OKTA as an SSO provider? Does this impact clients using OneLogin as an SSO provider?  

A. Since OKTA bypasses the SOLABS QM login page, no impact is foreseen. For OneLogin, since the user's password needs to be synced between both systems, every time the password is updated on the OneLogin side, a user will have to log in through the SOLABS QM login page in order to update the password on the SOLABS QM side.

SQP-4605: Remove the Withdrawal option in the Type of Change list for the processes started in version 2.5.1 when version 3.0.0 is deployed. 

Q. Can you please clarify what this means for clients who would have started Doc Control processes in 2.5.1? Was withdrawal added to 2.5.1 workflows when it should not have been? What will be the impact of removing it? 

A. Version 2.5.1 doesn’t support Document Retired. When deploying version 3.0.0 which supports Document Retired, the choice Withdrawal was also made available for version 2.5.1 which is not correct. SQP-4605 wants to fix this problem, meaning that the choice Withdrawal won’t be available for processes version 2.5.1, only for processes version 3.0.0+.

SQP-4689: Modify the name of the option Review and Withdrawal in the Type of Change list to Revision and Retire.

Q. What is the impact on previous processes and data captured in the database?

A. Ref. to the explanation for QMX-814

QMX-290: If a process task was assigned to a Role that included more than one user, and the role was removed from one of the users, the reassignments actions were not done correctly.

Q. Can you provide more details on what "not done correctly" means? 

A. When a role was assigned to 2 users, and a process task was set up to be assigned to "any" user of that role, if one of the users was removed from the role, the process task ended up assigned to "any" user in "any" role.

ex.:
Assignee (Role): PR_Role
Assignee (User): any

But after removing the role from the user, when going back to Reassign task, the assignment would now display as:
Assignee (Role): any
Assignee (User): any

QMX-899: Process transactions could remain open behind the scenes even when no longer in use.

Q. Could you provide more details on the impact on end-users?  

A. When operations were made on the JBPM module (core component backing the QMApps), JBPM contexts and transactions are created to perform the operations. Sometimes these would not be closed appropriately.
End-users would never actually be impacted by this unless the system would end up in a state where it would no longer be possible to create more, though this never actually happened because of the SOLABS QM scheduled service restart.

QMX-928: Report Update to correct a possible issue in the STAGING_DocumentWorkflow table.
QMX-969: Report Update to correct an issue where the PSA_ProcessInstanceInformation was not appropriately dropped in the report script.
QMX-970: Report Correct a display issue when documents are at a status of Awaiting Retire Date.

Q. Issue and impact are not clear on those items. Additional information is needed to be able to understand the change and the potential impacts on end-users. 

A. QMX-928: The isUsingDueDate flag that was present in this table was loaded from the document's workflow template instead of from the specific document's versions to which it relates. So it would have been possible for this flag to indicate a value different than what it actually was if, for instance, the value was changed in the document's workflow template after a version of the document was made effective (an effective version would show the value of the workflow template instead of its own).

QMX-969: When report scripts are re-executed over existing reporting data, the jobs would output a warning since the PSA_ProcessInstanceInformation table was already existing (because it was not dropped first like it should have been).
QMX-970: When there is a version of a document that is currently Awaiting Retire Date, the previous version does not show the correct status in the Document Metadata DS and also shows Awaiting Retire Date instead of Approved, Not Effective, or Approved & Effective.
 

QMX-971: Update to ensure that when a user is deactivated, document workflow tasks are reassigned to ‘any’ user in the same role as that user.

Q. Issue and impact are not clear on those items. Additional information is needed to understand the change and the potential impacts on end-users. 

A. When a user that had completed document workflow steps is deactivated, going back into the document would show the step as if it was assigned to "Any" user instead of being assigned to the user as it was before the deactivation. The confirmation is still "signed" by the user, it's just the assignment that has changed.

QMX-994: Update to ensure consistency between the Reason for Change values for the document and the Doc Control Process.

Q. Issue and impact are not clear on those items. Additional information is needed to understand the change and the potential impacts on end-users. 

A. When a document that was linked as a reason for the change has a new version that is made effective the existing link with the process is broken (it loses its version) which prevents the process from moving forward. (Only applies to P0007 >= v3.0.0 )

QMX-1013: Setup Add a Modify option for deactivated users. 

Q. Issue and impact are not clear on those items. Additional information is needed to understand the change and the potential impacts on end-users. 

A. This is the opposite in fact. The "Modify" option has been removed for deactivated users, to prevent them from being added/removed from roles after being deactivated.

QMX-1020: Authentication in the eRoom from SOLABS QM using SOLABS’s username.

Q. Will I be able to connect to the eRoom using my SOLABS QM username?

A. Unfortunately this feature was pushed to a future release, you still need to use your SQUID to authenticate in the eRoom.