Mailman 3 Search results for "affinity" - Mailman-Developers

Re: RFC: Config complexity [was: I have issue where it does not send ...]

by Mark Sapiro

On 5/2/20 4:53 AM, Andrew Hodgson wrote: > > I fell foul of this myself to be honest and it took me a while to get it right in my head. One thing I was wondering is if the name of Mailman-Suite is possibly misleading, especially as there used to be a Mailman-Bundler in the past. Something like Mailman Web Bootstrapper (though that possibly needs refining). I agree that the name of the mailman-suite project is wrong because all it is is an example Django project for Postorius and Hyperkitty whereas the mailman-suite-doc project is aptly named as it is the source for <https://docs.mailman3.org/en/latest/> and does cover everything (so far; maybe in the not too distant future we will have Affinity and Empathy too). I was thinking along the lines of mailman-web or even mailman-web-example. Something more in line with its README which says > ============================= > Mailman Suite example project > ============================= > > This example project is meant to give you a quick development setup for using > both Hyperkitty and Postorius in a single Django instance, providing you a > web interface for Mailman 3 configuration and web access to the archives. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 11 months

Re: Is it possible to use Postorius alongside the legacy interface?

by Mark Sapiro

On 12/31/20 3:57 PM, Joe Corneli wrote: > Hello, > > I wonder if it's possible for users to choose between the new Postorius > interface and the old text-based interface? Some users might prefer the > text-based interface (e.g., for accessibility or just familiarity); others > may prefer the new interface (which does look quite snazzy!). But, I > didn't find any documentation about switching between the two. The short answer is there's no documentation because it isn't possible. I assume that by "the old text-based interface" you mean the Mailman 2.1 web UI. If you are asking if there is a way to have a web UI for Mailman 3 which mimics the Mailman 2.1 web UI, the answer is yes, but you'd have to create it. I.e., you'd have to implement the web pages in some kind of framework and have them communicate with Mailman core via it's REST API. Mailman 3 was designed to be modular in this respect and Postorius and HyperKitty are really just examples of web UIs for list management and archiving. Brian Carpenter of EMWD has php based alternatives called Affinity and Empathy, but they are proprietary and don't emulate the MM 2.1 UI at all. See <https://mail.python.org/archives/search?mlist=mailman-developers%40python.o…> for some discussion of these. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

3 years, 3 months

Re: New Admin Interface for Mailman 3

by Abhilash Raj

