Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nE9CL-0002La-8D for pgsql-www@arkaria.postgresql.org; Sun, 30 Jan 2022 12:20:49 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nE9CJ-0007gZ-8W for pgsql-www@arkaria.postgresql.org; Sun, 30 Jan 2022 12:20:47 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nE9CI-0007gQ-VN for pgsql-www@lists.postgresql.org; Sun, 30 Jan 2022 12:20:47 +0000 Received: from mail-lf1-x129.google.com ([2a00:1450:4864:20::129]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nE9CG-00027r-K7 for pgsql-www@lists.postgresql.org; Sun, 30 Jan 2022 12:20:45 +0000 Received: by mail-lf1-x129.google.com with SMTP id u6so21158071lfm.10 for ; Sun, 30 Jan 2022 04:20:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hagander-net.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=FzY34GfOYhW4BUJmmqBURFQndoyAf3pio+vKt8VMyKo=; b=RMwRtwo+1jK2AcUWZAPgCmRmLhrcLWuTb8M9v3F4FJjLb1M8VB5TGob5ctj/Wx043w 0pFMPWTYbkglGv7cRWOJwyevSZH1fmGQlf5fP5Pf3edOFt7LEMvvQMG2IjnPCHHRxSv7 0VwtKRN2XcBnl+ea+Pe8tzHo+UDtfX19jImMsBlYjyEm84w0MkHXPyDit0eWsMcQ3wVK FDSsamk4Gwy+cx9cGTm7NROYJW8dzRn/LhsIYMN4CO0q7/9IZhTHaPH5hCiDB20AOGGs fTsHb20qF6FzvJ07IVnfZ8Kxnm4Y98vZv8zeSTyMlZ7ijfe3ovNEejqyeO9fSzTFDinr ngxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=FzY34GfOYhW4BUJmmqBURFQndoyAf3pio+vKt8VMyKo=; b=eUbR9CjIlolNJoVP1pyL4exvRwWNWbpNwvXxT8iUKNBeYmzg9SLNHrt69o/+cBA8eN 0i85jVZ+zoAjvKgWrim1rPicw6SzYuP0qQyyLOyVxW87V4/0ymrAvpPLI66Ax+x3LZyq Mgh9BWJOEJAbAk8CE8/gfQ3orrqQ5gQ5VtKMz4fip5H19QrMJq7ZJCmdbwOOLneG/Ddi TaNZ4NeKStRlAFCeN0YMiSP8utDHZoL1BzvpmO3DfyK+vHnSDtHnQt8bo5IswEFrzJMD qbANy3R/oukv8ScEIxrkFmiANaeeX2jBucIl+nTO15eiwxJ6lRrWNRChoMWqhg0ehHjK 41Hw== X-Gm-Message-State: AOAM531FNBEBxFo8yPDvYZlZdKLJk899cfSEJirY5KmIbtk4oHujwhHr L1Z3RZpUcte+xSAo3wGOFG0ZXewz+kvHRxG/DqK9E5w+BbE= X-Google-Smtp-Source: ABdhPJwe8gfEShXAZolsQRQxuvXndDbPgxpWhywam5lTrfWRQp6g6Jcamu/QqceTNruEI5AHRGU73oF5/V9F2zA5Kp4= X-Received: by 2002:a05:6512:96a:: with SMTP id v10mr11649332lft.497.1643545242228; Sun, 30 Jan 2022 04:20:42 -0800 (PST) MIME-Version: 1.0 References: <1d060463-e562-7783-decd-b5a7f3c4c06c@cmatte.me> In-Reply-To: <1d060463-e562-7783-decd-b5a7f3c4c06c@cmatte.me> From: Magnus Hagander Date: Sun, 30 Jan 2022 13:20:30 +0100 Message-ID: Subject: Re: [PATCH] pgarchives: pglister_sync: import lists with subscriber_access set to True To: =?UTF-8?Q?C=C3=A9lestin_Matte?= Cc: PostgreSQL WWW Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Fri, Jan 28, 2022 at 6:37 PM C=C3=A9lestin Matte wrote: > > pglister_sync.py is a script used to synchronize things between pglister = and pgarchives: lists, subscribers etc. > > subscriber_access is not set in pglister_sync's query, and is set to null= =3DFalse in Django's model. As a consequence, pglister_sync fails to add ne= w lists: > Traceback (most recent call last): > File "/srv/pgarchives/local/loader/pglister_sync.py", line 68, in > 'groupname': l['group']['groupname'], > psycopg2.errors.NotNullViolation: null value in column "subscriber_access= " violates not-null constraint > DETAIL: Failing row contains (8, test-pglister-sync, test-pglister-sync,= , t, 1, null). > > I don't know if there is a way to configure postgres to use the default v= alue , but I think it would be wiser to explicitly set this variable in pgl= ister_sync.py. Interesting. Yes there is, set the columns default to false. Which is what is running on both our production servers for postgresql.org -- but I'm unsure how it actually got there given that Django is dumb enough not to propagate that down to the database, assuming all access will forever be through the ORM. We must've done some manual step when deploying that, that has since been forgotten. This should definitely be fixed. > By default, subscriber_access is set to False and there is no way to modi= fy that within the web interface. > As a consequence, access to lists on private servers is restricted to sup= erusers, and there is no easier way to modify that than to edit the databas= e 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. 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 said, it may be better to have a way to modify that within the web i= nterface 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. --=20 Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/