Remove use of conditional publish from Forms.createNew #1143

ktuite · 2024-05-10T20:52:29Z

This PR consolidates Form publishing in one place, because Dataset publishing is tied to Form publishing. There were three different places to possibly publish a Dataset (creating a new form, updating a form, just publishing a form) and it was too hard to think about which Form scenario led to which Dataset scenario.

As of 5/10/24:

So far, I've removed publish=true from Forms.createNew(). Any time creating a new form was also going to publish the form, the Forms.publish() is now called separately.

One downside is that those lines of code aren't as cute and concise anymore. This only happened in one resource, in a test fixture, and in some tests.

Another downside is that the enketo test mock had a way to put it into an erroneous state for the next request, but a certain form POST request will trigger two enketo requests behind the scenes. I mucked with the enketo test mock to require you to remove the error state, but it's kind of ugly and required modifying multiple tests.

As of 5/14/24:

I decided that keeping publish=true in Forms.createVersion() had utility. There is one rare situation with encrypting existing forms where it really helps to publish concurrently, e.g. when there is both a published version and draft version of a form, and both active versions need to be encrypted. Because this has nothing to do with Datasets, Forms.createVersion does not have code to publish a dataset. I tried to clarify this with comments, too.

I also trie to make Forms.createNew() and Forms.createVersion() more similar. There are some things they both do (parse the form XML to get form fields and dataset info, insert form fields, insert attachments, do enketo things) and some things that are special (comparing against previous schemas for updated forms).

Checklist

I think I want to move enketo draft creation from _createNewDef to createVersion
improve enketo test infrastructure

What has been done to verify that this works as intended?

Why is this the best possible solution? Were any other approaches considered?

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Does this change require updates to the API documentation? If so, please update docs/api.yaml as part of this PR.

Before submitting this PR, please make sure you have:

run make test and confirmed all checks still pass OR confirm CircleCI build passes
verified that any code from external sources are properly credited in comments or that everything is internally sourced

lib/model/query/forms.js

test/integration/api/datasets.js

test/integration/api/forms/forms.js

test/util/enketo.js

lib/model/query/forms.js

test/integration/fixtures/02-forms.js

ktuite

Try this to add reset() to global.enketo?

const reset = () => {
  if (global.enketo === undefined) global.enketo = { reset };
  Object.assign(global.enketo, defaults);
  cancelToken += 1;
};

lib/model/query/forms.js

test/integration/api/audits.js

test/integration/api/forms/draft.js

test/integration/api/forms/forms.js