User admin forms have inconsistent behaviour with KVP that duplicate existing user properties

[JimKerslake]

Spinning this out from #12

At the moment the UI can go a bit awry if you try to declare KVP properties that duplicate existing native User fields.

This comes down to a difference between how the administrator's User Management forms handle things -
'New User' behaves differently from 'Manage' (= edit user).

For the 'Manage' (user edit) screen, you can get the same form input element twice (eg with DoB).

However, if you get rid of that by setting the 'VisibleOnAdminUserEdit' and 'EditableOnAdminUserEdit' config settings to false -
but if you have declared the KVP for DoB as 'required' -
then the admin's "New User" screen becomes impossible to submit, because it does not have its own pre-existing DoB input, the above config prevents the KVP DoB form input element being rendered, but the validation still kicks in.

So maybe a bit of work needed on those various user management forms, validation etc.
(But keeping in mind also the user self-registration form, which is also affected by KVP).

[JimKerslake]

I guess the root issue here is that I've always been a bit confused why the example documentation and start-up code examples for the KVP system focus on properties for FirstName and LastName and DoB which already exist in cs_User table as native properties (but are not by default required in the new user registration form) - why would we ever need to declare these again as KVP?

Always seemed simpler to me to keep the KVP system as something to be used for new properties that are not already fields in cs_User (like 'membership number'). Then if we have an inconsistency that we want properties such as FirstName and LastName to be shown on the new user reg form (as well as the Admin >> Edit User screen) then we might address that some other way - not by declaring a whole extra second KVP property for FirstName and potentially then getting duplicate ones in the Admin >> Edit User screen. Feels like a conflation / confusion of two different use cases.

Having said that, I guess there must be special provision in the KVP code for such properties that are already native to cs_User because I don't think these ones ever get represented as extra rows in kvp_items table.

In practice I don't think we have any production sites where we have any pressing need to change all this and clean it up - and to do so would be very likely to introduce additional bugs - so inclined not to act on this ticket - it 'ain't broke'. Perhaps though it might be worth understanding the issue and seeing whether the KVP documentation is clear enough about this distinction between 2 types of user property.