Unable to start a workstep when elements are pre-populated

An update patch is now available for users on Mosaic 22.1.0.0 to correct this issue. Please see our 22.1.0.1 patch release notes for further information.
​
This issue has been corrected in 21.1.0.3, 21.2.0.3 and 22.1.0.1.

We've identified an issue where it may not be possible to start some worksteps in versions 21.2.1.1, 21.2.0.1, 22.1.0.0 and subsequent versions.
​
This occurs in a very specific scenario and relates to the pre-population of multi-subjects elements, so it’s very likely that you may not see this issue at all. It does relate to a historic bug in Mosaic that affects a wider range of forms elements.

The error when attempting to start a workstep occurs when a multi-subjects table or multi-subjects repeating subsection is pre-populated from more than one other form or form version.

Form A – completed for this group in March 2022 - contains multi-subjects table. This could be an element, but we use table as an example.​

Form B – completed for this group in April 2022 - contains multi-subjects table. Note the worker has removed the line for Ali.​

Form C is set up to pre-populate from Forms A or B and pre-populates from the last completed form. This would mean Form C is pre-populated using the answers from Form B.
​
Mosaic does this, resulting in the table above, but it also notes that the column Question 2 is missing from Form B. It then goes to find the pre-population for Question 2 and finds that the most recent answer to that is in Form A.
​
It is only looking for the answers to Question 2 at this point, so it doesn’t pull through the subject or any other question answers but adds into the table the answers it finds in Form A, starting with the first row, regardless of the answers in the rest of each row.
​
As a result, Form C’s multi-subjects table, in earlier versions of Mosaic, would have appeared in the form in the front end as below.​

However, in the back-end tables, it would appear as:​

Note that question two has simply listed from the top row downwards, regardless of the subjects and other answers. So, where Chicken was the answer for Ali, it now appears against Marcin.

In the above Mosaic versions, we introduced validation that checks the subjects for each table row.
​
This was to support the work to remove subjects from group worksteps, ensuring there are no table rows relating to subjects who are no longer subjects of that form. This performs the validation on the back-end tables, and so on the table above.
​
This validation is working correctly; however, it’s highlighting the historic issue described above, and in these circumstances, it isn’t possible to open the workstep as some of the rows don’t contain a subject.
​
The same issue would occur for multi-subjects repeating subsections in this scenario.
​
The validation only stops the workstep from starting where this causes creation of extra rows without subjects for those rows.

We recommend that anyone taking 21.2.1.1, 21.2.0.1 and 22.1.0.0 versions review this issue and consider whether this affects their upgrade or testing.
​
We are currently working to identify the fix and how we roll this out. We will communicate the plan for this very soon but wanted to ensure we had alerted customers as early as possible. You can keep up to date on releases on from the release notes section of the Customer Success Portal.

These form answers should never have worked like this, we were just not aware of this previously, as it was allowing the steps to be open as expected and required this very specific set of circumstances to occur.
​
It does, however, highlight an existing bug that could, given the very specific circumstances, affect:

As per the example above, if you had pre-population from various forms or form versions where –there was a mismatch in questions as above, for example, the form being populated from was missing a question that appears in the destination form and an earlier form, then this pre-population could occur and potentially, as above, result in question answers mis-matching with the rest of the row they are placed in if the rest of the table row content, or the order, had changed.
​
We do expect this is an edge case, due to the specific scenario in which it occurs, but you should be careful to check pre-population when creating and testing forms and look to take an upgrade to a version containing this fix as soon as possible.