Message-ID: <1b4db143-3410-54c2-bb91-1242ae430bcd@cmatte.me>
Date: Wed, 2 Feb 2022 09:16:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.5.0
From: =?UTF-8?Q?C=c3=a9lestin_Matte?= <celestin.matte@cmatte.me>
To: Magnus Hagander <magnus@hagander.net>
Cc: PostgreSQL WWW <pgsql-www@lists.postgresql.org>
References: <1d060463-e562-7783-decd-b5a7f3c4c06c@cmatte.me>
 <CABUevEyBc9+zspBNE_TgKwtURKeuAsf++Wgszb8rnpDu=KPdKQ@mail.gmail.com>
Content-Language: en-US
Subject: Re: [PATCH] pgarchives: pglister_sync: import lists with
 subscriber_access set to True
In-Reply-To: 
 <CABUevEyBc9+zspBNE_TgKwtURKeuAsf++Wgszb8rnpDu=KPdKQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/1b4db143-3410-54c2-bb91-1242ae430bcd%40cmatte.me>
Precedence: bulk

> This should definitely be fixed.

Thanks!

>> By default, subscriber_access is set to False and there is no way to modify 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 database 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 are configured that way), so that anybody does not have access to archives.

> 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 web 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 pgarchives, as it already exists and pglister_sync can then push (and update) the configuration to pgarchives.


-- 
Célestin Matte