@timconsidine thank you for the link, that is the piece I was missing. I had been guessing at packages/releasebell and cloudron/releasebell; the group is apps, which I never tried.
It does not get me all the way there, though. Signed in as LoudLemur the path 404s, and GitLab answers 404 rather than 403 for a private project you are not a member of, so I read that as the repository being there and my account not being on it. The apps group is public but lists no public projects, and packages lists exactly one, so I assume that is simply how app repos are kept rather than anything to do with me.
@girish that narrows what I asked for in my last post. I no longer need the path, only access to apps/releasebell for LoudLemur, or a fork pushed somewhere I can reach. Everything else on my side is unchanged: once I can read the real tree I will rebase onto current master, re-run my checks against that base instead of the archived 1.12.0 mirror, and open the MR.
Incidentally the footer of the notification email points at git.cloudron.io/cloudron/releasebell, which is one of the paths that comes back not-found. Small thing, but the in-app link looks stale relative to apps/. Happy to fix it in the same MR.
On the email rule: you are right that it works, and more cleanly than I would have guessed before looking. The subject is built as <project> <version> (prerelease) released, and that (prerelease) comes straight from the release API flag rather than from pattern-matching the tag, so a filter on that literal string catches exactly the prerelease mails and nothing else. No false hits on a project that happens to ship a version called beta.
So it is a good workaround and worth having posted for anyone who needs one today. Three things it cannot do, which is why I still think the setting earns its place.
It is all-or-nothing. The reason I ended up adding a per-project override on top of the per-user flag is that the useful setting is not "no prereleases" but "prereleases for the four projects I actually test against, and not for the other forty". Expressing that as mail rules means one rule per project, edited by hand every time you follow something new.
It deletes rather than defers. Because a suppressed release stays notified=FALSE in the database, turning the setting back on delivers the prereleases you missed while it was off. That is deliberate, and it is what makes the setting safe to flip. A filtered email is gone.
And it depends on a presentation detail. The subject string is template text, not API surface. If someone rewords it, the rule quietly stops matching and you start receiving prereleases again, or a reworded rule quietly starts eating real releases. Filters that fail in the delete direction fail silently.
None of which is an argument against your rule in the meantime.
