MIME-Version: 1.0
References: <1d060463-e562-7783-decd-b5a7f3c4c06c@cmatte.me>
 <CABUevEyBc9+zspBNE_TgKwtURKeuAsf++Wgszb8rnpDu=KPdKQ@mail.gmail.com>
 <1b4db143-3410-54c2-bb91-1242ae430bcd@cmatte.me>
In-Reply-To: <1b4db143-3410-54c2-bb91-1242ae430bcd@cmatte.me>
From: Magnus Hagander <magnus@hagander.net>
Date: Sat, 5 Feb 2022 18:24:22 +0100
Message-ID: 
 <CABUevEyrMwAsTG8c4ECj-zBBFsB-52CcKg02bkbkr=JBMz6_LA@mail.gmail.com>
Subject: Re: [PATCH] pgarchives: pglister_sync: import lists with
 subscriber_access set to True
To: =?UTF-8?Q?C=C3=A9lestin_Matte?= <celestin.matte@cmatte.me>
Cc: PostgreSQL WWW <pgsql-www@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CABUevEyrMwAsTG8c4ECj-zBBFsB-52CcKg02bkbkr%3DJBMz6_LA%40mail.gmail.com>
Precedence: bulk

On Wed, Feb 2, 2022 at 9:16 AM C=C3=A9lestin Matte <celestin.matte@cmatte.m=
e> wrote:
>
> > This should definitely be fixed.
>
> Thanks!
>
> >> By default, subscriber_access is set to False and there is no way to m=
odify that within the web interface.
> >> As a consequence, access to lists on private servers is restricted to =
superusers, and there is no easier way to modify that than to edit the data=
base manually.
> >>
> >> It seems more logical to me that this value be set to True by default,=
 as access can still be moderated to avoid lists being publicly available.
> >
> > In what way would access "still be moderated"? In pgarchives, that's a
> > pure boolean and there are no further checks. User accounts are
> > auto-created.
>
> I meant that subscriptions can still be moderated in pglister (if lists a=
re configured that way), so that anybody does not have access to archives.

Ah, right. That still doesn't fully solve the problem though --
because once somebody has been approved in moderation, they
automatically get access to everything on the list from before they
were added. Which may not be what's wanted -- we have cases where
we're archiving things for "no regular use", but leave it for
superusers to be able to go look things up in an emergency for
example. In that usecase, it's not tied to the subscription at all.


> > The idea is that anything that's "open" should have to be set
> > explicitly and thus we should default to it being off. Based on that I
> > have at least initially applied a version of your patch that sets it
> > to false.
>
> That makes sense.
>
> >> That said, it may be better to have a way to modify that within the we=
b interface in pglister.
> >
> > I agree in principle. The argument does fall off a bit on the fact
> > that there is *no* admin interface to pgarchives. You don't have a way
> > to add a list manually either, without doing it directly in SQL. So we
> > either accept that SQL is the way things are done, or we should tackle
> > the bigger problem of setting up such an interface. But I think we
> > could get pretty far by just enabling the general django admin
> > interface and set up the required classes for that -- we don't
> > necessarily need to move things like reparsing and hiding of messages
> > into such an admin interface.
>
> I meant this could be added in the admin interface of pglister, not pgarc=
hives, as it already exists and pglister_sync can then push (and update) th=
e configuration to pgarchives.

Ah, then I understand.

That's an interesting aspect. Right now, pglister has no knowledge of
what actually runs on the archiving side other than "send the emails
over here" and "create links that look like this".

In general, I like that level of disconnect -- it should be possible
to swap out the archive solution from underneath it, or indeed run the
same pglister instance against multiple different types of archives.

--=20
 Magnus Hagander
 Me: https://www.hagander.net/
 Work: https://www.redpill-linpro.com/