[16.0][ADD] website_event_private: new module

[Hugo-Trentesaux]

This is an update on PR #385 with a bugfix.

This module allows to select privacy on event and generate an access link for private events to be shared with foreseen attendees

This module is used in production in two instances.

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[Hugo-Trentesaux]

Not stale, just missing reviewer. And it could help some tests.

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[Hugo-Trentesaux]

Not stale, just missing reviewer.

[github-actions]

There hasn't been any activity on this pull request in the past 4 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days.
If you want this PR to never become stale, please ask a PSC member to apply the "no stale" label.

[odrakirmusic]

Ciao @Hugo-Trentesaux and @remi-filament, thanks for this module.

I felt the same need and built a website_event_private for 19.0, and only
noticed your PR afterwards. I do not want to just push my module into the
19.0 branch on my own, since you are the original authors of this one, so I
would rather ask how you would like me to proceed.

Here is a "short" comparison so you can decide:

Your design is link-based: an access_token (UUID) shared as a URL, a public
/ private_displayed / private_hidden trichotomy, and the privacy can be
defaulted from the event.type. Mine is password-based: a human-memorable
shared password entered on a gate page, plus a non-secret "codename" so
people can tell private events apart.

Where mine goes further is leak-hardening. It tries to close every
Odoo-core path by which a private event's name or details could escape:

• full redaction of the listing card (no name, date, place or image),
  where yours keeps the card visible with a "Private" badge in
  private_displayed;
• website search: matchable only by codename, with the date/country facet
  counts and the search autocomplete redacted too;
• the canonical-URL 301 (/event/42 to /event/-42) guarded at the
  routing layer so the slug cannot leak the name;
• the iCal /ics download gated, and private events dropped from
  sitemap.xml;
• a constant-time password compare that is safe for non-ASCII passwords.

Conversely, your event.type-level default, the share-link UX, and the
explicit hidden-vs-displayed split are things mine does not have. They feel
complementary rather than one being strictly better.

I would be glad to bring this in whichever way works best for you. Two options come to my mind, and I am happy to
co-author in either way:

1. I build on your module: migrate this PR to 19.0 and add my hardening
   (redaction, search, URL, iCal and sitemap protection) on top by
   default.
2. We keep them separate: my version lands as a standalone module (for
   example website_event_private_password), and yours stays as the
   link-based website_event_private.

You can see my full code here:
https://github.com/odrakirmusic/event/tree/19.0-website_event_private/website_event_private

Whatever you and the maintainers prefer, I am happy to do the work.

[Hugo-Trentesaux]

Hi @odrakirmusic, thanks for your comment!

I think our two modules address different aspects of the "private" word. Ours is more like "not public" while yours is more like "secret". While our module mainly aims to restrict registration to a known user, yours achieve that plus secrecy about the event.

Because these are two different requirements and philosophy, I think it should stay as two separate modules. However, as there could be some cases where people would need both, we could try to make these two modules work together well. But this requires us to first migrate our not-yet-merged module to 19.0 where we currently do not need. In addition, making the two modules compatible would need a certain quantity of work.

So my suggestion for the moment is that we wait for more review on our website_event_private module and you submit a PR on 19.0 under the name website_event_secret or website_event_private_password according to your preference. Is that ok for you?

[pedrobaeza]

Yes, maybe _hidden sounds better, following the nomenclature in Youtube.