Mailman 3 February 2015 - Mailman-coders

[Bug 1423756] [NEW] Ability to define user as domainowner or serverowner
by Andrew Stuart April 28, 2015

April 28, 2015

Public bug reported: I had an idea about rounding out the Mailman permissions model, interested in hearing thoughts on it. Obviously there has been considerable discussion on this topic before. Mailman already carries much of the information needed for determining user permissions to Mailman resources. Only two things are missing: 1: the ability to define a user as being a “serverowner” 2: the ability to define a user as being a “domainowner” (You’ll need to look at this email in plain text to see the table properly). The Mailman permissions model currently looks like this: resource_type roles resource_id user_identifier where to find permission --------------------------------------------------------------------------------------------------------- user userowner n/a UUID (defined in user record) list listowner list_id subscriber (defined in list member record) list listmember list_id subscriber (defined in list member record) list listmoderator list_id subscriber (defined in list member record) list listnonmember list_id subscriber (defined in list member record) I am suggesting adding two further permissions to the existing permissions model, which would look like this: resource_type roles resource_id user_id where to find permission --------------------------------------------------------------------------------------------------------- server serverowner n/a UUID (not currently defined in Mailman) domain domainowner mail_host UUID (not currently defined in Mailman) To implement, it would need to be possible to define as user as being a ‘serverowner’, and also to be able to define a user as being a ‘domainowner’ for any given domain. It should be possible to define multiple user with the serverowner role and it should be possible to define multiple users with the domain owner role. If it were possible to do so within the Mailman core then there would be a completely usable permissions model entirely within Mailman, and no need to store any additional permissions data outside Mailman. The permissions model would allow definition of user access to any Mailman resource including domains and servers. The interpretation of the permissions would still be up to the application that consumes the REST API, as is currently the case. There would need to be methods available via the REST API to: set domainowner role for a user set serverowner role for a user delete domainowner role from a user delete serverowner role from a user find if a specific user holds domainowner find if a specific user holds serverowner role find all domainowners for a domain find all serverowners ** Affects: mailman Importance: Undecided Status: New ** Tags: enhancement mailman3 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1423756 Title: Ability to define user as domainowner or serverowner To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1423756/+subscriptions

3 19

[Bug 1420083] [NEW] Provide a reserved url for clearing out the uid table
by Barry Warsaw April 28, 2015

April 28, 2015

Public bug reported: While testing the authenticating REST proxy, it is necessary to clear out the uid table. In normal operation, we never delete rows from this table, to ensure that uids are never duplicated. However, when a user is deleted in the proxy test suite, its uid entry is never cleaned up. This thread discusses several options: http://thread.gmane.org/gmane.mail.mailman.devel/19733 Yet another option would be to expose <api>/reserved/uids/orphans and if you DELETE that resource, all uids not associated with users will be removed from the table. It's a bit crufty in that I think we may be abusing the DELETE method (since <api>/reserved/uids/orphans will still exist after the successful operation), but since this is a testing-only method, I think it's fine. Not sure we need to implement GET, or subresources, but we could if it turns out we need that for testing purposes. Also, DELETEing .../orphans means that the ill effects of accidentally calling this on a real server are minimized. At worst, uids could be reused, but that's unlikely given our use of uuid4(). ** Affects: mailman Importance: High Status: Triaged ** Tags: mailman3 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1420083 Title: Provide a reserved url for clearing out the uid table To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1420083/+subscriptions

2 5

[Bug 1419519] [NEW] REST API delete user function does not delete every 2nd linked address
by Andrew Stuart April 28, 2015

April 28, 2015

