[Mailman-Developers] GSOC Project Discussion

varun sharma varunsharmalive at gmail.com
Mon May 13 19:22:11 CEST 2013


On Tue, May 7, 2013 at 10:39 AM, Stephen J. Turnbull <stephen at xemacs.org>wrote:

> varun sharma writes:
>
> Thanks for the introduction!
>
>  > In my project "Better user settings management", i need to extend the
>  > Client class of mailman.client and i will be adding a lot of instance
>  > methods and variables to the class.
>
> Is this the right approach?  What are you adding (some examples will
> do at this time)?

Hi,
I apologize for replying to this post so late. I was having my end semester
exams last week, also i should have given more examples in my previous
post. As mentioned in my previous post, now i don't think there is any
immediate requirement to add more instance methods to _client module,
although some changes can be made in some cases so that more data from
mailman core interfaces (which is required to add the proposed features)
can be fetched with rest api calls.
Below are some examples of an possible implementation and core requirements
for getting the required data from mailman core using rest api.

New Features:

1. Suspend emails in vacation and post from multiple email ids:
IMember interface present in interfaces/member.py is already providing the
delivery_status enum in _client module via rest api but the user.save() is
currently not functional, so the member preferences are not getting saved
right now. Similarly, IUser interface in interfaces/user.py is providing
the user.addresses attribute from IAddress interface to _client module but
due to the problem of user object not getting saved, this functionality is
also not working. For these two features, i don't think there is any
requirement from mailman core interfaces.

2. Merge identities :
Not exactly sure about additional core requirements, but i think it can be
achieved by expanding IAddress interface.

3. User permissions management :
role attribute from IMember interface is being called in _Member of _client
module. It can be used along with other role options from MemberRole to
create a django form for user role management. Only the owner should have
the right to modify the member roles. This should be functional if
user.save() is fixed and here also i do not see any changes required in the
core.

4. Digest subscriptions from selected lists :
delivery_mode attribute  from IMember interface is called in _Member
preferences. As multiple members can point to same user, so digest
subscriptions for each member can be managed separately with no additional
changes in the core.

5. Domain page for every domain and ToDo Feature :
IDomain interface is providing all the required attributes to the _Domain,
so creating separate pages for every domain should not be a difficult task.
Regarding ToDo feature i need advice and help in creating a possible
implementation from community. Right now, what i have in my mind is that
all the pending tasks should automatically be added to the ToDo queue and
should be removed automatically upon completion of the required task. I
think there is a need to create some sort of task queue in the core for
that.

Improvements:
1. Edit/delete users :
delete_user method in _User from IUserManager interface is working fine.
Fixing of user.save() should fix this problem of editing user preferences
as well. So no change in core is required for this part.

2. Multi-addresses management in postorius:
addresses attribute from IUser and IAddress interfaces can be used to
manage the multiple addresses. creating a django form to manage the
multiple addresses should not take much time.

3. List subscribe/unsubscribe and subscription settings:
django template for list settings can be modified according to the
delivery_status attribute of member. The list subscription can be queried
by get_member method which returns the member object for the list and it
can be used in subscriptions settings page also.



> Specifically, there's been a lot of talk about providing extensible
> user settings *outside* of the core DB.  The idea is to provide access
> to existing enterprise databases (eg, LDAP organization directories)
> or special-purpose "social networking" databases.  How does your idea
> fit into or deal with this class of extensions?
>
> I may have misinterpreted it completely but I think the additional data
can be managed by django models as the additional data is not required in
mailman core,so a link can be established between the django User model and
mailman user just for the purpose of identifying the additional user data.
This will enable a login interface for all the users and the additional
user data can be stored in a different django model.

So, i think there is a need to do some changes in core for ToDo queue
management and for merging of different identities for now. I will be able
to find the exact implementation in next few weeks as i am following the
book "restful web services" for learning the rest basics and started
following some zope interface tutorials. Waiting for feedback from
community.


Thanks
Varun Sharma


More information about the Mailman-Developers mailing list