MOTs business logic: Clear CO form when CO Type changes

[sharadsw]

Fixes #5088

Using business rules to clear CO values when COType changes. Needs #5098 to be fixed to test with configuring a pick list in Schema Config. Until then, it can be tested with CoType as a QCBX.

The following fields are ignored when clearing for better UX or based on backend restrictions (for eg: backend needs a non-null value for version)

specify7/specifyweb/frontend/js_src/lib/components/DataModel/businessRuleDefs.ts

Lines 155 to 161 in 64fd7ea

	const fieldsToIgnore = [
	'cataloger',
	'catalogNumber',
	'collection',
	'collectionObjectType',
	'version',
	];

Checklist

• Self-review the PR after opening it to make sure the changes look good
  and self-explanatory (or properly documented)
• Add automated tests
• Add relevant issue to release milestone

Testing instructions

Set up a QCBX for CollectionObjectType (like in #5127):

Ideally, COType would be set as a picklist. However, until #5098 is fixed, it is not possible to configure one for COType. Instead for this PR, COType can be set up as a QCBX.

• Go to App Resources > Type Searches (found under Global Resources)
• Add the following line in the XML editor:

<typesearch tableid="1015"  name="CollectionObjectType" searchfield="name" displaycols="name" format="%s" uifieldformatter="" dataobjformatter="" system="true"/>

• Click on the Form Definition tab
• Select the correct .views file for the collection you are in
• Go the the Collection Object form definition
• Add the following lines inside an existing <row>:

<cell type="label" labelfor="111"/>
<cell type="field" id="111" name="collectionObjectType" uitype="querycbx" />

Your CO form should look something like this

Testing the PR

• Go to Data Entry -> Collection Object
• Enter some determinations
• Enter data in different basic fields (text/number fields)
• Change CollectionObjectType value
• Verify all simple fields are cleared
• Verify any added determinations are deleted
• Re-run the test for an already existing Collection Object

[CarolineDenis]

TODO:

• Refresh after type change when form is already saved

[melton-jason]

Are we clearing all fields on the CollectionObject?

What I gathered from #4640 (comment) is that only the CollectionObjectAttribute fields should be cleared.
Other fields on CollectionObject can remain untouched.
Is this misunderstanding the requirements, or have the requirements changed?

(If we go with a businessrule approach for determing the Taxon tree to search on for the Determination -> QueryComboBox and the current implementation style of #5127, then Determinations should be cleared as well).

[sharadsw]

Hmm, looks like #4640 mentions only clearing determinations and collectionObjectAttribute fields - which would make this a lot simpler. However, I think we discussed in a meeting that we should clear all fields as we don't know what fields are gonna be conditionally rendered - which should handle all possibilities.

Thoughts on this? @grantfitzsimmons

[CarolineDenis]

@sharadsw

However, I think we discussed in a meeting that we should clear all fields as we don't know what fields are gonna be conditionally rendered - which should handle all possibilities.

Yes that is correct

[grantfitzsimmons]

@sharadsw The decision for now is to clear everything– I just spoke with Aimee and it seems like the simplest solution for the MVP.

I feel that we should only clear fields not visible on the form (in case of conditionals) and the determination, but maybe that is something we revisit later.

[sharadsw]

Trying to clear all to-many dependent fields with the simple resource.set(fieldName, []) results in an infinite loop. So the only other way to clear to-many fields is to individually remove every record of each to-many relation in the CO form - which could theoretically be an expensive/slow operation for large data.

Right now this PR will clear all simple fields and independent relations and also delete all determinations added in the CO form whenever CollectionObjectType changes. Does this sound good? @grantfitzsimmons

[emenslin]

Testing the PR

• Go to Data Entry -> Collection Object
• Enter some determinations
• Enter data in different basic fields (text/number fields)
• Change CollectionObjectType value
• Verify all simple fields are cleared
• Verify any added determinations are deleted
• Re-run the test for an already existing Collection Object

Looks good, all fields expected to clear were cleared

[grantfitzsimmons]

Trying to clear all to-many dependent fields with the simple resource.set(fieldName, []) results in an infinite loop. So the only other way to clear to-many fields is to individually remove every record of each to-many relation in the CO form - which could theoretically be an expensive/slow operation for large data.

Right now this PR will clear all simple fields and independent relations and also delete all determinations added in the CO form whenever CollectionObjectType changes. Does this sound good? @grantfitzsimmons

That sounds good to me.

[alesan99]

Testing the PR

• Go to Data Entry -> Collection Object
• Enter some determinations
• Enter data in different basic fields (text/number fields)
• Change CollectionObjectType value
• Verify all simple fields are cleared
• Verify any added determinations are deleted
• Re-run the test for an already existing Collection Object

All fields I tried were cleared 👍👍👍

chrome_uq7cIGOCjt.mp4

[Areyes42]

Testing the PR

• Go to Data Entry -> Collection Object
• Enter some determinations
• Enter data in different basic fields (text/number fields)
• Change CollectionObjectType value
• Verify all simple fields are cleared
• Verify any added determinations are deleted
• Re-run the test for an already existing Collection Object

---

Looks good, all fields cleared on new and pre-existing COs👌

[melton-jason]

This is fine given it is acceptable for the requirements and a temporary solution or fallback if a more robust solution can not be implemented by the deadline.

Not a fan of clearing all literal fields and some relationships here.
Either of the previously discussed solutions (only clearing fields used in a conditional panel or having separate view definitions based on CollectionObjectType) will be well worth the complexity, and far better from a resultant UX standpoint.

Complexity does take time, and that we don't have much of, so something is better than nothing.

Still, this is a fine start while we work out everything else for Geo.
Onto the next fish to fry! 👏

[specifysoftware]

This pull request has been mentioned on Specify Community Forum. There might be relevant details there:

https://discourse.specifysoftware.org/t/specify-7-9-7-release-announcement/1979/1