Public bug reported: The following series of curl commands creates a user with an email address of ‘z(a)example.xn--org-to0a, and then links 10 additional addresses to z(a)example.org curl -X POST --data "email=z(a)example.org&display_name=z" --header "authorization: Basic cmVzdGFkbWluOnJlc3RwYXNz" http://localhost:8001/3.0/users curl -X POST --data "email=z1(a)example.org" --header "authorization: Basic cmVzdGFkbWluOnJlc3RwYXNz" http://localhost:8001/3.0/users/z@example.org/addresses curl -X POST --data "email=z2(a)example.org" --header "authorization: Basic cmVzdGFkbWluOnJlc3RwYXNz" http://localhost:8001/3.0/users/z@example.org/addresses curl -X POST --data "email=z3(a)example.org" --header "authorization: Basic cmVzdGFkbWluOnJlc3RwYXNz" http://localhost:8001/3.0/users/z@example.org/addresses curl -X POST --data "email=z4(a)example.org" --header "authorization: Basic cmVzdGFkbWluOnJlc3RwYXNz" http://localhost:8001/3.0/users/z@example.org/addresses curl -X POST --data "email=z5(a)example.org" --header "authorization: Basic cmVzdGFkbWluOnJlc3RwYXNz" http://localhost:8001/3.0/users/z@example.org/addresses curl -X POST --data "email=z6(a)example.org" --header "authorization: Basic cmVzdGFkbWluOnJlc3RwYXNz" http://localhost:8001/3.0/users/z@example.org/addresses curl -X POST --data "email=z7(a)example.org" --header "authorization: Basic cmVzdGFkbWluOnJlc3RwYXNz" http://localhost:8001/3.0/users/z@example.org/addresses curl -X POST --data "email=z8(a)example.org" --header "authorization: Basic cmVzdGFkbWluOnJlc3RwYXNz" http://localhost:8001/3.0/users/z@example.org/addresses curl -X POST --data "email=z9(a)example.org" --header "authorization: Basic cmVzdGFkbWluOnJlc3RwYXNz" http://localhost:8001/3.0/users/z@example.org/addresses curl -X POST --data "email=z10(a)example.org" --header "authorization: Basic cmVzdGFkbWluOnJlc3RwYXNz" http://localhost:8001/3.0/users/z@example.org/addresses A sqlite3 dump of the database shows the following in the addresses table: INSERT INTO "address" VALUES(11,'z(a)example.org',NULL,'z',NULL,'2015-02-08 10:50:37.241724',5,17); INSERT INTO "address" VALUES(12,'z1(a)example.org',NULL,'',NULL,'2015-02-08 10:52:08.928901',5,19); INSERT INTO "address" VALUES(13,'z2(a)example.org',NULL,'',NULL,'2015-02-08 10:52:36.308978',5,20); INSERT INTO "address" VALUES(14,'z3(a)example.org',NULL,'',NULL,'2015-02-08 10:52:43.947229',5,21); INSERT INTO "address" VALUES(15,'z4(a)example.org',NULL,'',NULL,'2015-02-08 10:52:49.598934',5,22); INSERT INTO "address" VALUES(16,'z5(a)example.org',NULL,'',NULL,'2015-02-08 10:52:54.406450',5,23); INSERT INTO "address" VALUES(17,'z6(a)example.org',NULL,'',NULL,'2015-02-08 10:52:59.295078',5,24); INSERT INTO "address" VALUES(18,'z7(a)example.org',NULL,'',NULL,'2015-02-08 10:53:04.892381',5,25); INSERT INTO "address" VALUES(19,'z8(a)example.org',NULL,'',NULL,'2015-02-08 10:53:10.497119',5,26); INSERT INTO "address" VALUES(20,'z9(a)example.org',NULL,'',NULL,'2015-02-08 10:53:16.450507',5,27); INSERT INTO "address" VALUES(21,'z10(a)example.org',NULL,'',NULL,'2015-02-08 10:53:24.021368',5,28); All good at this stage. No problems. The following curl command deletes user ‘z(a)example.xn--org-to0a curl --verbose -X DELETE --header "authorization: Basic cmVzdGFkbWluOnJlc3RwYXNz" http://localhost:8001/3.0/users/z@example.org Strangely, a sqlite3 dump of the database now shows the following in the addresses table: INSERT INTO "address" VALUES(12,'z1(a)example.org',NULL,'',NULL,'2015-02-08 10:52:08.928901',NULL,19); INSERT INTO "address" VALUES(14,'z3(a)example.org',NULL,'',NULL,'2015-02-08 10:52:43.947229',NULL,21); INSERT INTO "address" VALUES(16,'z5(a)example.org',NULL,'',NULL,'2015-02-08 10:52:54.406450',NULL,23); INSERT INTO "address" VALUES(18,'z7(a)example.org',NULL,'',NULL,'2015-02-08 10:53:04.892381',NULL,25); INSERT INTO "address" VALUES(20,'z9(a)example.org',NULL,'',NULL,'2015-02-08 10:53:16.450507',NULL,27); So 6 of the addresses that should have been deleted were deleted, but 5 remain. The linked address deletion seems to be skipping addresses for some reason. It appears the problem is caused by the delete address functionality mutating the iterator of user addresses. This appears to fix the problem, which is in rest/users.py def on_delete(self, request, response): """Delete the named user, all her memberships, and addresses.""" if self._user is None: not_found(response) return for member in self._user.memberships.members: member.unsubscribe() user_manager = getUtility(IUserManager) addresses_for_deletion = [] for address in self._user.addresses: # to avoid mutating the self._user.addresses iterator, create a separate list of addresses addresses_for_deletion.append(address) for address in addresses_for_deletion: user_manager.delete_address(address) user_manager.delete_user(self._user) no_content(response) ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1419519 Title: REST API delete user function does not delete every 2nd linked address To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1419519/+subscriptions

