On 3/3/25 14:27, Andy Matthews wrote:
We're using Mailman 3.3.9.Entity<Form> data = Entity.entity(form, MediaType.APPLICATION_FORM_URLENCODED_TYPE); response = getTarget().path("lists/" + listId + "/config").request().method("PATCH", data);
You are patching the list's config and with that patch you are replacing the old value of `accept_these_nonmembers` with the new, not appending the new value. You would need to retrieve the existing value, update it and PATCH that.
However, as you know, that setting is deprecated and exists only to support the regexp and @list type of entries. For explicit email addresses, the intent is to create a nonmember and set the nonmember's moderation_action to `defer` - you normally don't want `accept` because that bypasses all the subsequent checks such as administrivia, implicit-dest, max_recipients, max_size, , no_subject, etc.
The result of these two API calls is that both the subscribers and nonmembers properties of the mailing list are updated to include the new email (let's call it a...@123.com). The user can immediately send another email which is not held for moderation. The issue comes when a different nonmember sends an email and is approved (let's call it x...@789.com). For some reason this blows out the "always accept" status of user a...@123.com and requires their email to be approved again. After some research I believe this is because the `accept_these_nonmembers` property has been deprecated (which seems valid because that property remains an empty array). Additional reading seems to indicate that we can now set `moderation_action` on each individual user which supercedes the mailing list's `default_nonmember_action` property (in our case it is `Action.hold`).
That is correct, and that is the intended way to deal with nonmember moderation.
The docs indicate that I should be able to submit a patch request to update the moderation action for any user: https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/membership.html#moderating-a-member But it requires the user ID. And when trying to get the user_id for a nonmember it appears that it is not returned by the API. The following call: `/3.0/addresses/a...@123.com` returns ``` { "email": "a...@123.com", "original_email": "a...@123.com", "registered_on": "2025-03-03T19:18:35.169703", "self_link": "https://0.0.0.0:8001/3.0/addresses/a...@123.com";, "http_etag": "\"92c44d0b3b323450f3576e6352acb59b4cc5d6f0a\"" } ``` So I'm not sure how I would be able to update this particular record without a member or user id. So, all that said, I'm looking for information on how to do one of the following. 1. When submitting a user's email to the `accept_these_nonmembers`, is there a way to indicate that the `member.moderation_action` should be a specific value?
No. You can put the email in the appropriate *_these_nonmembers, but that does only that. It doesn't affect the nonmember's moderation_action, nor does it create a nonmember if there isn't one already, but if there is a nonmember with non-None moderation_action, that action takes precedence over *_these_nonmembers.
2. Retrieve a nonmember record and have it include a member or user id that I can use to explicitly update the `member.moderation_action` value?
You must be able to set a nonmember's moderation_action via REST. (The docs may need updating.) Postorius does it, so it can be done, but I don't offhand know the endpoint and I'm leaving the country for vacation tomorrow and don't have time to research it.
-- Mark Sapiro <m...@msapiro.net> The highway is for gamblers, San Francisco Bay Area, California better use your sense - B. Dylan _______________________________________________ Mailman-users mailing list -- mailman-users@mailman3.org To unsubscribe send an email to mailman-users-le...@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/PAEWWL7F6VDD2LBNBJDXRWKBK56AO3SN/ This message sent to arch...@mail-archive.com
