Easier way to add volunteer role admins

[ormiret]

fixes #1508

[jellybob]

Rebased, and regenerated the migration.

I'm seeing the following warnings on startup, and don't know enough SQLAlchemy (or have enough brain power this evening) to work out whether they're something we should be worrying about.

/app/models/__init__.py:202: SAWarning: relationship 'Role.role_admins' will copy column volunteer_role.id to column volunteer_role_admin.role_id, which conflicts with relationship(s): 'Role.admins' (copies volunteer_role.id to volunteer_role_admin.role_id), 'RoleAdmin.role' (copies volunteer_role.id to volunteer_role_admin.role_id). If this is not the intention, consider if these relationships should be linked with back_populates, or if viewonly=True should be applied to one or more if they are read-only. For the less common case that foreign key constraints are partially overlapping, the orm.foreign() annotation can be used to isolate the columns that should be written towards.   To silence this warning, add the parameter 'overlaps="admins,role"' to the 'Role.role_admins' relationship. (Background on this error at: https://sqlalche.me/e/14/qzyx)
  db.configure_mappers()
/app/models/__init__.py:202: SAWarning: relationship 'Role.role_admins' will copy column volunteer.user_id to column volunteer_role_admin.user_id, which conflicts with relationship(s): 'RoleAdmin.user' (copies user.id to volunteer_role_admin.user_id), 'User.volunteer_admin_roles' (copies user.id to volunteer_role_admin.user_id). If this is not the intention, consider if these relationships should be linked with back_populates, or if viewonly=True should be applied to one or more if they are read-only. For the less common case that foreign key constraints are partially overlapping, the orm.foreign() annotation can be used to isolate the columns that should be written towards.   To silence this warning, add the parameter 'overlaps="user,volunteer_admin_roles"' to the 'Role.role_admins' relationship. (Background on this error at: https://sqlalche.me/e/14/qzyx)
  db.configure_mappers()
/app/models/__init__.py:202: SAWarning: relationship 'Volunteer.admined_roles' will copy column volunteer.user_id to column volunteer_role_admin.user_id, which conflicts with relationship(s): 'RoleAdmin.user' (copies user.id to volunteer_role_admin.user_id), 'User.volunteer_admin_roles' (copies user.id to volunteer_role_admin.user_id). If this is not the intention, consider if these relationships should be linked with back_populates, or if viewonly=True should be applied to one or more if they are read-only. For the less common case that foreign key constraints are partially overlapping, the orm.foreign() annotation can be used to isolate the columns that should be written towards.   To silence this warning, add the parameter 'overlaps="user,volunteer_admin_roles"' to the 'Volunteer.admined_roles' relationship. (Background on this error at: https://sqlalche.me/e/14/qzyx)
  db.configure_mappers()
/app/models/__init__.py:202: SAWarning: relationship 'Volunteer.admined_roles' will copy column volunteer_role.id to column volunteer_role_admin.role_id, which conflicts with relationship(s): 'Role.admins' (copies volunteer_role.id to volunteer_role_admin.role_id), 'RoleAdmin.role' (copies volunteer_role.id to volunteer_role_admin.role_id). If this is not the intention, consider if these relationships should be linked with back_populates, or if viewonly=True should be applied to one or more if they are read-only. For the less common case that foreign key constraints are partially overlapping, the orm.foreign() annotation can be used to isolate the columns that should be written towards.   To silence this warning, add the parameter 'overlaps="admins,role"' to the 'Volunteer.admined_roles' relationship. (Background on this error at: https://sqlalche.me/e/14/qzyx)

[russss]

Really sorry that this one got dropped - it'll need re-applying to the current state of the codebase (the migrations have got reset so at least the migration will need replacement, and it'll probably need tweaking for the new SQLAlchemy syntax).

Given that we've got a blank database at the moment, I wonder if it might be better to make trained_roles into an explicit join table with a boolean admin flag, rather than adding a new table for admins?

[marksteward]

RoleAdmin already exists, the problem is the secondary join path, which sqlalchemy doesn't like. It should either be view_only or an association proxy (and I don't know how those interact with flask-admin, which is why it's languished).

We should also be getting rid of lazy=dynamic.