2 4

[Bug 1418280] [NEW] "Address already exists" when creating a new user, but user is created anyway
by Andrew Stuart April 28, 2015

April 28, 2015

Public bug reported: When creating a new user via the REST API, if the email address exists, it reports "Address already exists", but it creates the user anyway. After a bit of deep cave diving into the code I suspect it’s this in model/usermanager.py This function appears to create a user before it checks to see if the address exists, with the result that multiple users are created when the address already exists. @implementer(IUserManager) class UserManager: """See `IUserManager`.""" def create_user(self, email=None, display_name=None): """See `IUserManager`.""" user = User(display_name, Preferences()) if email: address = self.create_address(email, display_name) user.link(address) return user this seems to fix the problem - but please don’t trust my solution - needs verification. @implementer(IUserManager) class UserManager: """See `IUserManager`.""" def create_user(self, email=None, display_name=None): """See `IUserManager`.""" if email: address = self.create_address(email, display_name) user = User(display_name, Preferences()) if email: user.link(address) return user ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1418280 Title: "Address already exists" when creating a new user, but user is created anyway To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1418280/+subscriptions

2 4

[Bug 1418276] [NEW] Deleting a user via the REST API does not delete their user preferences
by Andrew Stuart April 28, 2015

April 28, 2015

Public bug reported: The on_delete function in rest/users.py appears to not delete user preferences when the user is deleted resulting in an accumulation of orphaned preferences data. def on_delete(self, request, response): """Delete the named user, all her memberships, and addresses.""" if self._user is None: not_found(response) return for member in self._user.memberships.members: member.unsubscribe() user_manager = getUtility(IUserManager) for address in self._user.addresses: user_manager.delete_address(address) user_manager.delete_user(self._user) no_content(response) ** Affects: mailman Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1418276 Title: Deleting a user via the REST API does not delete their user preferences To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1418276/+subscriptions

5 9

[Bug 1411435] [NEW] installing: TypeError: Can't convert 'NoneType' object to str implicitly
by Sumana Harihareswara April 28, 2015

April 28, 2015

Public bug reported: I am on a stock Ubuntu 14.04 machine (a Digital Ocean virtual server). When I run "mailman start" I get this traceback: $ mailman start Starting Mailman's master runner Traceback (most recent call last): File "/usr/local/bin/mailman", line 9, in <module> load_entry_point('mailman==3.0.0b6', 'console_scripts', 'mailman')() File "/usr/local/lib/python3.4/dist-packages/mailman-3.0.0b6-py3.4.egg/mailman/bin/mailman.py", line 100, in main args.func(args) File "/usr/local/lib/python3.4/dist-packages/mailman-3.0.0b6-py3.4.egg/mailman/commands/cli_control.py", line 138, in process os.execl(*execl_args) File "/usr/lib/python3.4/os.py", line 489, in execl execv(file, args) TypeError: Can't convert 'NoneType' object to str implicitly For reference, my .bash_history (removing the bits where I, e.g., used aptitude to check that I wanted python3-setuptools, and annotating where I got errors): sudo apt-get update sudo apt-get install bzr python-setuptools python-dev build-essential postfix mkdir repos cd repos/ bzr branch lp:mailman bzr branch lp:mailman.client bzr branch lp:postorius bzr branch lp:~mailman-coders/postorius/postorius_standalone cd mailman python setup.py install # got error - it wants Python 3 python3 setup.py install # got ImportError: No module named 'setuptools' sudo apt-get install python3-setuptools sudo python3 setup.py install sudo mailman start (And if I made an error in installing here, please let me know and I'll fix the docs.) ** Affects: mailman Importance: Undecided Status: New ** Tags: mailman3 -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1411435 Title: installing: TypeError: Can't convert 'NoneType' object to str implicitly To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1411435/+subscriptions