On Mon, Mar 2, 2020, at 12:14 AM, Stephen J. Turnbull wrote: > brian_carpenter(a)emwd.com writes: > > > After much thought, I have decided to break away from the use of > > Postorius/Hyperkitty. Tomorrow a PHP developer will begin work on > > brand new admin interface on my behalf. Here are my goals: > > I do have some comments. :-) > > Before any details, I'll say the core developers applaud this effort. > Though we'd like to think Postorius and HyperKitty are great as far as > they go, we've always believed that there are many uses cases for > Mailman they can't serve well. That includes but is not limited to > close integration with integrated platforms such as cPanel and > ticketing systems. > > > 2. To provide an easy installation approach to the setup and > > portability of the admin interface. > > This is likely to limit the use cases. I encourage you to think > carefully about that, and to prioritize the cases you know very well, > such as the needs of hosting service administrators. I won't be > surprised if you make a lot of ordinary users (subscribers) happy too, > but don't get overambitious. > > > 3. To reveal everything that Mailman core has via the new admin > > interface > > I myself am not sure why, but Barry has stated that it's hard to do > this, at least in the face of current pace of development of Mailman 3 > core. I love Barry and deeply respect his judgment, but I find the > idea itself offensive :-), so dealing with it on the core side is on > my own TODO list. Let's cooperate! > > > and perhaps to bring in additional features such as the ability > > to migrate a Mailman 2 list into a Mailman 3 list from a browser > > interface. > > This is already possible in Postorius and HyperKitty for > "well-behaved" Mailman 2 lists. Unfortunately I don't have a > definition of "well-behaved" (yet, and I don't think it's easy to > do). :-/ OTOH, from our point of view, this is a site administrator > decision, so doing the conversion at Mailman 3 installation time and > the site administrator's convenience is the logical process. > > Do you have a specific use case for this? Do you have users (list > administrators or virtual domain administrators) who want to try > Mailman 3 lists but continue some of their lists with Mailman 2? (I > still think this is unlikely to be something core development would > prioritize, but I'd like to have real data about it.) > > > 4. To bring in the use of stats that a list admin would like to see > > such as overall number of list members, which list is generating > > the most bounces, subscription/unsubscription rates, etc. > > These are surely going to require core-side features. Speaking for > myself, they are desirable features, and I'm pretty sure the core > developers will agree. > > These features (and more) are already implemented in the Systers forks > of Mailman. I can introduce some of their developers (if interested, > let's talk off-list, I don't have names and contacts off-hand). > > > 5. To provide a list creation wizard for list admins that will > > automatically create a list that has preset settings in place > > based upon the input during the list creation wizard. > > Again, this is going to require cooperation from core. We have a > feature called "list templates" for Mailman 3 in core, which we intend > to expose fully in Postorius and populate with common templates. Ask > Abhilash, who knows it best I think. > IIUC, what Brian needs is basically an ability to create "List Styles" in the web ui instead of having to make a code change for that purpose. Templates are mostly meant for emails sent out via Mailman in response to various events. > > The name of the new admin interface: Affinity > > "Affinity for Mailman [3]". I like it! > > Steve > _______________________________________________ > Mailman-Developers mailing list -- mailman-developers(a)python.org > To unsubscribe send an email to mailman-developers-leave(a)python.org > https://mail.python.org/mailman3/lists/mailman-developers.python.org/ > Mailman FAQ: https://wiki.list.org/x/AgA3 > > Security Policy: https://wiki.list.org/x/QIA9 > -- thanks, Abhilash Raj (maxking)

4 years, 1 month

Re: New Admin Interface for Mailman 3

by brian_carpenter＠emwd.com

>> Before any details, I'll say the core developers applaud this effort. > Though we'd like to think Postorius and HyperKitty are great as far as > they go, we've always believed that there are many uses cases for > Mailman they can't serve well. That includes but is not limited to > close integration with integrated platforms such as cPanel and > ticketing systems. Thank you. I am not concern with other platforms at the moment as I am with coming up with a more modern looking interface that is more intuitive to use. cPanel will probably stay with Mailman 2 for years to come and continue to provide their own patches if need to keep it functional. I will probably at some point make a serious attempt in coming up with a Wordpress plugin that integrates with Mailman 3. >> This is likely to limit the use cases. I encourage you to think > carefully about that, and to prioritize the cases you know very well, > such as the needs of hosting service administrators. I won't be > surprised if you make a lot of ordinary users (subscribers) happy too, > but don't get overambitious. Point taken. My main target is server and list administrators. List members will get some love as well but they are a lower priority. >> I myself am not sure why, but Barry has stated that it's hard to do > this, at least in the face of current pace of development of Mailman 3 > core. I love Barry and deeply respect his judgment, but I find the > idea itself offensive :-), so dealing with it on the core side is on > my own TODO list. Let's cooperate! Will do! >> This is already possible in Postorius and HyperKitty for > "well-behaved" Mailman 2 lists. Unfortunately I don't have a > definition of "well-behaved" (yet, and I don't think it's easy to > do). :-/ OTOH, from our point of view, this is a site administrator > decision, so doing the conversion at Mailman 3 installation time and > the site administrator's convenience is the logical process. > Do you have a specific use case for this? Do you have users (list > administrators or virtual domain administrators) who want to try > Mailman 3 lists but continue some of their lists with Mailman 2? (I > still think this is unlikely to be something core development would > prioritize, but I'd like to have real data about it.) I have in mind Mailman 2 list admins that are using Mailman via cPanel. cPanel dropped a bomb last September (I think) with a huge price increase for license users. The results were some large hosts made their intentions known that they were leaving cPanel for alternative or custom developed control panels. Most of these will not include Mailman or even any MLM application. So I suspect a lot of these users will need to be finding homes for their Mailman 2 lists and I think when any these come my way, and some have, it would be a good time to introduce them to Mailman 3. Two obstacles have hinder me in converting Mailman 2 users to Mailman 3: -- high load times for Mailman 3 processes -- less features for the mailing list side of Mailman (which Mailman 2 users held in higher priority) even though the archive side (Hyperkitty) had significant improvements to offer over pipermail. The high load times I was seeing was a concern but the recent upgrades to Mailman 3 has resolved them and now Mailman 3 hums along very nicely. However the lack of bounce processing, at least in the past, and other features, held me back from marketing the benefits of Mailman 3 to them. >> These are surely going to require core-side features. Speaking for > myself, they are desirable features, and I'm pretty sure the core > developers will agree. I am hoping to generate some of these stats from the logs of the MTA. cPanel uses something called eximstats to put mail statistics from Exim's logs into a MySQL database. It polls the data on a server and account wide basis. I absolutely love it because it tells me immediately which lists are not playing nice. I want list admins to have access to something like that so they can see what is going on with their roster. Most of my cPanel list admins don't bother going into cPanel to make use of eximstats. So I want to bring something like that to them in this new admin interface. >> These features (and more) are already implemented in the Systers forks > of Mailman. I can introduce some of their developers (if interested, > let's talk off-list, I don't have names and contacts off-hand). Is this a fork off of Mailman 3? Feel free to contact me anytime because I am interested to see what is out there. > > Again, this is going to require cooperation from core. We have a > feature called "list templates" for Mailman 3 in core, which we intend > to expose fully in Postorius and populate with common templates. Ask > Abhilash, who knows it best I think. I forgot about those templates and came across them today. They would work but I want something a little more powerful and elegant for list admins to use. I am trying to hit a home run with this. I may end up doing a bunt instead and getting thrown out at 1st. > > The name of the new admin interface: Affinity > > "Affinity for Mailman [3]". I like it! > Steve Thank you! Brian

4 years, 1 month

Re: Mailman Core 3.3.1rc1 release

by Brian Carpenter

On 4/10/20 3:31 AM, Abhilash Raj wrote: > Hey Everyone, > > I have just released Mailman Core 3.3.1rc1. The final release is scheduled for next week, 17th April. > > This release includes support for bounce processing, which had been lacking in Mailman 3 until now. So, after upgrading to this release, you will notice bounce related notifications from Mailman 3 being sent out to list owners if the list has bounce processing enabled (which, most list do by default). > > Postorius changes for new bounce processing options are coming out soon, I would like the current head to bake in a little longer since it went through bootstrap 4 upgrade recently. Expect it to be out in about a month. If your users would really care about bounce processing being enabled and not being able to tune threshold and notification parameters in the web interface, you might want to wait for Postorius's next release before upgrading. > > It also exposes all the remaining attributes of MailingList via REST API, so Postorius can expose them in the Web Interface. This should finally make all attributes of a MailingList manageable via Web Interface, without having to access command line interface. > > There has also been a whole lot of bug fixes. A full list of changes can be found at: > > https://mailman.readthedocs.io/en/latest/src/mailman/docs/NEWS.html#rc1 > > The release is available via PyPI: > > https://pypi.org/project/mailman/3.3.1rc1/ > > To install this release via pip, you can run: > > $ pip install --upgrade --pre mailman > > Note the `--pre` flag because this is a pre-release. > > If you can, I encourage you to try this out with your environment and report any major breakage to us. We have been running this code on the server hosting this list, so it has already seen some testing, but it is always nice to have some more. > > If there aren't any major breaking changes reported, the final release will be identical to this one. > Well this is exciting and timely. I plan on upgrading Mailman core on my development server today to 3.3.1rc1 so we can start implementing the new REST API elements into Affinity. I will keep you posted via Gitlab if we run into any issues. Thanks! -- Please let me know if you need further assistance. Thank you for your business. We appreciate our clients. Brian Carpenter EMWD.com -- EMWD's Knowledgebase: https://clientarea.emwd.com/index.php/knowledgebase EMWD's Community Forums http://discourse.emwd.com/

4 years

[GSoC] Some Questions in List Configuration Tool

by Stephen J. Turnbull

Steven Chen writes: > I am currently working on the proposal of List Configuration Tool in > GSoC idea list. Glad to hear it! > I wonder what kind of configurations should be exported, and what > should not. > Q1. We can get nearly all the configurations for a list from the > core's REST API > (https://mailman.readthedocs.io/en/release-3.1/src/mailman/rest/docs/listcon…), > but some of the data should not be exported, such as `created_at`, > `last_post_at`, and etc. Hence, we may need a filter to extract out > the meaningful configurations to export out. If you are migrating a list to a new host, you *do* want to export those details. At this level, I think it's probably more meaningful to separate the attributes into "read/write" (RW) and "read-only" (RO). The tool's UI should allow you to see everything, export everything, and change the RW attributes in place. RO attributes would include things like last_post_at, and maybe list_id (oops, that page doesn't mention the RFC 2919 List-Id attribute ... that should be part of the config!) Perhaps the list's addresses should not be RW by default but there could be a "hot stove" mode where you can change them. Also, there are partially identifying attributes like 'acceptable_aliases', which might be useful as initial values in some cases (for example, I have a tree of umbrella lists for my advisees depending on enrollment status and expected graduation year -- the all_students top umbrella list should be an alias for all the others). > I wonder whether we have a more convenient way to get all > meaningful configurations, No. There is the "collection" endpoint ".../config", and the individual resource endpoints like ".../config/display_name". These are written with the 'PUT' and 'PATCH' HTTP methods, respectively. That's it. > and what kind of configuration fields are expected to be exported > from the user's perspective? Look up "list styles". This is a partial configuration that can be applied to a new or existing list. I think that there are "stylable" options such as 'advertised', there are list-identifying attributes like 'display_name', > Q2. Besides all the configurations obtained from the listconf > mentioned in Q1, we have more configurations for a list, such as > member list. In the Idea Page > (https://wiki.list.org/DEV/Google%20Summer%20of%20Code%202021), it > says that the membership roster should not be included by default. > Since we already have the `list_mass_subscribe` method for importing a > lot of subscriptions at once, so should the list configuration tool > include the functionality to handle membership automatically or just > does not include the memberships in the exported configuration? I don't think this is necessary. Postorius already has a "good-enough" interface for this. > For Q1, I do have some thinking for some important configuration > fields that should not be exported: > owner_address: should be filtered out, since only the list owner can > import the configuration template, But this attribute is independent of the admin who does the importing. Also, you need to serve the host migration use case. > the owner_address should be set when the owner apply the > configuration template to the list instead of import from the > previous configuration. mail_host, fqdn_listname: should be > filtered out, since lists are created under the domains, domains > should be created before the lists are created. Hence, only the > name before the domain should be included in the exported > configuration, and the full fqdn_listname can be generated when > creating the list. Consider the virtual host use case, such as readthedocs. Suppose they migrate doc-sig(a)mailman.readthedocs.org to mailman.readthedocs.io. Then they need at least the subdomain "mailman." The styling use case should be more flexible. Perhaps a checklist of all RW attributes. > I do need more suggestions on what to choose in the configuration that > can be exported. Any suggestion is welcome. You might want to ask the users (specifically, mailman-users(a)mailman3.org). I would not worry too much about this, however. At this stage, you can have a tentative list of the kinds of attributes and which attributes are which kind. It's more important to think about use cases you want to serve, at least migrations and list styles, and maybe the tool can replace the current list configuration UI in Postorius. Also, is it just a backend for Postorius? Can it be written in Django? Or should it be written in Python, so it can be accessed from Postorius, the command line, and perhaps even EMWD's alternative Affinity management interface (that might be difficult since Affinity is written in PHP)? I forgot to mention this previously, but you should make your account on summerofcode.withgoogle.com *immediately*, and start your proposal there. Make sure all needed fields are filled out. You can edit up until the deadline (at least that was always true in the past). It hasn't happened for several years, but Google's site has crashed or been extremely congested just before deadline, and if you don't have a proposal filed at that point, you're out of luck -- Google has always been very strict about that. If the schedule is incomplete, we can deal with that, but if any required data doesn't have at least a starter draft, it's no go. (Of course we can't accept updates after the deadline, but we can accept updates off-line if the site is crashed.) For scheduling format, especially milestones, please refer to https://wiki.list.org/DEV/SPAM. I suspect that hasn't been updated since 2016 or 2017, so the URLs and some other information may be out of date. I also recommend reading at least the introductions to the articles on "Waterfall_Model" and "Test-Driven_Development" (TDD) on Wikipedia. I don't necessarily recommend either as a great way to plan a software development project, but they give some idea of the kinds of activities and events that go into a plan. The ideas of writing documentation (the spec) and tests (TDD) first are important to thinking about plans, even if you don't necessarily follow those particular methodologies. Regards, Steve

3 years

New Admin Interface for Mailman 3

by brian_carpenter＠emwd.com

Hello everyone. I have been a long time supporter of Mailman 2 and now 3. Most of my experience with Mailman has been as a service provider that offers managed mailman hosting both for version 2 and 3. I do have the benefit of a decade+ of insight into the use of Mailman from a list admin, moderator, and member point of view simply via my support ticket system that my Mailman clients have access to. I want to say that I appreciate all of the hard work that has been put into bringing Mailman 3 to life. I also appreciate the forward thinking that shows itself in the including of a REST api with Mailman 3 and the use of and support of databases such as postgreSQL and MySQL. I have been using Mailman 3 for over a year now in a commercial/production environment and have installed it on several servers using Docker and now from source. I received quite a bit of feedback from users this past year and also lost about 20% of my Mailman 3 users to other competing list/forum applications. The feedback I received was almost entirely due to shortcomings in the user interface. After much thought, I have decided to break away from the use of Postorius/Hyperkitty. Tomorrow a PHP developer will begin work on brand new admin interface on my behalf. Here are my goals: 1. Modernize the admin interface to meet modern design and interface standards. 2. To provide an easy installation approach to the setup and portability of the admin interface. 3. To reveal everything that Mailman core has via the new admin interface and perhaps to bring in additional features such as the ability to migrate a Mailman 2 list into a Mailman 3 list from a browser interface. 4. To bring in the use of stats that a list admin would like to see such as overall number of list members, which list is generating the most bounces, subscription/unsubscription rates, etc. 5. To provide a list creation wizard for list admins that will automatically create a list that has preset settings in place based upon the input during the list creation wizard. I am sure there are many hurdles to overcome in the process. When the inevitable questions arises that pertain anything to the Mailman side of this project, I hope I can count on this list for assistance. I am also interested in seeing if I can recruit some of you to test out the new admin interface for usability testing when I reach that stage. I am interested to find out if some of you that have enough experience in PHP to help contribute to this project. Bootstrap 4 and User Interface design skills would also be appreciated. The name of the new admin interface: Affinity Wish me well with this new project and let me know on or off list of anything that you would like to see change, removed, implemented into a new admin interface. Brian

4 years, 1 month

Re: New Admin Interface for Mailman 3

by Abhilash Raj

On Sun, Mar 1, 2020, at 4:37 PM, brian_carpenter(a)emwd.com wrote: > Hello everyone. > > I have been a long time supporter of Mailman 2 and now 3. Most of my > experience with Mailman has been as a service provider that offers > managed mailman hosting both for version 2 and 3. I do have the benefit > of a decade+ of insight into the use of Mailman from a list admin, > moderator, and member point of view simply via my support ticket system > that my Mailman clients have access to. > > I want to say that I appreciate all of the hard work that has been put > into bringing Mailman 3 to life. I also appreciate the forward thinking > that shows itself in the including of a REST api with Mailman 3 and the > use of and support of databases such as postgreSQL and MySQL. > > I have been using Mailman 3 for over a year now in a > commercial/production environment and have installed it on several > servers using Docker and now from source. I received quite a bit of > feedback from users this past year and also lost about 20% of my > Mailman 3 users to other competing list/forum applications. The > feedback I received was almost entirely due to shortcomings in the user > interface. > > After much thought, I have decided to break away from the use of > Postorius/Hyperkitty. Tomorrow a PHP developer will begin work on brand > new admin interface on my behalf. Here are my goals: > > 1. Modernize the admin interface to meet modern design and interface standards. > > 2. To provide an easy installation approach to the setup and > portability of the admin interface. > > 3. To reveal everything that Mailman core has via the new admin > interface and perhaps to bring in additional features such as the > ability to migrate a Mailman 2 list into a Mailman 3 list from a > browser interface. > > 4. To bring in the use of stats that a list admin would like to see > such as overall number of list members, which list is generating the > most bounces, subscription/unsubscription rates, etc. > > 5. To provide a list creation wizard for list admins that will > automatically create a list that has preset settings in place based > upon the input during the list creation wizard. > > I am sure there are many hurdles to overcome in the process. When the > inevitable questions arises that pertain anything to the Mailman side > of this project, I hope I can count on this list for assistance. I am > also interested in seeing if I can recruit some of you to test out the > new admin interface for usability testing when I reach that stage. I am > interested to find out if some of you that have enough experience in > PHP to help contribute to this project. Bootstrap 4 and User Interface > design skills would also be appreciated. > > The name of the new admin interface: Affinity > > Wish me well with this new project and let me know on or off list of > anything that you would like to see change, removed, implemented into a > new admin interface. > All the best! I really like the idea of having more than one option for users to choose from in terms of UI. It would truly make the Mailman Core's API efforts justified :) I've been quite out-of-sync with opensource work in past few months and my responses are often delayed. Do add me to To:, Cc: if it is something urgent that you'd like me response on though. Finally, I do want to mention that the REST API is extensible. So, if you need changes/additional details from the Core, we should be able to flush out the design and work on that. > Brian > _______________________________________________ > Mailman-Developers mailing list -- mailman-developers(a)python.org > To unsubscribe send an email to mailman-developers-leave(a)python.org > https://mail.python.org/mailman3/lists/mailman-developers.python.org/ > Mailman FAQ: https://wiki.list.org/x/AgA3 > > Security Policy: https://wiki.list.org/x/QIA9 > -- thanks, Abhilash Raj (maxking)

4 years, 1 month

Mailman-Developers search results for query "affinity"