Subscribing members to list through 2 different methods?
Upon searching more regarding various models in the Gnu Mailman, I learned that technically first a "User" entity is created and then a "Member" entity can be created in correspondence to a "Mailing-List" entity. For example
harry_member = mlist.subscribe(harry_user)
This, however, is totally different to the subscribe function given in the mailmanclient doc, where you actually do:
harry_member = mlist.subscribe(harry_email,harry_display_name,pre_verified...)
Why is this behaviour desired? Pointers on this would be appreciated
On 6/10/19 11:21 PM, Aaryan Bhagat wrote:
Upon searching more regarding various models in the Gnu Mailman, I learned that technically first a "User" entity is created and then a "Member" entity can be created in correspondence to a "Mailing-List" entity. For example
harry_member = mlist.subscribe(harry_user)
This is the mailing list subscribe method in Mailman core which requires a user or address object to subscribe.
This, however, is totally different to the subscribe function given in the mailmanclient doc, where you actually do:
harry_member = mlist.subscribe(harry_email,harry_display_name,pre_verified...)
mailmanclient is completely separate from Mailman core. It provides a set of Python bindings that are used by Postorius and HyperKitty to communicate with core via core's REST API. Its mailing list subscribe method is not core's subscribe method and its arguments are those appropriate for Postorius
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Yes, I understand, thanks for explaining, however:
But even when doing through mailmanclient bindings which are appropriate for Postorious, it would not technically bypass creating the "User" entity as the entity will be created when the account on postorious will be created, or am I missing something here?
On Tue, Jun 11, 2019, at 10:39 AM, Aaryan Bhagat wrote:
Have you read this1?
In short, Postorius and Core are weakly linked today through email address. You can just subscribe/unsubscribe/moderate/set preferences for just an email.
User is an abstraction on a group of emails with a set of preferences. What that gives you is ability to manage multiple emails together. So you can set User level preferences and that is applied to emails (unless emails have preferences too for overriding).
When it comes to subscription, one can choose to subscribe either a User or and Address object which results in a Member object with a Role.
This all happens in Core and lower level primitives are exposed in REST API to subscribe an Address or a User.
Postorius does User management differently. It has it's own concept of what a "User" is, which is loosely coupled with Core. Postorius uses Django's user model for account management. A user who has verified their email address in Postorius can control the subscriptions for that address in Core.
For example, you sign up in Postorius with your email address, but you already have a subscription with your email address in Core. They will show up as soon as you sign in, even if it is the first time you are signing in.
It is not *required* to create a "User" object associated with a Django user until that user actually subscribes to a list. Although, we now use Django's signals framework now to create a user in Core as soon as they sign up in Postorius2, code for that lives in Django-mailman3.
Does that answer your questions?
-- thanks, Abhilash Raj (maxking)
I understood it, thanks for explaining
It is not *required* to create a "User" object associated with a Django user until that user actually subscribes to a list.
For my current aim of processing bounces, I think my target people are only those who are subscribed to some list right? Because in the end, I have to decide whom to disable sending emails and whom not to, that will only happen when they member of some list.
Should I or shouldn't I take into consideration those who are not a member of any list? Am I missing something here?
On 6/11/19 10:38 AM, Aaryan Bhagat wrote:
But even when doing through mailmanclient bindings which are appropriate for Postorious, it would not technically bypass creating the "User" entity as the entity will be created when the account on postorious will be created, or am I missing something here?
Not exactly. Creating accounts in Django (Postorius/HyperKitty) does not create Users in Mailman Core, but when Postorius calls mailmanclient's subscribe method to subscribe a user, mailmanclient submits a request to core via the REST API and the processing of that request creates the necessary user/address objects for the subscription. See the on_post method of the AllMembers class in mailman/rest/members.py for the details.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Tue, Jun 11, 2019, at 10:54 AM, Mark Sapiro wrote:
This used to be the case before Django-Mailman3 exited. With move to django-allauth, we now sync _most_ of the changes in Postorius down to Core. AFAIK, we don't do primary email change( there should be a TODO for this), but add/remove/sign in etc generates signals which creates appropriate users/addreses and links them.
https://gitlab.com/mailman/django-mailman3/blob/master/django_mailman3/signa...
-- thanks, Abhilash Raj (maxking)
So you are implying if we create an account using Postorious, a User/Address object is created automatically in the Core but this is not important, we can already have a User/Address entity in the Core even if we have not signed up at all in Postorious, if we sign up then all the synced data will show up. Is the above understanding is right?
On Wed, Jun 12, 2019, at 11:18 AM, Aaryan Bhagat wrote:
Right, core technically doesn't need to know about all the accounts on Postorius.
we can already have a User/Address entity in the Core even if we have not signed up at all in Postorious,
If you have ever interacted with Core through emails, i.e. subscribed, unsubscribed, set your preferences, someone else added you as a member on a list etc.
Yes, that's correct.
-- thanks, Abhilash Raj (maxking)
I actually am trying to understand the model architecture as a whole, I admit the pace is slow due to my machine had hardware problems recently ( I notified this as soon as possible to Abhilash and it is fixed now ),
As mentioned in my proposal 1 I actually need an entity ( any model, class in the mailman models ) which has all the emails corresponding to the mailing list they have subscribed for a particular user, the new variables I want to create my new variables in that entity.
Any pointers on this will be helpful.
On 6/10/19 11:21 PM, Aaryan Bhagat wrote:
Upon searching more regarding various models in the Gnu Mailman, I learned that technically first a "User" entity is created and then a "Member" entity can be created in correspondence to a "Mailing-List" entity. For example
harry_member = mlist.subscribe(harry_user)
This is the mailing list subscribe method in Mailman core which requires a user or address object to subscribe.
This, however, is totally different to the subscribe function given in the mailmanclient doc, where you actually do:
harry_member = mlist.subscribe(harry_email,harry_display_name,pre_verified...)
mailmanclient is completely separate from Mailman core. It provides a set of Python bindings that are used by Postorius and HyperKitty to communicate with core via core's REST API. Its mailing list subscribe method is not core's subscribe method and its arguments are those appropriate for Postorius
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Yes, I understand, thanks for explaining, however:
But even when doing through mailmanclient bindings which are appropriate for Postorious, it would not technically bypass creating the "User" entity as the entity will be created when the account on postorious will be created, or am I missing something here?
On Tue, Jun 11, 2019, at 10:39 AM, Aaryan Bhagat wrote:
Have you read this1?
In short, Postorius and Core are weakly linked today through email address. You can just subscribe/unsubscribe/moderate/set preferences for just an email.
User is an abstraction on a group of emails with a set of preferences. What that gives you is ability to manage multiple emails together. So you can set User level preferences and that is applied to emails (unless emails have preferences too for overriding).
When it comes to subscription, one can choose to subscribe either a User or and Address object which results in a Member object with a Role.
This all happens in Core and lower level primitives are exposed in REST API to subscribe an Address or a User.
Postorius does User management differently. It has it's own concept of what a "User" is, which is loosely coupled with Core. Postorius uses Django's user model for account management. A user who has verified their email address in Postorius can control the subscriptions for that address in Core.
For example, you sign up in Postorius with your email address, but you already have a subscription with your email address in Core. They will show up as soon as you sign in, even if it is the first time you are signing in.
It is not *required* to create a "User" object associated with a Django user until that user actually subscribes to a list. Although, we now use Django's signals framework now to create a user in Core as soon as they sign up in Postorius2, code for that lives in Django-mailman3.
Does that answer your questions?
-- thanks, Abhilash Raj (maxking)
I understood it, thanks for explaining
It is not *required* to create a "User" object associated with a Django user until that user actually subscribes to a list.
For my current aim of processing bounces, I think my target people are only those who are subscribed to some list right? Because in the end, I have to decide whom to disable sending emails and whom not to, that will only happen when they member of some list.
Should I or shouldn't I take into consideration those who are not a member of any list? Am I missing something here?
On 6/11/19 10:38 AM, Aaryan Bhagat wrote:
But even when doing through mailmanclient bindings which are appropriate for Postorious, it would not technically bypass creating the "User" entity as the entity will be created when the account on postorious will be created, or am I missing something here?
Not exactly. Creating accounts in Django (Postorius/HyperKitty) does not create Users in Mailman Core, but when Postorius calls mailmanclient's subscribe method to subscribe a user, mailmanclient submits a request to core via the REST API and the processing of that request creates the necessary user/address objects for the subscription. See the on_post method of the AllMembers class in mailman/rest/members.py for the details.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
On Tue, Jun 11, 2019, at 10:54 AM, Mark Sapiro wrote:
This used to be the case before Django-Mailman3 exited. With move to django-allauth, we now sync _most_ of the changes in Postorius down to Core. AFAIK, we don't do primary email change( there should be a TODO for this), but add/remove/sign in etc generates signals which creates appropriate users/addreses and links them.
https://gitlab.com/mailman/django-mailman3/blob/master/django_mailman3/signa...
-- thanks, Abhilash Raj (maxking)
So you are implying if we create an account using Postorious, a User/Address object is created automatically in the Core but this is not important, we can already have a User/Address entity in the Core even if we have not signed up at all in Postorious, if we sign up then all the synced data will show up. Is the above understanding is right?
On Wed, Jun 12, 2019, at 11:18 AM, Aaryan Bhagat wrote:
Right, core technically doesn't need to know about all the accounts on Postorius.
we can already have a User/Address entity in the Core even if we have not signed up at all in Postorious,
If you have ever interacted with Core through emails, i.e. subscribed, unsubscribed, set your preferences, someone else added you as a member on a list etc.
Yes, that's correct.
-- thanks, Abhilash Raj (maxking)
I actually am trying to understand the model architecture as a whole, I admit the pace is slow due to my machine had hardware problems recently ( I notified this as soon as possible to Abhilash and it is fixed now ),
As mentioned in my proposal 1 I actually need an entity ( any model, class in the mailman models ) which has all the emails corresponding to the mailing list they have subscribed for a particular user, the new variables I want to create my new variables in that entity.
Any pointers on this will be helpful.
participants (3)
-
Aaryan Bhagat -
Abhilash Raj -
Mark Sapiro