Search results for "Postorius" - Mailman-users

Re: Core, Hyperkitty and Postorius releases

by Odhiambo Washington

On Sat, May 15, 2021 at 12:24 AM Abhilash Raj <maxking(a)asynchronous.in> wrote: > > > On Fri, May 14, 2021, at 2:16 PM, Odhiambo Washington wrote: > > On Sat, May 15, 2021 at 12:01 AM Mark Sapiro <mark(a)msapiro.net> wrote: > > > > > On 5/14/21 1:54 PM, Odhiambo Washington wrote: > > > > > > > > /usr/local/include/sass > > > > > > > > That is the only thing found that is in the base system. > > > > > > And that's the one you want. What is it's mode? > > > > > > > root@gw:/usr/home/wash # ls -al /usr/local/include/sass > > total 104 > > drwxr-xr-x 2 root wheel 512 Apr 16 16:49 . > > drwxr-xr-x 176 root wheel 10240 Apr 19 18:05 .. > > -rw-r--r-- 1 root wheel 2369 Apr 8 11:08 base.h > > -rw-r--r-- 1 root wheel 10742 Apr 8 11:08 context.h > > -rw-r--r-- 1 root wheel 6632 Apr 8 11:08 functions.h > > -rw-r--r-- 1 root wheel 6489 Apr 8 11:08 values.h > > -rw-r--r-- 1 root wheel 198 Apr 8 11:08 version.h > > > > I imagined I needed an executable. > > This sounds like a result of you running `pip3 install sass`, probably > with sudo > which failed mid-way due to the exception you posted above. > Closer to the truth! It failed. I was running this from within the virtualenv. > Which OS are you using? FreeBSD. > On debian/ubuntu, you can install: > > sudo apt install sassc > Do I need to install sassc in the base OS or in the virtualenv? > I am not exactly sure how it got removed during your upgrade > to the new version of Mailman since it shouldn't affect your system > packages. > The funny part is my MM3 used to run. Mark took so much hand-holding for me to get it running. Then one day I used the update process and things got hosed. The happy part is that I had not put any production lists on MM3 as I hadn't developed the confidence of managing it. Did you install Mailman initially using system packages or instructions > provided at [1]? > > [1]: > https://docs.mailman3.org/en/latest/install/virtualenv.html#virtualenv-inst… No. I relied on https://wiki.list.org/DOC/Mailman%203%20installation%20experience. This is way back! Your new link is recent, no? -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 "Oh, the cruft.", egrep -v "^$|^.*#" :-)

4 years, 10 months

Re: remove website example.com via django interface

by Odhiambo Washington

On Wed, Mar 26, 2025 at 6:09 PM Alexander Inzinger-Zrock via Mailman-users < mailman-users(a)mailman3.org> wrote: > remove website 'example.com' via django interface > or > "how to rush jourself off your feet" > > > **Disclaimer: don't try this at home** > > > in believe to replace the display of 'example.com' in the > postorius-webinterface i logged into django-interface, under 'website' > (very bottom of the left menu) i added my new website and then deleted > 'example.com'. > > Result: i can't access my webinterfaces any more, neither django nor > postorius. > > > Questions: > > 1. Does somebody know about the correct approach to change the displayed > url in the postorius-webinterface? > The displayed URL should be the one you configured in Nginx or Apache. example.com is usually SITE_ID=1. It's possible to rename it in Django admin UI to whatever you want - like mywebsite.name > 2. does somebody perhaps know how to revert those removal via CLI or > other ways? > ``` SQL: select * from django_site; ``` Whatever ID shows for the one you created, stick that ID to settings.py and restart mailmanweb. -- Best regards, Odhiambo WASHINGTON, Nairobi,KE +254 7 3200 0004/+254 7 2274 3223 In an Internet failure case, the #1 suspect is a constant: DNS. "Oh, the cruft.", egrep -v '^$|^.*#' ¯\_(ツ)_/¯ :-) [How to ask smart questions: http://www.catb.org/~esr/faqs/smart-questions.html]

11 months, 2 weeks

Re: Fwd: Re: Removing a mail addresses and users

by Brian Carpenter