2 3

[Bug 1166911] [NEW] domain option for `bin/mailman lists` doesn't work as expected
by Manish Gill April 28, 2015

April 28, 2015

Public bug reported: (mailman)➜ mailman bin/mailman lists --domain example.cc 4 matching mailing lists found: Test1(a)mail.localhost mytest(a)example.cc test2(a)mail.localhost test3(a)mail.localhost For the above output, only mytest(a)example.cc should've been the output. ** Affects: mailman Importance: Undecided Status: New ** Tags: command-line-scripts easy mailman3 ** Branch linked: lp:~mgill25/mailman/mailman -- You received this bug notification because you are a member of Mailman Coders, which is subscribed to GNU Mailman. https://bugs.launchpad.net/bugs/1166911 Title: domain option for `bin/mailman lists` doesn't work as expected To manage notifications about this bug go to: https://bugs.launchpad.net/mailman/+bug/1166911/+subscriptions

3 4

[Bug 1021364] [NEW] Catch httplib2 error if REST API is not available
by Florian Fuchs April 28, 2015

April 28, 2015

Public bug reported: httplib2 (used in mailman.client) throws "[Errno 111] Connection refused" if the core api isn't available. This should be turned into a nice error page with a meaningful description (possibly depending on the visiting user's role - details for admins and a more vague error msg for everyone else). ** Affects: mailman.client Importance: Undecided Status: New ** Affects: postorius Importance: Medium Status: Confirmed ** Tags: api ** Description changed: - httplib2 throws "[Errno 111] Connection refused" if the core api isn't - available. + httplib2 (used in mailman.client) throws "[Errno 111] Connection + refused" if the core api isn't available. This should be turned into a nice error page with a meaningful description (possibly depending on the visiting user's role - details for admins and a more vague error msg for everyone else). ** Also affects: mailman.client Importance: Undecided Status: New ** Changed in: postorius Milestone: None => 1.0.0a2 -- You received this bug notification because you are a member of Mailman Coders, which is the registrant for Postorius. https://bugs.launchpad.net/bugs/1021364 Title: Catch httplib2 error if REST API is not available To manage notifications about this bug go to: https://bugs.launchpad.net/mailman.client/+bug/1021364/+subscriptions

2 6

[Bug 987100] [NEW] enable archival
by Jeff Breidenbach April 28, 2015

April 28, 2015

Public bug reported: Expose mailmans archival booleans as a tristate, either none/private/public or none/local/cloud. ** Affects: postorius Importance: Undecided Status: New ** Tags: mailman3 ** Tags added: mailman3 -- You received this bug notification because you are a member of Mailman Coders, which is the registrant for Postorius. https://bugs.launchpad.net/bugs/987100 Title: enable archival To manage notifications about this bug go to: https://bugs.launchpad.net/postorius/+bug/987100/+subscriptions

3 4

[Bug 1004048] [NEW] Able to create superuser with same email as existing BrowserID account
by Jeff Marshall April 28, 2015

April 28, 2015

Public bug reported: I initially connected to Postorius using BrowserID. I then created a superuser from the command line (in dev_setup -> python manage.py createsuperuser). It correctly prevented me from using the existing username, but I was able to use the same email address as my BrowserID account. The superuser account was created and I could log into Postorius successfully. When I then logged back out and logged in via BrowserID I received this error: AuthException at /complete/browserid/ Not unique email address. Request Method: POST Request URL: http://xxxxxxxxxxxxxxxxxx/complete/browserid/ Django Version: 1.3.1 Exception Type: AuthException Exception Value: Not unique email address. Exception Location: /usr/local/lib/python2.7/dist-packages/django_social_auth-0.6.9-py2.7.egg/social_auth/backends/pipeline/associate.py in associate_by_email, line 22 ** Affects: postorius Importance: Undecided Status: New -- You received this bug notification because you are a member of Mailman Coders, which is the registrant for Postorius. https://bugs.launchpad.net/bugs/1004048 Title: Able to create superuser with same email as existing BrowserID account To manage notifications about this bug go to: https://bugs.launchpad.net/postorius/+bug/1004048/+subscriptions

2 1