Create proxy models for the member model, like we did for PaymentUsers. And then create custom admin views displaying certain parts of this data.
Motivation
Think of:
a SalesUsers proxy model with an admin that displays the people that are underage, and their order history
a EventsUser proxy model with an admin that displays the people that are allowed to attend events and their registration history
The events app should then get a model for keeping the events blacklist with a OneToOne relation to the users model
a ThabloidUser proxy model with an admin that displays the people that indicated they want to receive the Thabloid
The thabloid app should then get a model for keeping the opt-in with a OneToOne relation to the users model
an ActiveMembers proxy model with an admin that displays all memberships of a person (only the currently members and people that were active in the past)
Possibly also relevant for partners app (with the opt-in partner mailing list), food orders app (with everyone who ordered food), newsletters (with the newsletter opt-in), mailing lists (with all mailing lists a person is in)
This is all similar to the situation we have with blacklisted TPay payment users.
This has some benefits:
Centralising code in the proper apps the code belongs to
More granular permission management, like required for #2619
Easy way to export more data. Like checking a person's event registration history
Current implementation
Only board has access to the members data, it is not possible to give other people easy access to parts of the members data
Certain code is included in the members profile though it doesn't belong there.
JobDoesburg
commented
1 year ago
Describe the change
Create proxy models for the member model, like we did for PaymentUsers. And then create custom admin views displaying certain parts of this data.
Motivation
Think of:
a SalesUsers proxy model with an admin that displays the people that are underage, and their order history
a EventsUser proxy model with an admin that displays the people that are allowed to attend events and their registration history
a ThabloidUser proxy model with an admin that displays the people that indicated they want to receive the Thabloid
an ActiveMembers proxy model with an admin that displays all memberships of a person (only the currently members and people that were active in the past)
Possibly also relevant for partners app (with the opt-in partner mailing list), food orders app (with everyone who ordered food), newsletters (with the newsletter opt-in), mailing lists (with all mailing lists a person is in)
This is all similar to the situation we have with blacklisted TPay payment users.
This has some benefits:
Current implementation
Suggested implementation
Additional context