REST access to preferences
Bug #821438 reported by
benste
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
GNU Mailman |
Fix Released
|
Medium
|
Barry Warsaw | ||
GNU Mailman REST Client |
Fix Committed
|
Undecided
|
Unassigned | ||
MailmanwebGSoC2011 |
Triaged
|
Wishlist
|
Unassigned |
Bug Description
Using the Python bindings the following things are available at the moment:
self_link: u'http://
role: u'member'
user: u'http://
address': <email address hidden>'
fqdn_listname': <email address hidden>'
For better user management the following options should be seen as wishlist:
acknowledge_posts
hide_address
receive_list_copy
receive_
delivery_mode
delivery_status
in addition i requested _User.get_lists which is in https:/
+ what about users password ? users e-mails ...
Changed in mailman.client: | |
status: | New → Confirmed |
tags: | added: mailman3 |
Changed in mailmanwebgsoc2011: | |
status: | New → Triaged |
importance: | Undecided → Wishlist |
Changed in mailman: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
assignee: | nobody → Barry Warsaw (barry) |
milestone: | none → 3.0.0a8 |
summary: |
- REST and Client are missing membership_settings options + REST access to preferences |
Changed in mailman: | |
status: | Confirmed → Fix Committed |
Changed in mailman: | |
status: | Fix Committed → Fix Released |
Changed in mailman.client: | |
status: | Confirmed → Fix Committed |
milestone: | none → 1.0.0a1 |
To post a comment you must log in.
Actually, these are going to be interesting, because individual IMember preferences are stored in multiple places, and there's a _lookup() method that returns the first non-None value. This would probably be fine for read-only access, but if you want to write changes, where do you write them? I think that if you POST or PATCH any of the attributes, it changes them on the member directly (i.e. overriding any other value).