[19.0][ADD] website_event_hidden_by_password#515
Conversation
Hide a website event behind a per-event access password. A hidden event is fully redacted on the events listing (no name, date, place or image; only a lock, "Private" and an optional public codename), shows an info-free password wall, and is kept out of the website search (name, facet counts and autocomplete), the canonical-URL redirect, the iCal export and sitemap.xml, so its name and details never leak. Managers bypass the wall. Split out from the discussion on PR OCA#445 as a standalone, password-based counterpart to website_event_private.
OCA-git-bot
added
series:19.0
mod:website_event_hidden_by_password
|
The test workflows haven't run on this PR yet and they are awaiting first-time-contributor approval. Could a maintainer approve the CI runs? Runboat is already green. |
|
Hi @pedrobaeza, this is the module we discussed on #445, renamed to website_event_hidden_by_password as per your suggestion. The tests and pre-commit workflows are still queued in action_required (first-time contributor), so the PR can't go green on its own. Could you approve the runs? Runboat is green. Same for #506 (website_event_custom_registration), waiting since 25 June. |
|
Workflows started. You can sign the CLA for not requiring this manual triggering: |
|
@pedrobaeza Thank you! Strange, I've signed the CLA already a month ago. I thought it would recognize my GH account automatically. |
3 participants
Hide a website event behind a per-event access password. A hidden event is fully redacted on the events listing (no name, date, place or image; only a lock, "Private" and an optional public codename), shows an info-free password wall, and is kept out of the website search (name, facet counts and autocomplete), the canonical-URL redirect, the iCal export and sitemap.xml, so its name and details never leak. Managers bypass the wall.
Split out from the discussion on PR #445 as a standalone, password-based counterpart to website_event_private.