Abhilash Raj writes:
Typo :( Page in Postorius is what I meant to say.
:D No problemo, mon, I just did it too ->
Is that necessarily required? Every user in Django has a corresponding user in Core, but the converse isn’t true and I am not sure if that is even required.
I meant "accessed from Postorius or HyperKitty." :-)
You will be able to see:
- Does the user have a Django account?
- All Subscriptions for the User
- All addresses of the User
You will be able to perform following actions:
- Add or remove a user’s address
- Verify or un-verify an address
- Set any address as primary for the user
- Update display name of the user
- Update address on any of the subscriptions
I don't think we *need* a Django account for what I'm thinking of. I do think that creating the account on User access from Postorius might make the implementation logic simpler.
What I am on fence about:
- Provide a full blown preferences menu to the admin for that user. This will also make the UI extremely complex to see and implement.
Wait to decide on that until I have a mockup or maybe a full MR.
But, when you have an account in Django with a different email (email2) and a different Mailman user (user2) and you add a second email (email1) to your account and are able to prove ownership by verifying the address, Django will ask Core to add that second address (email1) to your Mailman user (user2) and absorb “user1”. This process is already implemented.
Good.
However, if two Django accounts are created for “user1” and “user2” then situation becomes more tricky and currently we don’t have a way to resolve that short of delete one of the accounts and add the addresses to other account.
Delete "that" and add its attributes to "this" is what I had in mind. Again, thanks for explaining the existing logic.
Steve