Can "Pre Verified" set to yes by default?
We are a university with many departments & colleges owning their own mailing lists and they manage their members lists by themselves. The current (ours is 1.3.6) Postorius have a default of "Pre Verified" as "No" when doing mass subscription by the list admin. It sounds sensible if most people subscribe to the lists by themselves normally. But in our case, our departmental staff normally maintain their list of members and do not want their members need to do anything before they can be reachable from lists. However, some of our departmental staff sometimes forget to check the box "Pre Verified" when they refresh (actually delete all and subscribe all) list of members during term's start. This often lead to issue especially if the list they maintained have thousands of members. Our normal way to help them is to remove the list and create the list again so that the departmental staff do not need to discard the pending members one by one. This is already the best scenario if they know that it is the root cause. Since subscribing thousands of members normally will not have the normal UI page coming back (due to timeout), they often do not know that it is the cause of issue. If they repeat the steps to subscribe the members again, they will just not be able to get the job done but also make the system busier and they never know that it's already in the pending list.
Is this possible to add default setting of Pre Verified during mass-subscription (for example settings.py) such that we can help them a bit?
Thanks.
Alan So writes:
However, some of our departmental staff sometimes forget to check the box "Pre Verified" when they refresh (actually delete all and subscribe all) list of members during term's start. [...] Is this possible to add default setting of Pre Verified during mass-subscription (for example settings.py) such that we can help them a bit?
I don't know if there's a way to do this in settings.py, but I suspect not. Maybe Mark knows a way.
However, you can find .../site-packages/postorius/forms/list_forms.py (not sure exactly where that is in your instance but I guess you probably do), and find this code (AFAICT this is the unique instance of 'Pre Verified' in the whole Postorius code base) in that file:
pre_verified = forms.BooleanField(
label=_('Pre Verified'),
initial=False,
required=False,
help_text=_(
'If checked, users will not have to verify that their '
'email address is valid.'),
widget=forms.CheckboxInput()
)Then just edit the line
initial=False,to
initial=True,Note that this will get overwritten if you upgrade (or reinstall) Postorius, and you'll have to do it again. But it will save you a ton of grief until that happens.
Also note that if there *is* a way to do this in settings.py, it is *safe* to do that later without reverting the change to list_forms.py, and the settings.py setting will continue to work after any upgrade or reinstall. So you can patch list_forms.py now without worrying it will get you into trouble later.
Steve
On 12/19/22 00:21, Stephen J. Turnbull wrote:
I don't know if there's a way to do this in settings.py, but I suspect not. Maybe Mark knows a way.
Well, I haven't tried this and I don't recommend it, but while the intent of settings.py is to assign values to various known attributes, it is a Python module which is imported and could contain any valid Python code including code to read, modify and rewrite .../site-packages/postorius/forms/list_forms.py.
However, my recommendation is to maintain your local patches in a script that you can run following an update to apply them.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
I am a bit hesitated to somehow fork a branch which deviate from the main branch though it is just a small bit of code changes if we do not have any developers who would claim the ownership of the branch. I do not think that system admin is an appropriate role to take this up. More requests can come from the users which may not simply be "patches".
Instead, if the core team believe that the feature is useful and is willing to incorporate the feature to the main branch, I think that it is a better way of handling it. The change is also supposed to be more aligned with the design.
On 12/19/22 17:42, Alan So wrote:
Instead, if the core team believe that the feature is useful and is willing to incorporate the feature to the main branch, I think that it is a better way of handling it. The change is also supposed to be more aligned with the design.
The best way to get this feature request considered and possibly implemented is to file an issue at <https://gitlab.com/mailman/postorius/-/issues>.
-- Mark Sapiro <mark@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan
Thanks for the suggestion. I have just created https://gitlab.com/mailman/postorius/-/issues/563 . Hope that it will be considered.
Alan So writes:
Instead, if the core team believe that the feature is useful and is willing to incorporate the feature to the main branch, I think that it is a better way of handling it.
For some reason, admins always feel that way. ;-) We feel the opposite way. :-) Let me explain why.
This is a *really big* ask. *Every* configurable element of every screen has some sort of default, and somebody somewhere probably wants to be able to customize it. As my mentor on another project used to ask, "Why do all the defaults suck?" The answer seems to be, "well, they just do." For somebody, somewhere, anyway.
The problem isn't writing the code, I doubt it would be difficult to come up with boilerplate to allow sitewide configuration of all the defaults for all actions. The problem is thinking about the admin's user interface for this. Sure, we could put some kind of mechanism in settings.py, but how do we document all the configurable defaults? How do admins discover them except by asking on mailman-users? And changing that much code would probably be pretty tedious.
The change is also supposed to be more aligned with the design.
I don't understand what that's suppposed to mean. If you do it, you're changing a default, that's all. There's no real design here. It's just a question of the greatest good for the greatest number, which is an empirical question. You have a different answer for your site than most Mailman sites (which are open subscription and normally the admin has no real-world connection to subscribers, so verification of address is needed). Your request is perfectly reasonable, but similar requests for site configurations of every other default would be just as reasonable -- which implies a lot more work for us than you're willing to do for your list admins. Am I missing something?
Steve
Stephen J. Turnbull wrote:
The problem isn't writing the code, I doubt it would be difficult to come up with boilerplate to allow sitewide configuration of all the defaults for all actions. The problem is thinking about the admin's user interface for this. Sure, we could put some kind of mechanism in settings.py, but how do we document all the configurable defaults? How do admins discover them except by asking on mailman-users? And changing that much code would probably be pretty tedious.
:-) Thanks for exchanging the idea about adding codes for configuration or making customization. I can say that it is not purely a technical issue in an organization that whether system admin should maintain a few minor changes that are not in the main branch. Due to massive customization made to previous Mailman 2 installation by some student helpers which made it very difficult to be upgraded nearly 20 years ago, we tend not to repeat this pattern when we upgrade to Mailman 3 a few years ago. Therefore, we are now very cautious to accept request that need to change the codes. We do not want to give an impression to our business users that codes of an open-source software can be changed at no/low cost and without any maintenance cost.
I understand that coding is tedious and users often demand a lot of different things especially about the UI. It is one of the reasons why there are a lot of commercial product of opensource backend and closed source frontend. I really appreciate all of these development effort in the mailman project which focused in the (admin) frontend a lot, which usually create great unique differences in a commercial product.
After all, it is just one of the many suggestions that you received. I respect the decision of the core team. If the core team consider that this feature is low priority, it is fine not to implement it.
I don't understand what that's suppposed to mean. If you do it, you're changing a default, that's all. There's no real design here. It's just a question of the greatest good for the greatest number, which is an empirical question. You have a different answer for your
The supposed to here mean that you may try to solve the issue in some other ways. You may not add the options to change the default. I am not sure but maybe make them be settings of list or prompt an alert that a lot of email will be sent to confirm/verify. I believe that you probably read a lot more of opinion from others than me and so I think the core team can judge what should or should not be done after consolidating the opinions.
Hi Alan,
It occurred to me that Django template widgets are very flexible. It may be possible to customize the template to accomplish this task. In that case, the customized template would be kept in a place that doesn't get overwritten in an upgrade, reducing the maintenance cost (unless either Postorius or Django changes the template in a way that seems unlikely to me). I'll try to take a look at that over the holiday break -- that has the advantage that I just document how we did it for you, and tell any future requests to RTFM and DIY. ;-)
Alan So writes:
I can say that it is not purely a technical issue in an organization that whether system admin should maintain a few minor changes that are not in the main branch.
Sure, we understand that. I'd be interested to hear from business users and university users if they would like this particular default to be configurable. It's very easy to do as a one-off, if there is substantial demand we *can* do it, and later say to people who want similar changes that it's on them to demonstrate they have enough demand on their side for another one-off, just as was done for this one.
Due to massive customization made to previous Mailman 2 installation by some student helpers which made it very difficult to be upgraded nearly 20 years ago, we tend not to repeat this pattern when we upgrade to Mailman 3 a few years ago.
I agree, you need to be disciplined about what changes you are willing to develop and maintain. This one seemed to me to be over that bar, especially since you can put it in and not suffer too greatly if it gets reverted in a upgrade and the maintainers don't notice.
After all, it is just one of the many suggestions that you received. I respect the decision of the core team. If the core team consider that this feature is low priority, it is fine not to implement it.
Unless I see a lot of demand, I think as a one-off I don't want to implement it in list_forms.py, but rather let occasional admins do it on their sites if they want it that bad. But GSoC is coming up again; maybe a student would be willing to take on a generic "pwn all the defaults" project next summer.
Steve
Stephen J. Turnbull wrote:
Hi Alan, It occurred to me that Django template widgets are very flexible. It may be possible to customize the template to accomplish this task. In that case, the customized template would be kept in a place that doesn't get overwritten in an upgrade, reducing the maintenance cost (unless either Postorius or Django changes the template in a way that seems unlikely to me). I'll try to take a look at that over the holiday break -- that has the advantage that I just document how we did it for you, and tell any future requests to RTFM and DIY. ;-)
Many thanks for your effort especially during the long holiday. Really appreciate.
I agree, you need to be disciplined about what changes you are willing to develop and maintain. This one seemed to me to be over that bar, especially since you can put it in and not suffer too greatly if it gets reverted in a upgrade and the maintainers don't notice.
We do not always have full control of what we are willing to do. It is kind of a Pandora's box. Opening it up may lead to other requests which may no longer be patches but changes potentially conflicting with future upgrade. It is ok if people here recognize that we should have our own developers to participate in this kind of changes and also the maintenance but it is not the culture here. Particularly developers here are much more experienced in Win, C#, .NET than Linux, Python.
participants (3)
-
Alan So -
Mark Sapiro -
Stephen J. Turnbull