The mentioned issue: https://gitlab.com/mailman/mailman/issues/553
So, the line 65 in eml_confirm.py in /src/mailman/commands/
which raises the error is assert member is None, member
Basically what this line is doing is checking if the member is None or not and if it ISN'T, it raises an Assertion Error with member details printed.
According to the comments (line 57-60) in the same file, member would be None when there's an unsubscription, but here it is NOT None (idk why).
2 pretty simple ways of dealing with this will be:
- commenting the line
- adding an
except AssertionErrorline
But these won't solve the root problem, i.e why is the member NOT None.
I'm currently looking a bit more into it but, How should I proceed with this??
Also, couple of doubts:
- How can a moderator confirm the unsubscription request??
- For the tables
userandmemberinmailman.dbfile inmailman/var/data/, when a person unsubscribes from a list, the entry of that member is deleted from themembertable but not fromusertable. Is it due to the fact that even if the person is not a member, they can still be user??
Thank You
Line 53 in eml_confirm.py is: new_token, token_owner, member = ISubscriptionManager(mlist).confirm(token)
I checked the return of function confirm of class ISubscriptionManager in /mailman/src/interfaces/subscriptions.py which says -->
A 3-tuple is returned where the first element is the token
hash, the second element is a TokenOwner`, and the third element is the subscribed member. If the subscriber got subscribed immediately, the token will be None and the member will be an IMember``. If the subscription is still being held, the token
will be a hash and the member will be None.
But this doesn't say anything of unsubscription??
Even if it does, the returns I'm getting are not in conjunction to what is written over there. I'm getting a token hash AS WELL AS a member which is thus raising the error.
On 1/3/20 11:21 AM, ritwik p wrote:
Line 53 in
eml_confirm.pyis: new_token, token_owner, member = ISubscriptionManager(mlist).confirm(token)I checked the return of function
confirmof classISubscriptionManagerin/mailman/src/interfaces/subscriptions.pywhich says -->A 3-tuple is returned where the first element is the token hash, the second element is a
TokenOwner`, and the third element is the subscribed member. If the subscriber got subscribed immediately, the token will be None and the member will be anIMember``. If the subscription is still being held, the token will be a hash and the member will be None.But this doesn't say anything of unsubscription??
That's exactly the issue. The code doesn't fully account for unsubscription. (And comments don't always agree with what the code actually does.)
Even if it does, the returns I'm getting are not in conjunction to what is written over there. I'm getting a token hash AS WELL AS a member which is thus raising the error.
Because that code didn't take moderation of unsubscriptions into account.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
That's exactly the issue. The code doesn't fully account for unsubscription. (And comments don't always agree with what the code actually does.)
So basically I need to modify/update/rewrite the confirm(token) function?
Where can I start with this?
Also any pointers as to how should I deal with the function??
On 1/4/20 5:13 AM, ritwik p wrote:
Mark Sapiro wrote:
That's exactly the issue. The code doesn't fully account for unsubscription. (And comments don't always agree with what the code actually does.)
So basically I need to modify/update/rewrite the
confirm(token)function? Where can I start with this? Also any pointers as to how should I deal with the function??
No. You do not want to change the confirm(token) function. You want to
change mailman/commands/eml_confirm.py to do the right thing.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
No. You do not want to change the confirm(token) function. You want to change mailman/commands/eml_confirm.py to do the right thing.
Ok.
Also,
I'm getting member as not-None when the member confirms their subscription.
But the comments said (which you corrected), that the member will be None when subscribing.
On 1/3/20 7:57 AM, ritwik p wrote:
The mentioned issue: https://gitlab.com/mailman/mailman/issues/553
So, the line 65 in
eml_confirm.pyin/src/mailman/commands/which raises the error isassert member is None, memberBasically what this line is doing is checking if the
memberisNoneor not and if it ISN'T, it raises an Assertion Error with member details printed. According to the comments (line 57-60) in the same file, member would beNonewhen there's an unsubscription, but here it is NOT None (idk why).
Because the comment is backwards.
2 pretty simple ways of dealing with this will be:
- commenting the line
- adding an
except AssertionErrorlineBut these won't solve the root problem, i.e why is the member NOT None.
because member exists when when we are unsubscribing a member and member doesn't yet exist when we are subscribing a new member.
The comment We can't assert anything about member. actually applies to
all the conditions, not just if new_token is None:
The point is that the comment is wrong and also that
elif token_owner is TokenOwner.moderator: # This must have been a confirm-then-moderator subscription.
is wrong because it could also be a confirm-then-moderate unsubscription
I'm currently looking a bit more into it but, How should I proceed with this??
Create some additional tests for unsubscription when policy is
confirm_then_moderate that will fail on the assert member is None.
Once you are satisfied that you are testing all the combinations of subscribe/unsubscribe and policy confirm with and without moderate, fix the code so the tests pass.
Also, couple of doubts:
- How can a moderator confirm the unsubscription request??
Usually, through the Postorius web UI, but also by email, and you need to be sure that's tested too.
- For the tables
userandmemberinmailman.dbfile inmailman/var/data/, when a person unsubscribes from a list, the entry of that member is deleted from themembertable but not fromusertable. Is it due to the fact that even if the person is not a member, they can still be user??
Yes. The user could be a member of other lists, but even if not the user remains. This is the subject of <https://gitlab.com/mailman/mailman/issues/646>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
Because the comment is backwards.
What do you mean by this??
because member exists when when we are unsubscribing a member and member doesn't yet exist when we are subscribing a new member. The comment We can't assert anything about member. actually applies to all the conditions, not just if new_token is None: The point is that the comment is wrong and also that elif token_owner is TokenOwner.moderator: # This must have been a confirm-then-moderator subscription.
is wrong because it could also be a confirm-then-moderate unsubscription
That's what I meant by the "root" problem.
Create some additional tests for unsubscription when policy is confirm_then_moderate that will fail on the assert member is None. Once you are satisfied that you are testing all the combinations of subscribe/unsubscribe and policy confirm with and without moderate, fix the code so the tests pass.
I haven't really written tests before. Can you point me to any link/docs for the same? Also, where can I write the tests?
Usually, through the Postorius web UI, but also by email, and you need to be sure that's tested too.
Can I do it with mailman inject??
If yes, then how??
Thanks Mark :)
On 1/4/20 5:10 AM, ritwik p wrote:
Mark Sapiro wrote:
Because the comment is backwards.
What do you mean by this??
The comment says
# We can't assert anything about member. It will be None when # the workflow we're confirming is an unsubscription request, # and non-None when we're confirming a subscription request. # This class doesn't know which is happening.
That's backwards. I.e, it should say
# We can't assert anything about member. It will be None when # the workflow we're confirming is a subscription request, # and non-None when we're confirming an unsubscription request. # This class doesn't know which is happening.
Create some additional tests for unsubscription when policy is confirm_then_moderate that will fail on the assert member is None. Once you are satisfied that you are testing all the combinations of subscribe/unsubscribe and policy confirm with and without moderate, fix the code so the tests pass.
I haven't really written tests before. Can you point me to any link/docs for the same? Also, where can I write the tests?
See mailman/commands/tests/test_eml_confirm.py for the existing tests. That's where you would add new tests for this.
How can a moderator confirm the unsubscription request??
Usually, through the Postorius web UI, but also by email, and you need to be sure that's tested too.
Can I do it with
mailman inject?? If yes, then how??
You can use mailman inject in lieu of sending email, but you can't
test the REST interface that Postorius uses that way.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Mark Sapiro wrote:
The comment says # We can't assert anything about member. It will be None when # the workflow we're confirming is an unsubscription request, # and non-None when we're confirming a subscription request. # This class doesn't know which is happening. That's backwards. I.e, it should say # We can't assert anything about member. It will be None when # the workflow we're confirming is a subscription request, # and non-None when we're confirming an unsubscription request. # This class doesn't know which is happening.
So the comments which are already present in the file are wrong?
You can use mailman inject in lieu of sending email, but you can't test the REST interface that Postorius uses that way.
Can you point me to the docs where i can find the command/instructions for approval from the moderator?
Also, If I, set the unsubscription_policy to confirm_then_moderate in mailman-shell, is it applied to the Postorius as well?
On 1/7/20 7:35 AM, ritwik p wrote:
Mark Sapiro wrote:
The comment says # We can't assert anything about member. It will be None when # the workflow we're confirming is an unsubscription request, # and non-None when we're confirming a subscription request. # This class doesn't know which is happening. That's backwards. I.e, it should say # We can't assert anything about member. It will be None when # the workflow we're confirming is a subscription request, # and non-None when we're confirming an unsubscription request. # This class doesn't know which is happening.
So the comments which are already present in the file are wrong?
In that case, yes.
You can use mailman inject in lieu of sending email, but you can't test the REST interface that Postorius uses that way.
Can you point me to the docs where i can find the command/instructions for approval from the moderator?
See <https://mailman.readthedocs.io/en/latest/src/mailman/core/docs/chains.html#t...>. This applies to held posts, but held subscriptions are similar.
Also, If I, set the
unsubscription_policytoconfirm_then_moderatein mailman-shell, is it applied to the Postorius as well?
Postorius is a web UI that communicates with core fia core's REST interface to retrieve, display and update core settings. Postorius gets everything from core. It does not keep its own version of anything.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
@ritwak p Are you still working on this issue? Please let us know.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
participants (2)
-
Mark Sapiro -
ritwik p