Cloned records misassign 'isCurrent' and 'isPrimary'

[Areyes42]

Describe the bug
When cloning an agent with multiple addresses, the new cloned agent sets the most recently added address as 'primary' instead of preserving the 'primary' address from the original agent record.

To Reproduce
Steps to reproduce the behavior:

1. Go to or create an agent with multiple addresses
2. Set any address as the 'Primary' address (excluding the last one)
3. Save the changes
4. Click on clone
5. Observe that the 'Primary' addresses do not match

Expected behavior
The cloned agent should retain the same primary address as the original.

Screenshots

Screen.Recording.2024-06-20.at.10.26.44.AM.mov

Please, also fill out the following information manually:

• OS: macOS 14.5
• Browser: Chrome
• Specify 7 Version: edge
• Database Name: KUFish_5_16_23
• Collection name: KU Fish Voucher
• User Name: spfishadmin

[emenslin]

Can recreate in edge (7.9.6)

[emenslin]

Also applies to is current in determinations

[bronwyncombs]

CSIRO has urged a fix for this:

(currently using v7.9.4)

When we clone (or Carry Forward) a collection object which has multiple determinations, before we save the clone, all the determinations are ticked as current.
Source:

Clone before save:

However, when we hit save (without unticking anything), we don't get an error, but the current determination assigned is not the same current determination as the source cloned record. This is a problem!
Clone after save:

This latter issue is replicable in Sp7demofish, with voucher 000040413.
Source record (2010 determination is current):

Clone: (2009 determination is current):

Is this being fixed soon?
Cloning is something our users are keen to use, but these issues are preventing us from recommending its use. We need this resolved. This, in combination with our other request ticket #4186 (about being able to delete dependent resources before they are saved), would make cloning very helpful for our users.
Thanks,
Zoe

[emenslin]

Since we are planning to release the ability to select a range for series entry in 7.11.1, do we have a plan for fixing this issue? I feel like this could become a big problem for users who want to use series entry.

07-07_14.27.mp4

[melton-jason]

The Issue stems from the fact that when cloning a record, Specify directly copies over it's non-relationship and independent field values as it is creating the new cloned record.

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

Lines 175 to 178 in 45288b4

	const newResource = new this.constructor(
	removeKey(this.attributes, ...specialFields, ...exemptFields),
	{ createdBy: 'clone' }
	);

(There's an incorrect assumption that all independent relationships should be copied over exactly, leading to another problem: #1702)

Specify then goes through each of the dependent records, clones them and adds them one-by-one to the new resource:

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

Lines 183 to 227 in 45288b4

	Object.entries(self.dependentResources).map(
	async ([fieldName, related]) => {
	if (exemptFields.includes(fieldName)) return;
	const field = self.specifyTable.getField(fieldName);
	switch (field.type) {
	case 'one-to-one':
	case 'many-to-one': {
	/*
	* Many-to-one wouldn't ordinarily be dependent, but
	* this is the case for paleocontext. really more like
	* a one-to-one.
	*/
	newResource.set(
	fieldName,
	await related?.clone(cloneAll, isBulkCarry)
	);
	break;
	}
	case 'one-to-many': {
	await newResource
	.rget(fieldName)
	.then(async (newCollection) =>
	Promise.all(
	related.models.map(async (resource) =>
	newCollection.add(
	await resource?.clone(cloneAll, isBulkCarry)
	)
	)
	)
	);
	break;
	}
	case 'zero-to-one': {
	newResource.set(
	fieldName,
	await related?.clone(cloneAll, isBulkCarry)
	);
	break;
	}
	default: {
	throw new Error('unhandled relationship type');
	}
	}
	}
	)

This leads to the onAdded business rules (which are in charge of handling the setting of isCurrent and isPrimary) to be triggered for each of the dependent resources, leading to the incorrect result.

[melton-jason]

A reminder for whomever tackles this Issue, the temporary fixes of #7182 need to be reverted.
See the REFACTOR comments in https://github.com/specify/specify7/pull/7182/files.