On Tue, May 7, 2013 at 10:39 AM, Stephen J. Turnbull <stephen@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