Hey,
As a Debian fanboy and also a mailman addict, I'd like to try packaging it
in Debian. As I'm not a DD and as I'm not in a hurry, I'd like to take some
time to think about what would be relevant.
For that, I'd like to have some help. And I was suggested to come here and
ask.
I decided to use https://gitlab.com/groups/mailman as a basis for my work.
First of all, to create the source package, I've to think about what to put
in it.
It seems that if I want to have a good source package, I need 5 repos :
- Mailman
- HyperKitty
- Postorius
- HyperKitty - MailMan Plugin
- MailmanClient
My first question is "Am I right?". And the second one is whould I consider
looking into mailman-suite-doc and also have it in the source package?
On another way, I also see that there is a standalone postorius repo and
also some django project files for HyperKitty in another one. I have the
impression it is more designed for people to work on as standalone -
forkable projects for other features, and so I wouldn't need them in a
Debian package.
Am I also right?
Thanks for your answer, I hope I'll be able to make this package look as
you'd like. :)
Cheers,
--
PEB
Hi,
Mozilla is dropping Persona and shutting it down later this year [1].
Postorius and Hyperkitty will have to drop it, and use something else as a default login mechanism.
I propose using the django authentication system by default and making it easy for people to add
other authentication methods.
If we go with django authentication we can either build everything ourselves (I did it for a couple
of projects myself) or use some provided project. This is because django doesn't offer registration
views and email confirmation. Also password changing and password resetting will have to be added.
I know of two projects that do that already:
django-user-accounts [2]
It's part of the pinax platform, but can be used independently of the other components. It comes
with everything we need and not much more. Note that the profiles of django-user-accounts can
contain additional emails, which we probably don't want. It's officially supporting django 1.8 and
1.9. I'm not sure about our django dependency policy but since upstream has marked all pre 1.8 as
being out of date, I think that we can move on as well...
django-userena [3]
Pretty much the same as django-user-accounts but it has additional "features" like messaging which
we definitely don't need. It's not yet django 1.9 compatible but there is a merge request that adds
support for it.
Since we have two projects to maintain, I'd rather go with an external app. I guess it would be
easiest to have exactly the same configurations for Postorius and Hyperkitty. In order to not
duplicate any templates and other code, I'd propose to create a third project that has all the
account functionality and put everything we need in there.
In case we go with doing everything ourselves, I guess it's still better to create a separate app
for that.
My personal favorite is django-user-accounts for which I have some basic functionality in a merge
request for Postorius so you can have a look at what needs to be changed. [4]
Regardless of what approach we choose, we should also think of migrations.
Existing internal django accounts can be easily migrated. We'll have to choose if we want to migrate
the "social" accounts as well or just tell people to sign up again.
We still have time for the transition, but I'd prefer dropping persona before the 3.1 release if
that happens to come before the shutdown.
What do you think?
Simon
[1]: https://wiki.mozilla.org/Identity/Persona_Shutdown_Guidelines_for_Reliers
[2]: https://github.com/pinax/django-user-accounts
[3]: https://github.com/bread-and-pepper/django-userena
[4]: https://gitlab.com/mailman/postorius/merge_requests/73
Hi Tarunjit,
On 01/24/2016 08:38 PM, Tarunjit Singh wrote:
> Hi Fellow Developers,
>
> I am a graduate student at University of Toronto, Canada who likes to code
> (mainly in python).
> I just started to get to know the Mailman product by studying its
> architecture available on Aosabook <http://www.aosabook.org/en/mailman.html>
Awesome! That particular article really sums up the architecture of
Mailman. If you want to know more, look at Barry's talk/notes from PyCon
2012.
> and I am looking forward to contribute to the organization. After reading
> some of the email chains, I am assuming the best place to start is by
> looking into issues available here
> <https://gitlab.com/mailman/mailman/issues/> once I have a better
> understanding on the product but any newbie advice/guidance is welcome.
Yes, you are on the right track. Try looking for issues that are marked
"easy" or "beginner-friendly", though there aren't many. You can look
for bugs in Postorius[1] or Hyperkitty[2] too if you like. They feed
upon the REST API from the core and are Django based front-end and
archiver respectively.
Also, instead of solving some random bugs, you can also find a
particular project from the ideas page that interests you and try
solving some easy but small "parts" of the project that you can submit
as an independent patch. Even if you don't end up working on that
project, it would help you to know the wiring[*] inside mailman a lot
better.
[1]: https://gitlab.com/mailman/postorius/issues
[2]: https://gitlab.com/mailman/hyperkitty/issues
[*]: There is a lot of wiring and moving parts in mailman. So feel free
about asking about anything that don't understand, even if its very trivial.
> Thanks
> Tarunjit Singh
> _______________________________________________
> Mailman-Developers mailing list
> Mailman-Developers(a)python.org
> https://mail.python.org/mailman/listinfo/mailman-developers
> Mailman FAQ: http://wiki.list.org/x/AgA3
> Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/
> Unsubscribe: https://mail.python.org/mailman/options/mailman-developers/raj.abhilash1%40…
>
> Security Policy: http://wiki.list.org/x/QIA9
>
--
thanks,
Abhilash Raj
On 01/30/2016 11:11 AM, Harshit Bansal wrote:
> Hi Steve,
>
> On 1/27/16, Stephen J. Turnbull <stephen(a)xemacs.org> wrote:
>> Harshit Bansal writes:
>>
>> > Figure out how to store and access the styles as some of them are
>> > defined in the source code and the ones created by the by users would
>> > have to be stored in databases?
>>
>> You also need a read/print repr. A Python dict may be a reasonable
>> one, but JSON, YAML, init, etc could all be considered.
>>
>
> I am planning to use dictionary.
What exactly I meant here was not a data structure but *how*? The data
structure could simply be dictionary, but how would you populate the
existing styles in the code? Notice that there is already an existing
IStyle interface in the mailman right now, can you modify it somehow to
dynamically update/fetch/store styles from the database instead of
creating a new structure altogether?
Barry: Is there a reason the styles in the src/styles/base.py are not an
implementation of IStyle interface?
If I am not wrong, you can define the styles in configuration too apart
from the source code, so how do you pull those and update the database
during the initialization?
This is not a difficult question I want an answer to right now, just
that the application should have implementation details too, even if
they are a rough sketch.
>
>> > Styles will be stored in database in a dedicated table.
>>
>> You may want more than one table. Or you may be able to store them in
>> the same table as currently used for list configs, with that table
>> updated to allow "unstyled" as a value for its columns. (List id,
>> for example, would be "unstyled", since it is supposed to be globally
>> unique. Probably list name should be too, but domain would very
>> likely be styled.)
>>
>> > The style manager will update all the styles 'predefined in the
>> > source code' as well as the styles 'defined by users(by
>> > implementing the IStyle interface)' to the database. Currently we
>> > define a list of python import paths which are used for styles.
>>
>> Do you mean "configs"?
>>
>> > These will be collected in the style manager and then updated in
>> > the database. These styles will be publicly viewable but the users
>> > wouldn't be able to modify/change them(using Postorius) otherwise
>> > we would have to update those changes in the files as well.
>>
>> I don't understand why you wouldn't be able to modify them. The
>> presets probably should be read-only, and you might want to have a
>> permissions system such that only the owner of the style can change
>> it. Others would need to copy the style, modify the copy, and then
>> apply it to their own lists.
>>
>
> Here, I meant to say that the 'predefined-styles' would be
> read-only(not modifiable) while the style defined by the user(using
> Postorius) would be readable/editable as per the permissions system.
You may want to expand more on the *permissions system* in you
application as that is an important part of this. Also, how are you
going to propagate that to the Postorius via the API.
>
>> > Should we even allow changing list styles after lists have been
>> > created?
>>
>> Certainly. Consider the case where a dramatic improvement in MUAs
>> commonly used by a subscriber base makes it possible to use Wrap
>> Message instead of Munge From as DMARC mitigation. You want to change
>> all your lists in one go if they all have the same subscriber base
>> (consider an enterprise setting where the subscribers are mostly using
>> enterprise webmail).
>>
>> > Does changing a list style in database/source code changes
>> > the settings for list?
>>
>> IMO, yes. But source code changes by the Mailman Project would not be
>> allowed, except with a looong deprecation/obsoletion cycle, and source
>> code changes should be documented as an operation with potential (bad)
>> surprises for users.
>>
>> > I think there is no valid reason to not to allow changing list styles
>> > after they have been created but there are two attributes about which
>> > I am not sure these are:
>> > 1: default_member_action
>> > 2: default_nonmember_action
>> > The value of these style attributes are first copied to
>> > 'member.moderation_action'(moderation_action column of member table)
>> > and then this saved value is used to decide the correct moderation
>> > action. So changing the value of 'default_member_action' and
>> > 'default_nonmember_action' have no effect on the saved values and
>> > these will not change. This will have an undesired effect.
>>
>> I think that this is not a problem. We need to initialize all
>> attributes to valid values, and this will probably be hard-coded in
>> the source. Then we overlay this with site styles, domain styles,
>> list styles, and user attributes, and do the lookup in the opposite
>> order. In principle, for each attribute you would drill down as long
>> as the value at the current level is "unstyled". In practice, you'd
>> keep a cache of the current results of such lookups for users and
>> lists to avoid slamming the database, and some way of identifying when
>> the cache is out of date (such as a change "generation counter").
>> Note that this explains some of the reason why source code changes
>> need to be treated with care -- in some sense they are always
>> "generation 0" because it's impossible to know in advance what
>> generation the installlation is at.
I *think* we have had a discussion before about what should be a better
default value for member.moderation_action and
nonmeember.moderation_action. Instead of just copying them to the field,
we could set it to defer in which it case the lookup automatically picks
up the value of the list's default_(non)member_action.
Or we could *always* copy the default styles to a new style that the
list owner owns and can use for his other lists. This way he can change
values in the default styles too. This way, we don't have to deal with
user's being affected by the change in the default styles. Along with
that we could provide them with an option to update the styles
automatically from the default (when it changes) to fetch any new values
added/removed/updated. This however might introduce a *lot* of
redundancy in the database. Just a possibility, not very sure if this is
a good idea.
>>
>> > So I think whenever a user changes these two attributes then we
>> > will have to ask the user if he wants to change the saved values or
>> > not. Another approach could be to leave these values unchanged and
>> > bring this behavior to the knowledge of the user and if he wants
>> > then he can manually change the moderation action of some selected
>> > members but new members will automatically have their
>> > moderation_action set to new the values.
>>
>> This is the current behavior for default_* actions; I don't see why it
>> would change with the introduction of styles.
>>
>
> I wanted to ask that what should be the behavior when a user changes
> the 'default_member_action' and 'default_nonmember_action' attributes.
> Since, the values of these attributes are copied to the
> 'member.moderation_action' at the time of the creation of a new
> member. So, any changes made to the 'default_member_action' and
> 'default_nonmember_action' attributes will not be reflected in the
> already created members which I think may not be the desirable
> behavior.
> Please do correct me if am wrong somewhere.
See my comment above about the default behavior.
>> > How to apply styles to lists after they have been created? I will
>> > expose the styles via REST API. Whenever the user(admin) will
>> > change a mailing list's style in Postorius, it will automatically
>> > call 'new_style.apply()' function which will update the mailinglist
>> > table with the new values. This will change the list style.
>>
>> Be careful here. Since some styles percolate up to user level, a site
>> with hundreds of thousands of lists and millions of users (they
>> exist!) could really slam the database. The whole system would grind
>> to a halt.
>>
>> > After implementing all these things, there will be two ways to create
>> > and update styles :
>> > 1: Using Postorius
>> > 2: By defining a class implementing the IStyle interface and saving it
>> > to a file.
>>
>> I don't see why you would allow 2 at all. IStyle is an internal
>> thing, which would be used to provide a Python interface to the
>> database backend. Unless you're thinking of dynamic styles (eg,
>> theming the list page according to day of week or server load :-)?
>>
>
> Earlier, I was thinking to implement a way to add new styles using
> Postorius as well as by adding a file to the source code containing a
> class implementing the 'IStyle' interface to define the new style. But
> now I have dropped this idea as I think that it would not be that
> useful.
You cannot let users add stuff in the source code, configurations are
meant for the values that can be adjusted by users. AND you can add
styles via configs.
--
thanks,
Abhilash Raj
On Jan 30, 2016, at 08:49 PM, Aditya Divekar wrote:
>I have just started working on the mailman project. I am currently trying
>to solve Issue #186 and need help in testing, to check if my recommended
>fix is correct. any help would be appreciated.
There are some comments about manual testing in the issue, but for any branch
to land, it needs to have a test case that covers the new code. There's lots
and lots of examples of both doctests and unittests, and I will try to add
some more useful information to the in-tree documentation. If you're unable
to write a test for your branch, please indicate as such in your merge
request, and I will take a crack at it. Note though that an MR without tests
can mean a delay in merging.
For now, see src/mailman/docs/START.rst and DEVELOP.rst.
Cheers,
-Barry
Harshit Bansal writes:
> Figure out how to store and access the styles as some of them are
> defined in the source code and the ones created by the by users would
> have to be stored in databases?
You also need a read/print repr. A Python dict may be a reasonable
one, but JSON, YAML, init, etc could all be considered.
> Styles will be stored in database in a dedicated table.
You may want more than one table. Or you may be able to store them in
the same table as currently used for list configs, with that table
updated to allow "unstyled" as a value for its columns. (List id,
for example, would be "unstyled", since it is supposed to be globally
unique. Probably list name should be too, but domain would very
likely be styled.)
> The style manager will update all the styles 'predefined in the
> source code' as well as the styles 'defined by users(by
> implementing the IStyle interface)' to the database. Currently we
> define a list of python import paths which are used for styles.
Do you mean "configs"?
> These will be collected in the style manager and then updated in
> the database. These styles will be publicly viewable but the users
> wouldn't be able to modify/change them(using Postorius) otherwise
> we would have to update those changes in the files as well.
I don't understand why you wouldn't be able to modify them. The
presets probably should be read-only, and you might want to have a
permissions system such that only the owner of the style can change
it. Others would need to copy the style, modify the copy, and then
apply it to their own lists.
> Should we even allow changing list styles after lists have been
> created?
Certainly. Consider the case where a dramatic improvement in MUAs
commonly used by a subscriber base makes it possible to use Wrap
Message instead of Munge From as DMARC mitigation. You want to change
all your lists in one go if they all have the same subscriber base
(consider an enterprise setting where the subscribers are mostly using
enterprise webmail).
> Does changing a list style in database/source code changes
> the settings for list?
IMO, yes. But source code changes by the Mailman Project would not be
allowed, except with a looong deprecation/obsoletion cycle, and source
code changes should be documented as an operation with potential (bad)
surprises for users.
> I think there is no valid reason to not to allow changing list styles
> after they have been created but there are two attributes about which
> I am not sure these are:
> 1: default_member_action
> 2: default_nonmember_action
> The value of these style attributes are first copied to
> 'member.moderation_action'(moderation_action column of member table)
> and then this saved value is used to decide the correct moderation
> action. So changing the value of 'default_member_action' and
> 'default_nonmember_action' have no effect on the saved values and
> these will not change. This will have an undesired effect.
I think that this is not a problem. We need to initialize all
attributes to valid values, and this will probably be hard-coded in
the source. Then we overlay this with site styles, domain styles,
list styles, and user attributes, and do the lookup in the opposite
order. In principle, for each attribute you would drill down as long
as the value at the current level is "unstyled". In practice, you'd
keep a cache of the current results of such lookups for users and
lists to avoid slamming the database, and some way of identifying when
the cache is out of date (such as a change "generation counter").
Note that this explains some of the reason why source code changes
need to be treated with care -- in some sense they are always
"generation 0" because it's impossible to know in advance what
generation the installlation is at.
> So I think whenever a user changes these two attributes then we
> will have to ask the user if he wants to change the saved values or
> not. Another approach could be to leave these values unchanged and
> bring this behavior to the knowledge of the user and if he wants
> then he can manually change the moderation action of some selected
> members but new members will automatically have their
> moderation_action set to new the values.
This is the current behavior for default_* actions; I don't see why it
would change with the introduction of styles.
> How to apply styles to lists after they have been created? I will
> expose the styles via REST API. Whenever the user(admin) will
> change a mailing list's style in Postorius, it will automatically
> call 'new_style.apply()' function which will update the mailinglist
> table with the new values. This will change the list style.
Be careful here. Since some styles percolate up to user level, a site
with hundreds of thousands of lists and millions of users (they
exist!) could really slam the database. The whole system would grind
to a halt.
> After implementing all these things, there will be two ways to create
> and update styles :
> 1: Using Postorius
> 2: By defining a class implementing the IStyle interface and saving it
> to a file.
I don't see why you would allow 2 at all. IStyle is an internal
thing, which would be used to provide a Python interface to the
database backend. Unless you're thinking of dynamic styles (eg,
theming the list page according to day of week or server load :-)?
Steve
I have just started working on the mailman project. I am currently trying
to solve Issue #186 and need help in testing, to check if my recommended
fix is correct. any help would be appreciated.
Hello Devs,
I am Manish Bisht. I am in second year of my engineering in
information technology. I want to provide the code for Ubuntu. I have
created many projects outside of my college projects. You can see all
at https://github.com/manishbisht. I am familiar with many languages
some of them are HTML, CSS, JavaScript, PHP, C/C++, Java, and I am
currently learning Python also.
Also apart from my college hours i have also started my own startup
with Run4Offers (http://www.run4offers.com/)
I have also interested in Graphics Designing also. I have the
knowledge of AdobePhotoshop, Adobe Illustrator and Adobe In Design. I
have created many
images of various festivals for my College Entrepreneurship Cell(TOPAZ).
This is all about about me.
I am new to open source communities. I want to work on the GSOC-2016 projects
of Mailman and want to start contributing to it. Can anyone please help me
in contributing to Mailman.
Hope to see you soon :)
Thanks :)
Hi Harshit,
On 01/17/2016 09:22 AM, Harshit Bansal wrote:
> Hi everybody,
> I was looking at GSOC 2016 wiki page and I found "Preset List Settings
> Templates" project quite interesting.
>
> After reading out the project description and the discussion on the
> project from the mail archives I have been able to reach out the
> following conclusion :
> I will be required to develop a Web Interface that will allow the
> admins to set the different attributes to the different mailing lists
> using some fixed templates(also known as styles). Not only this they
> will be able to define their own styles and use them. This will serve
> as our front-end.
Your understanding is actually good, but more generic as of now. Styles
are the term used in Mailman to accumulate a certain list of
list-settings that change the behavior of the list. There are some
pre-defined styles like "Announce", "General", "Moderation" etc that you
can find in src/mailman/styles/base.py in the mailman-core source code[1].
Right now, styles can only be applied to a mailing list when they are
created. And there is no way right now to create new styles without
modifying the source code. The official Web UI for Mailman is called
Postorius and talks to the mailman-core via HTTP REST API. So you'd have
to expose the styles via REST API and then implement it in the Postorius
(which is a Django application).
Some major challenges for your project (not exhaustive) that I would
like to see addressed in the application are:
1) Figure out how to store and access the styles as some of them are
defined in the source code and the ones created by users would have to
be stored in database.
2) How to apply styles to lists after they have been created?
3) Should we even allow changing list styles after lists have been
created? Does changing a style in database/source code change the
settings for list?
4) See what happens when a style is changed now? Is it propagated down
to the lists or only the new lists inherit that?
> In the back-end, we will be using tables for storing style attributes
> and permission level(read only or editable). This table will basically
> contain all the "stylable" attributes with "default or predefined"
> values as contained in the mailing list table and one extra column for
> permissions.
Permissions should also consider if the user wants to make his new style
public or keep it private. And should public styles be editable by
anyone or just read-only?
One useful feature I can think of from the UI point of view is to be
able to copy an existing style to create a new style and then present
with the interface to customize the new style.
> There will also be some back-end python code whose key function would
> be to read the attribute values from the styles table and when the
> user applies a style on a mailing list it will copy the attribute
> values from the style table to that particular mailing list's table.
This "back-end" code is usually a part of Mailman-Core which takes care
of all the actual logic and mail processing.
>
> Please do correct me if I am wrong somewhere. Also,I wish to seek your
> views on this approach.
>
> Also tell me if I would need to develop a Command Line Interface(which
> I will love to develop) as well or only Web Interface would suffice?
I think an integration with Postorius would be sufficiently big for a
Summer. We already have a command line interface for mailman that can be
extended to add this functionality.
[1]: https://gitlab.com/mailman/mailman
--
thanks,
Abhilash Raj