reload sort_values idno validation errors

[peterjanssens]

Reloading sort values through the admininstration > maintenance > reload sort values UI throws idno validation errors.

Some of them are said to be duplicates but those seconds are deleted - I guess deleted records should always be ignored on validation anyway ?

One legacy idno is failing against the current multipart configuration but I think we never experienced revalidation unless a field was "touched".
The full idno is in the form of BIO.2005.1403b where that deviates from the current configuration where the latter part is SERIAL.
That (and the duplicates?) probably comes from these going through insert() paths and not update() ?? Is that the expected behavior on updating sort_value ? I would not expect idno (re)validation on updates.

[collectiveaccess]

Validation of identifiers happens every time update() is called on a record. If you have require_valid_id_number_for_<table> set for the table then it'll throw errors. If you have allow_duplicate_id_number_for_<table> set to false it'll throw errors on dupes. This isn't new. Your numbers should conform to your policy, or maybe don't have require_valid_id_number_for_<table> set?

The reload process does not filter out deleted rows, the idea being if you end up undeleting things you won't have odd sorting to guess at. I don't know that that really matters though.

[peterjanssens]

Thanks for the deleted dupes.

We usually have require.. true and allow.. false for (normal) idno hygiene.

When you don't filter deleted rows it would always trigger 'duplicated' constantly, even on normal forms, which it doesn't (?) and it would be counterproductive to allow duplicates to allow for deletions to exist. I was in the assumption only so called dirty formfields where handled at form handling.
When only the sort values are to be updated in that reload routine I would not expect revalidation (nothing changed so the validation rules should have done their work last time). It's probably safe and performant to disable validation of all rules on all fields for that reload ?
The feedback/screenshot mentionned insert() in the trace, there validation would be more fit but it's not an insert here?

Undeleting wouldn't be a direct problem I guess, they could then trigger duplicates should all occurrences co-exist (ok) and they probably carry the same sort (ok, unless you want historic or other preferences applied) - when they don't carry the same sort any longer probably too many things changed and a reload would be appropriate.
And since there are no real UI actions to undelete, it wouldn't be a bad thing to have the users/admin revisit a few things anyway.

So in summary for the remaining idno validation: is idno checked at any time ? we then have to try masaging the applied rule or move the legacy ones into another type without rules,... ?