Allan Hansen wrote: > Some dedicated and skilled developers are currently investing heavily in a replacement > for Postorius, but I really believe that any work is better spent transforming Mailman > Core etc. into a true account-based system. Then, and only then, will it make sense to > build new and better interfaces on top, as, without a healthy core, such interface will > currently may have to inherit the confusion and disconnect that currently is so > aggravating. Mark said it well. The problem is not with core (which I love very much). The issue you are having is with the decision to use Django. With Affinity, I believe we are using Mailman 3 core to it's (almost) full potential. For instance, the server owner (site admin in Postorius terms) can delete a user with one button and that user is really gone. You can immediately register again with Affinity using the same email and you will have no problems re-registering. If the deleted user was subscribed to multiple lists and were not unsubscribed, then those lists will be waiting for him if/when he re-registers. So our decision to go with a new admin U.I. for Mailman 3 core, imo, has been a great decision. Mailman core is wonderful. One improvement we made is a user can delete their Affinity account but still remain subscribed. They also have the choice to unsubscribe from all their lists at the time of account deletion as well.

5 years, 9 months

[MM3-users]New Mailman 3 users list

by Mark Sapiro

I'm happy to announce a new list for Mailman 3 users and others interested in Mailman 3. This list is running on a new Mailman 3 installation at lists.mailman3.org. The list's posting address is <mailman-users(a)mailman3.org>. The list's info page is <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/> and its archives are at <https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/>. The top level Postorius page is <https://lists.mailman3.org/mailman3/> and the HyperKitty archiver is at <https://lists.mailman3.org/archives/>. You can subscribe by email by sending a blank message to <mailman-users-join(a)mailman3.org> and responding to the resulting confirmation request. You can also subscribe by going to the info page at <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/>, logging in and subscribing. Log in offers three options. There are Google and Facebook OAuth2 login links on the log in page to log in with a Google or Facebook account, and there is a 'Login by email' link to login via Persona with any address you register and confirm with Persona. This is a new installation of Mailman 3 so there are still kinks to work out, and any issues can be discussed on the list or reported to the trackers at <https://gitlab.com/mailman/postorius/issues>, <https://gitlab.com/mailman/hyperkitty/issues> or <https://gitlab.com/mailman/mailman/issues> as appropriate. Enjoy! -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

9 years, 11 months

Re: hello， Discussion on how to subscribe to the mailing list

by 朱超

