Closed Bug 682577 Opened 13 years ago Closed 10 years ago

generic_nonmember_action on support-other, support-calendar, and support-firefox keeps getting set to Hold

Categories

(mozilla.org :: Discussion Forums, task)

task
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cilias, Assigned: rbryce)

References

()

Details

https://lists.mozilla.org/admin/support-other/?VARHELP=privacy/sender/generic_nonmember_action is supposed to be set to Accept, but after I set it to Accept, it gets reset to Hold the next day.
justdave: is there some script doing this? Gerv
Blocks: 663318
justdave: ping? Gerv
rbryce: are you able to look at this as part of your current work? I suspect there is some script which runs to check the configs of the lists regularly, and it's doing this. Gerv
This has now started happening on support-calendar as well, which was recently switched to moderated as well. (see bug 735787) So it appears this is specific to the way moderated lists are set up.
Summary: generic_nonmember_action on support-other keeps getting set to Hold → generic_nonmember_action on support-other and support-calendar keeps getting set to Hold
This bug is preventing me from moving forward implementing the new moderation system on the rest of the support newsgroups. Is there no-one that can investigate this?
Severity: normal → major
I'll poke this to see whats going on.
This shouldn't be assigned to me... Gerv
Assignee: gerv → rbryce
:cilias This works for me. Mailman migration fixed this I believe.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
At 4am this morning, it got switched back to "Hold". In case it matters, if you checked and saw it set to "Accept", that's because I change it back to accept *every morning*.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Is there anything else I can do to help move this along?
mburns may be able to help here... Gerv
I still reset this every morning, which is very annoying and sometimes causes support-calendar messages to be held. Is there anyone else we can ask to look into what's causing this bug?
Chris - This is a mystery to me. I did some research this afternoon, and it seems this problem has been seen before in different forms. All the troubleshooting I have come across points to problems with regex, which you are not using. Here is what I have done today on the Support-other mailinglist. I dumped the configuration from mailman, and added regex checks for mozilla domains. I then manually applied the new configuration file via mailman's cli tools. My hope is writing a new file will help. Also, my hunch is not having regex matches might be causing this. Note- The regex matches are just for testing, I'm auto accepting all @mozilla.com address and auto-rejecting any @aliizom.org address. Anything else, should be auto accepted.
rbryce: I heard a rumour from justdave that there was a script which ran daily which checked and "corrected" the config of all the lists. Perhaps this is overriding manual settings? Gerv
(In reply to Gervase Markham [:gerv] from comment #14) > rbryce: I heard a rumour from justdave that there was a script which ran > daily which checked and "corrected" the config of all the lists. Perhaps > this is overriding manual settings? > > Gerv I looked around for such a script, and did find anything. I will ping justdave today and confirm with him
I can add that this is happening on the community-uk mailing list, I set "generic_nonmember_action" to Reject, and it resets to Hold the next day. This definitely isn't a mailman issue, as it doesn't happen on a lug.org.uk mailing list where I use the same moderation setup.
rbryce: can you take up the torch again here? Gerv
Summary: generic_nonmember_action on support-other and support-calendar keeps getting set to Hold → generic_nonmember_action on support-other, support-calendar, and support-firefox keeps getting set to Hold
In bug 1132118 comment 1, Gerv said "There is a script which "standardizes" the list settings each day." Could that be the cause of this bug too?
Quite possibly. Gerv
Did someone disable it in the past 24 hours? This is the first day in 4 years, the setting hasn't reset.
Per bug 1134695 comment 8, Ed disabled a cron, and that seems to have fixed this bug.
Status: REOPENED → RESOLVED
Closed: 13 years ago10 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.