> 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
modifythat 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
listsbeing 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
nothave 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
canthen push (and update) the configuration to pgarchives.
--
Célestin Matte