Avoid being reliant on mSupply desktop field : [list_master_name_join]description

[ujwalSussol]

The suggestion

Avoid being reliant on mSupply desktop field : [list_master_name_join]description

Why?

The mSupply desktop app had to revert the field name from [list_master_name_join]spare_description to [list_master_name_join]description due to a mobile issue.

The field [list_master_name_join]description has been made obsolete

Corresponding issue mSupply Desktop issue : https://github.com/sussol/msupply/issues/8908

Describe alternatives you've considered

n/a

Additional context

If the mSupply mobile could ignore [list_master_name_join]description then this field could be converted to [list_master_name_join]spare_description and reused in the near future if required.

[josh-griffin]

Problem & possible solution

Essentially this is because of the canBeBlank arrays in incomingSyncUtils being checked as needing to be existing fields.

So, the NameStoreJoin has a canBeBlank array of [description] - when the field name is changed, then the field does not exist anymore, so mobile rejects all NameStoreJoin records.

The easy fix is to just make the array an empty array - []. Also can make canBeBlank fields non-required keys.

---

Consequences

• After this solution has been implemented, the next time desktop changes a field like this, it will be OK for any newly released mobile version.
• As soon as desktop changes a name of a field that is in a canBeBlank array here then that desktop version will be incompatible with any mobile version before this fix.
• It will be very unlikely we catch the problem before releasing, like we have done here, as we won't have the guards in place that older mobile versions will have.
• If this was not caught, I imagine it would have had a lot higher cost in production by the support team!

I am a big refactor fan and happy to do it, but the costs/benefits here don't seem to make this worthwhile 🤷