At 2023-01-17 15:56:35, "Stephen J. Turnbull" <stephenjturnbull(a)gmail.com> wrote: >Mark Sapiro writes: > > > On 1/16/23 18:55, 朱超 wrote: > > > Hi, When I subscribe the email list in Subscription Policy is > > > confirm, Some problems happen in here： > > > 1.Some mail mua reject send the confirm the message, because the > > > length of recipient is too long. for exmaple: > > > requirements-confirm+9605556e0b35a5da280c1de0d34a3e6f770f8ea5@domain, > > > and the mail mua reject to modify about this. > > > > The default English template says in part: > > > > Before you can start using GNU Mailman at this site, you must first > > confirm that this is your email address. You can do this by replying to > > this message. > > > > Or you should include the following line -- and only the following > > line -- in a message to $request_email: > > > > confirm $token > > > > I.e. It gives an alternative method if `reply` doesn't work. You can > > provide a custom version of this template with different wording if you > > think you can improve it. > >The problem is the reply address, though. Changing the template to >suggest only the "confirm $token" in body method doesn't help people >who hit R expecting that should work, especially since many "user >fiendly" (misspelling intentional) MUAs don't display the address. >Avoiding that requires code changes, I guess? Yes, You got it. It is too cumbersome to ask the user to write a reply email for email confirmation. > > > > 2.It is inconvenient for users to use. Many people will > > > mistakenly think that after clicking the subscribe button, it > > > will be successful, and they will not process the email. > > > step, you can set Subscription Policy to Open, but then anyone can > > maliciously subscribe third parties to the list. > >*Please* do not do this if your server is exposed to the Internet. >There are bots that search for such servers, and sell lists of them to >people who want to DOS mailboxes. You may find yourself banned across >the Internet. > Yes.For service security, we will not set the Subscription Policy to open >The only real alternative to confirmation is approval by moderators. >I believe Mailman 3 offers that alternative as Mailman 2 did, can't >check at the moment. > > > > Regarding the discussion on the subscription method of the > > > mailing list, should we consider optimizing the subscription > > > method of the mailing list, for example: > > > 1. use the method of sending a verification code to subscribe by > > > email，When you receive the verification code sent by the > > > mailing list and fill it in again, you can subscribe > > > successfully。 > > > > How is this different from the present method. > >Just wording. I think they are thinking of the "invite" option that >was provided in Mailman 2 mass subscribe (again, I think Mailman 3 >retains it but I never ever used it so I don't recall for sure). But >it doesn't make sense for a user-initiated interaction. > > > If you want, you can make > > a custom template and include something like: > > > > Alternatively, you can confirm by going to the URL > > > > https://www.example.com/mailman3/lists/$list_id/confirm/?token=$token > >If I understand the OP's PoV correctly, I think I would change the >list information page to say "Send a personal invitation to join the >list to [email address here]. If you aren't a subscriber, you can >invite yourself." And change the word "confirm" in the confirmation >template to "subscribe". Why do you need to modify the mailman-core service， I suggest we should modify the code of the postorius, We can refer to postorius to reset the user password process， Detail, through the postorius to send email to user, and user click the url in email to confirm subscribe the email，Currently I have achieved it this way。 > > We don't include that in the default template because Mailman core > > doesn't know if you even have a web UI or how to access it if you > > do. > >We should fix that, at least if the web interface is Postorius >(wishlist, assigned to me): >https://gitlab.com/mailman/mailman/-/issues/1055 > >@mark >https://gitlab.com/mailman/mailman/-/issues/901 >Maybe we can close this? I'm not sure why it was left open since >there's no action proposed for Mailman improvement. > > > > 2. use the email to send a connection to confirm the > > > subscription，People click the link to be redirected to a > > > confirmation page to subscribe to the email。 > > > > See above. > >Indeed, AFAICS almost everything the OP is suggesting amounts to an >identical procedure as far as the Mailman server is concerned, it's >just described to the subscriber differently. The one exception is >the suggestion to eliminate the confirmation step, and while that is >supported, it's quite likely to cause problems for third parties and >eventually for the Mailman site unless you have an alternative ground >source of truth such as an employee database. > >Steve >_______________________________________________ >Mailman-users mailing list -- mailman-users(a)mailman3.org >To unsubscribe send an email to mailman-users-leave(a)mailman3.org >https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >Archived at: https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > >This message sent to tom_toworld(a)163.com

3 years, 2 months

delete examples.com site

by enrique.terrazas＠utsa.edu

Hello, I've been working on setting up Mailman3 on a RHEL 7.5 vm using the guides and documentation found here: http://docs.mailman3.org/en/latest/index.html https://mailman.readthedocs.io/en/latest/README.html http://docs.mailman3.org/projects/postorius/en/latest/index.html http://docs.mailman3.org/projects/mailmanclient/en/latest/README.html https://hyperkitty.readthedocs.io/en/latest/index.html https://gitlab.com/mailman/mailman-hyperkitty nginx is serving the Django applications via uwsgi. I was able to get mailman, postorius + hyperkitty, running and test sending out email verifications. In an attempt to set the default domain to something other than example.com I deleted the site: example.com, I did have another site. Unfortunately, this seems to have broken the Django applications. At the moment I am preparing to delete the virtual environment and set things up again. Unless there is something that can be done in the current virtual environment to "reset" things back to start. I was also running into an issue where the verification emails were successfully sent out. The url to verify the email looks like this: http://my.domain.com:8000/accounts/confirm-email/xxxxxxxxxxxx/ Replacing my.domain.com with the domain I added. How can I get the outgoing verification emails to not reference port 8000? If I take that same link and remove the port, I get the desired page. Port 8000 is blocked at our sites permitter firewall, I don't necessarily want to open it. I'd rather the URL just obfuscate the port and send it to https... Thank you in advance for your attention and assistance. Best regards, Enrique J. Terrazas

7 years, 5 months

Re: Avoiding non-members to be saved.

by Mark Sapiro

On 8/7/21 4:55 AM, Stephen J. Turnbull wrote: > Guillermo Hernandez (Oldno7) via Mailman-users writes: > > > Yesterday I had a problem with a private list. A spammer sent a mail > > forging one address that was a non-member (in fact was an "accept this > > no subscriber mails" from mailman 2.1 import) with very bad intentions > > and it was distributed. > > If you upgrade from Mailman 2 to Mailman 3, the accept_these_nonmembers > list for each list is grandfathered into the Mailman 3 list (from > rules/moderation.py): > > # Check the '*_these_nonmembers' properties first. XXX These are > # legacy attributes from MM2.1; their database type is 'pickle' and > # they should eventually get replaced. > for action_name in ('accept', 'hold', 'reject', 'discard'): > legacy_attribute_name = '{}_these_nonmembers'.format( > action_name) > > > There were no list of "accept this non members" in the Postorius > > config > > If there is no such list in Postorius, I would guess that some > developer thought "OK, this is a legacy feature and I'll get back to > it when we move it to the proper database" (unfortunate, but most of > us have open-subscription member-posts-only lists, and the current > workflow seems to work well, so this feature may not be so salient). Moderation in MM 3 works as follows: Is poster address a member. If so apply the member's moderation action, else Does poster address appear or match a pattern in the legacy (accept|hold|reject|discard)_these_nonmembers (first match in that order). If so, apply the appropriate action, else If the poster address is not a non-member, add it as a nonmember and apply the default nonmember moderation. > > I think it is solved now (deleting all and putting to hold just the > > non-members addresses that I would want to pass messages on) > > This should not be necessary, unless there were pre-approved addresses > that are no longer appropriate. But Mailman can't know that! The import21 process imports *_these_nonmembers by adding any regexps to the corresponding MM 3 *_these_nonmembers and adding any addresses as nonmembers with the appropriate moderation action. > > The fact is that any sender address of mails sent to the list is saved > > as a "non member", and it make me nervous as it will grow despite it is > > a legitimate message or not. This is the way MM 3 works. The only reason *_these_nonmembers exists in MM 3 is to support the legacy regexps from MM 2.1. For non-regexp addresses the address is a nonmember with the appropriate moderation action. I actually find this convenient. When a nonmember posts spam to a list and that spam is held, I discard the spam in Postorius and at the same time set the nonmember's moderation action to discard so I never see any more from that address. Also, when someone who I recognize as a list member posts from an alternate nonmember address, I can accept that post and set the nonmember address moderation action to default processing. > As far as I can see there is no other rule except that legacy rule > (and the rule that accepts all posts, which is rarely used) that will > accept a post from nonmembers. As I note above, nonmembers and members alike have a moderation action which can be any of Hold, Reject (with notice), Discard (no notice), Accept (without any further checks), Default Processing (continue with additioal checks) or the list's default action for (non)members. -- Mark Sapiro <mark(a)msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan

4 years, 7 months

Re: Where does sender postorius@ come from?

by Odhiambo Washington

The addresses are defined in Django settings if I'm not mistaken. And callout isn't evil. On Wed, Jun 7, 2023, 23:31 Jens Günther <jens.guenther(a)posteo.de> wrote: > I just realized, that mails for registering an account and/or resetting > ones password are obviously sent from postorius@SERVE_FROM_DOMAIN. Why > are they not sent from MAILMAN_ADMIN_EMAIL? > > The problem is: > - an account is trying to register with a mailaddress from a > HostEurope-server > - HostEurope-Servers are doing Sender-Callouts (bad practise :-D) to > verify that a mailaccount exists > - mail is then bouncing, b/c those are not answered (shoud I?): > status=bounced (host [80.237.138.5] said: 550-Sender verification is > required but failed. > - bounce then can't be processed, since mailaccount does not exist :-D > status=bounced (mail for SERVE_FROM_DOMAIN loops back to myself) > > Am I missing something are shouldn't it be better to send those mails > from MAILMAN_ADMIN_EMAIL? (I don't want to mess with these sender > callouts or change anything, HostEurope has been a little bit of a pain > in the ... with mailinglists and not much help at all). > > Thanks in advance, Jens. > _______________________________________________ > Mailman-users mailing list -- mailman-users(a)mailman3.org > To unsubscribe send an email to mailman-users-leave(a)mailman3.org > https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ > Archived at: > https://lists.mailman3.org/archives/list/mailman-users@mailman3.org/message… > > This message sent to odhiambo(a)gmail.com >

2 years, 9 months

Re: error changed after restart

by Guillermo Hernandez (Oldno7)

On 7/2/21 19:04, Abhilash Raj wrote: > > On Sun, Feb 7, 2021, at 1:07 AM, Guillermo Hernandez (Oldno7) via Mailman-users wrote: >> On 6/2/21 21:19, Abhilash Raj wrote: >>> >>> On Sat, Feb 6, 2021 at 19:44, Guillermo Hernandez (Oldno7) via >>> Mailman-users <mailman-users(a)mailman3.org> wrote: >>>> On 6/2/21 18:08, Abhilash Raj wrote: >>>> >>>> On Sat, Feb 6, 2021, at 3:04 AM, Guillermo Hernandez (Oldno7) via >>>> Mailman-users wrote: >>>> >>>> I restarted de server and the error changed. Now the log >>>> shows "KeyError: 'subscription_mode'": >>>> >>>> Did you also restart Mailman Core after the upgrade? >>>> >>>> Yes, indeed: I stopped mailman core and all the processes related. >>>> Did the upgrades. Started all again. Find the errors in the web user >>>> interface. Stopped all again. Looked for errors in the log. Restarted >>>> the complete server. Found the second error that this second mail is >>>> about to. It happens when, in the main page that shows all the lists >>>> you click to see one of them. It seems to me that it has been >>>> database structure changes in django that the upgrade is not aware... >>>> but it's a very long shot from my side. >>> `subscription_mode` was added in Mailman Core 3.3.2 and it is actually >>> a derived atrribute and not stored in Database. Mailman's API should be >>> returning this attribute for each Member, but for some reason it seems >>> to me like it isn't doing that even though do have Mailman 3.3.3 running >>> like you said. >>> If you have Curl installed, can you send me the output of: >>> $ curl -u <user>:<pass> http://localhost:8001/3.1/members?count=5&page=1 >> This is the output you asked for (it's the same you can see when you try >> to interact with one list): >> >> /usr/local/mailman3 # curl -u XXXXXX:XXXXXX >> http://localhost:8001/3.1/members?count=5&page=1 >> /usr/local/mailman3 # <html> >> <head> >> <title>Internal Server Error</title> >> </head> >> <body> >> <h1><p>Internal Server Error</p></h1> >> >> </body> >> </html> >> >> No log entry has been produced... > This is weird, if you have working Core, then there should be *some* json returned > from the above command. Do you have the Gunicorn running? I have the uwsgi approach running... > What is the > output of `ps -ef | grep mailman`? none but if I do an ps ax | grep mailman it shows /usr/local/mailman3 # ps ax | grep mailman 26803 - IsJ 0:00.87 /usr/local/bin/python3.7 /usr/local/bin/master --force -C /usr/local/mailman3/var/et 26834 - SJ 0:07.57 /usr/local/bin/python3.7 /usr/local/bin/runner -C /usr/local/mailman3/var/etc/mailma 26835 - IJ 0:05.84 /usr/local/bin/python3.7 /usr/local/bin/runner -C /usr/local/mailman3/var/etc/mailma 26836 - SJ 0:07.16 /usr/local/bin/python3.7 /usr/local/bin/runner -C /usr/local/mailman3/var/etc/mailma 26837 - SJ 0:08.74 /usr/local/bin/python3.7 /usr/local/bin/runner -C /usr/local/mailman3/var/etc/mailma 26838 - SJ 0:03.16 /usr/local/bin/python3.7 /usr/local/bin/runner -C /usr/local/mailman3/var/etc/mailma 26839 - SJ 0:07.07 /usr/local/bin/python3.7 /usr/local/bin/runner -C /usr/local/mailman3/var/etc/mailma 26840 - SJ 0:08.12 /usr/local/bin/python3.7 /usr/local/bin/runner -C /usr/local/mailman3/var/etc/mailma 26841 - SJ 0:09.07 /usr/local/bin/python3.7 /usr/local/bin/runner -C /usr/local/mailman3/var/etc/mailma 26842 - SJ 0:07.45 /usr/local/bin/python3.7 /usr/local/bin/runner -C /usr/local/mailman3/var/etc/mailma 26843 - IJ 0:00.95 /usr/local/bin/python3.7 /usr/local/bin/runner -C /usr/local/mailman3/var/etc/mailma 26844 - SJ 0:07.27 /usr/local/bin/python3.7 /usr/local/bin/runner -C /usr/local/mailman3/var/etc/mailma 26845 - SJ 0:07.69 /usr/local/bin/python3.7 /usr/local/bin/runner -C /usr/local/mailman3/var/etc/mailma 26859 - IJ 0:01.01 /usr/local/bin/python3.7 /usr/local/bin/runner -C /usr/local/mailman3/var/etc/mailma 26860 - IJ 0:05.75 /usr/local/bin/python3.7 /usr/local/bin/runner -C /usr/local/mailman3/var/etc/mailma 50153 - IsJ 0:00.16 /usr/local/bin/uwsgi --ini /usr/local/mailman3/uwsgi.ini 50481 2 S+J 0:00.00 grep mailman 26808 1 SJ 0:02.09 /usr/local/bin/uwsgi --ini /usr/local/mailman3/uwsgi.ini 26832 1 IJ 0:00.00 /usr/local/bin/uwsgi --ini /usr/local/mailman3/uwsgi.ini > Are you able to run `mailman members` command to list the members of a list? Yes. All the commands are working as expected. > Also, how did you actually install Mailman? Using pip. Here is a detailled post of how I did put all together: https://forums.FreeBSD.org/threads/mailman-3.61050/post-488128 Thanks for your support > > Abhilash. > >> TIA. >> >> >> >> >>> It should ideally return an output that looks something like shown >>> here[1]. You >>> can put the username/password of Core's API server in the above command. >>> [1]: >>> https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/… >>> >>> Abhilash >>>> I'm using sqlite as django database and mysql for mailman. >>>> >>>> ERROR 2021-02-06 11:47:49,015 26798 django.request Internal >>>> Server Error: >>>> /mailman3/mailman3/lists/name_and_domain.of.the.list >>>> Traceback (most recent call last): File >>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py", >>>> line 119, in __getattr__ return self._get(name) File >>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py", >>>> line 86, in _get raise KeyError(key) KeyError: >>>> 'subscription_mode' During handling of the above exception, >>>> another exception occurred: Traceback (most recent call >>>> last): File >>>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/exception.py", >>>> line 34, in inner response = get_response(request) File >>>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/base.py", >>>> line 115, in _get_response response = >>>> self.process_exception_by_middleware(e, request) File >>>> "/usr/local/lib/python3.7/site-packages/django/core/handlers/base.py", >>>> line 113, in _get_response response = >>>> wrapped_callback(request, *callback_args, **callback_kwargs) >>>> File >>>> "/usr/local/lib/python3.7/site-packages/django/views/generic/base.py", >>>> line 71, in view return self.dispatch(request, *args, >>>> **kwargs) File >>>> "/usr/local/lib/python3.7/site-packages/postorius/views/generic.py", >>>> line 74, in dispatch return super(MailingListView, >>>> self).dispatch(request, *args, **kwargs) File >>>> "/usr/local/lib/python3.7/site-packages/django/views/generic/base.py", >>>> line 97, in dispatch return handler(request, *args, >>>> **kwargs) File >>>> "/usr/local/lib/python3.7/site-packages/postorius/views/list.py", >>>> line 295, in get member.subscription_mode == File >>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py", >>>> line 124, in __getattr__ self.__class__.__name__, name)) >>>> AttributeError: 'Member' object has no attribute >>>> 'subscription_mode' *********************** some info about >>>> the installed versions via pip list: pip list | grep django >>>> django-allauth 0.44.0 >>>> django-appconf 1.0.4 >>>> django-compressor 2.4 >>>> django-extensions 3.1.0 >>>> django-gravatar2 1.4.4 >>>> django-haystack 3.0 >>>> django-mailman3 1.3.5 >>>> django-picklefield 3.0.1 >>>> django-q 1.3.4 >>>> djangorestframework 3.12.2 pip list | grep mailman >>>> django-mailman3 1.3.5 >>>> mailman 3.3.3 >>>> mailman-hyperkitty 1.1.0 >>>> mailmanclient 3.3.2 pip list | grep postorius >>>> postorius 1.3.4 On 6/2/21 11:12, >>>> Guillermo Hernandez (Oldno7) via Mailman-users wrote: >>>> >>>> I've just upgrade mailman 3 installation following Mr. >>>> Sapiro advice: did a pip install --upgrade >>>> django-mailman3 hyperkitty mailman mailmanclient >>>> mailman-hyperkitty postorius I did a "python3 manage.py >>>> migrate" after, too. And all seemed to run well. All the >>>> lists showed in postorius via web, but when I try to >>>> accesss into one of them the browser shows an error. In >>>> the log you can see: *-*-*-*-*-*-* Traceback (most recent >>>> call last): File >>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py", >>>> line 119, in __getattr__ return self._get(name) >>>> File >>>> "/usr/local/lib/python3.7/site-packages/mailmanclient/restbase/base.py", >>>> line 86, in _get raise KeyError(key) KeyError: >>>> 'get_requests_count' .. (And after all the traceback >>>> lines) AttributeError: 'MailingList' object has no >>>> attribute 'get_requests_count' *-*-*-*-*-*-*-* The lists >>>> seem to be distributing messeages well.. but I cannot >>>> acces via web administration (django/postorius) Can >>>> anyone point me in the right direction to solve this, >>>> please? _______________________________________________ >>>> Mailman-users mailing list -- mailman-users(a)mailman3.org >>>> <mailto:mailman-users@mailman3.org> To unsubscribe send >>>> an email to mailman-users-leave(a)mailman3.org >>>> <mailto:mailman-users-leave@mailman3.org> >>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >>>> <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3org/> >>>> >>>> >>>> _______________________________________________ Mailman-users >>>> mailing list -- mailman-users(a)mailman3.org >>>> <mailto:mailman-users@mailman3.org> To unsubscribe send an >>>> email to mailman-users-leave(a)mailman3.org >>>> <mailto:mailman-users-leave@mailman3.org> >>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >>>> <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3org/> >>>> >>>> >>>> _______________________________________________ Mailman-users mailing >>>> list -- mailman-users(a)mailman3.org >>>> <mailto:mailman-users@mailman3.org> To unsubscribe send an email to >>>> mailman-users-leave(a)mailman3.org >>>> <mailto:mailman-users-leave@mailman3.org> >>>> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >>>> <https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3org/> >> >> _______________________________________________ >> Mailman-users mailing list -- mailman-users(a)mailman3.org >> To unsubscribe send an email to mailman-users-leave(a)mailman3.org >> https://lists.mailman3.org/mailman3/lists/mailman-users.mailman3.org/ >>

5 years, 1 month

Re: custom css?

by Jamie McClelland

>> However, I would like to modify how the web pages look (both >> postorius and hyperkitty). I noticed that the web interface on this >> server (lists.mailman3.org) looks much nicer than the one showing >> on my server. For one, on my installed instance, the left and right >> margins are not set, so content is flush with the edge of the >> screen. > > Most likely there's a problem accessing the CSS files for Postorius > and/or HyperKitty. Oh - if my default installation could look like the lists.mailman3.org then yes, I would be happy to have that and don't need to customize. > The easiest way in my experience is to find which of the directories > on the path to the CSS mailman-web needs doesn't have at least search > (o=x) set for both the 'mailman' user and the webserver user > (typically 'www-data' on Debian family OSes), and fix that. Look in > the error logs for both mailman-web and the webserver for "couldn't > access something.css". I didn't have any luck finding errors or any files with the wrong permissions. But... your suggestion led me to /etc/mailman3/mailman-web.py and this setting: COMPRESS_OFFLINE = True Which led me to run: mailman-web compress which resolved a number of CSS problems. Thank you! However, my archive page still doesn't look quite like the one on lists.mailman3.org. Specifically, I am not getting the nav bar with a blue background. The style setting the navbar background is present in the following file on my server: /usr/share/python3-django-hyperkitty/static/hyperkitty/libs/hyperkitty.css In the stanza: nav#navbar-main { background-color: #086dd7; } And, I can find that stanza in the output of the css file for lists.mailman3.org: https://lists.mailman3.org/static/CACHE/css/output.ea180573a244.css But I don't have it in the corresponding output of that file on my server. Any suggestions for debugging that missing stanza? I also tried re-running maiman-web collectstatic. And, maybe a more critical difference, is that on the lists.mailman3.org server, the output css file starts with: /*! * Bootstrap v5.1.3 (https://getbootstrap.com/) Whereas on my server it starts with: /*! * Bootstrap v4.3.1 (https://getbootstrap.com/) So maybe my remaining problems are due to a different version of Bootstrap being shipped in Debian Trixie? Lastly, maybe just unrelated noise, but when I run mailman-web compress I get this error repeated a few times (with different templates): Invalid template usersessions/usersession_list.html: 'humanize' is not a registered tag library. Thanks again for your help getting my web interface looking better. jamie

4 months, 1 week

Mailman-users search results for query "Postorius"