Primary Address doesn't match functionality of Current determination

[bronwyncombs]

As of 7.9.3 release testing on edge, you must unselect a primary address to make another one primary. If you don't, Specify ignores the action on save and reverts to keeping the original primary address as primary.

For 'current' determinations, selecting one as current when there is one already marked 'current' will automatically deselect that one and allow you to save with the new preference for the 'current' determination.

Preferably, the primary field would only allow one record to have this selected at once. In the case of two address records where one is primary and you want the second to be primary instead, selecting the primary box on the second should automatically deselect this on the first.

Example:

• 321 address is primary
• I want 123 to be primary
• I select 123 as primary and save
• 321 as primary overrides and change is not saved

Screen.Recording.2024-01-19.at.2.31.31.PM.mov

Desktop:

• OS: macOS
• Browser: Chrome
• Specify 7 Version: edge

Database Name: fwri

[melton-jason]

I can recreate this issue in v7.9.2.
The behavior is because there is a business rule on the backend which was present, but not a corresponding one on the frontend.

The rule is defined here:

specify7/specifyweb/businessrules/rules/address_rules.py

Lines 4 to 7 in 8aa9027

	@orm_signal_handler('pre_save', 'Address')
	def at_most_one_primary_address_per_agent(address):
	if address.isprimary and address.agent is not None:
	address.agent.addresses.all().update(isprimary=False)

In common terms, the rule's logic is the equivalent of "Whenever saving an Address, if the Address is primary and associated with an Agent, set all other Addresses associated with the Agent to not be primary".

The bug is a result in the order in which the Addresses are saved.
In the example provided in #4440 (comment), if 123 was set as primary and you check Address 321 to be primary with 123, then Specify will set Address 321 to be the primary Address and not 123.
This is because 321 is being saved after 123. The same behavior causes 321 to be primary when 321 is initially primary and 123 is checked as primary.