Reported: clicking "Post a Listing" on /classifieds while logged out threw
a raw 500 instead of prompting login.
Root cause is upstream, in this Odoo 19 build's own http.py: when
auth='user' raises SessionExpiredException for an anonymous visitor,
Request._serve_db's `finally: self.env = None` clears the request env
before the exception reaches the website error handler, which then tries
to build the login redirect via self.env['ir.http']._redirect(...) and
crashes with TypeError: 'NoneType' object is not subscriptable. This
isn't specific to any one route - it reproduces on every auth='user' +
website=True page hit anonymously, including stock Odoo's own /my (traced
this back to the true cause rather than continuing to treat it as an
unrelated environment quirk, since it now has a real reported symptom).
Since core can't be patched here, worked around it at the route level
across all 9 affected pages (classifieds new/my/renew, membership
my/renew/card, benefits my, school attendance, portal my/school, event
checkin): switched from auth='user' to auth='public' and added an
explicit `if request.env.user._is_public(): return request.redirect(...)`
check at the top of each handler, before Odoo's own auth layer ever gets
a chance to raise. The jsonrpc AJAX endpoints (attendance save, checkin
scan/dashboard) were left on auth='user' since they return a JSON error
rather than attempting an HTML redirect, so they don't hit this path.
Verified against a live Odoo 19 + Postgres 16 container: reproduced the
original crash pre-fix, then confirmed all 9 previously-broken routes now
303-redirect to /web/login?redirect=<path> when hit anonymously, that the
login page carries the redirect target, that logged-in access is
unaffected (200), and that the separate "logged in but lacking a required
group" case (event check-in without Registration Desk) still degrades
gracefully to a clean 403 rather than a crash. Full regression: 48/48
tests pass across the six touched modules.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds a QWeb PDF "Membership Card" report (85x54mm landscape, custom
report.paperformat) showing the company logo, member name/ID, tier, and
a QR code generated with the qrcode library (embedded as a base64 PNG via
a non-stored res.partner.membership_card_qr compute field). The QR encodes
a public verification URL built from ir.config_parameter's web.base.url.
Adds the public GET /membership/verify/<member_id> controller: shows
valid/expired/not-found with no personal data beyond name (and tier, for
valid members) - internal states like 'invoiced'/'none' are deliberately
reported as not-found so partial signup state isn't leaked.
Adds the member portal: /my/membership (status/tier/expiry), /my/membership/
renew (finds or creates a draft renewal invoice, redirects to the existing
portal invoice page), and /my/membership/card (PDF download) - plus a
"Membership" entry card on the main /my portal home page. Since
community_theme_base doesn't exist yet (that's Phase 6), the card uses
res.company.logo rather than a theme setting - still brand-neutral,
just resolved from the standard company record for now.
Verified against a live Odoo 19 + Postgres 16 container, both via the
test suite (12/12 tests: unit tests, HttpCase tests hitting the real verify
endpoint for valid/expired/unknown IDs) and by hand end-to-end - created a
tier and member over JSON-RPC, activated the membership, fetched the live
/membership/verify/ page, and rendered the actual PDF card via
/report/pdf/... (11.7KB single-page PDF, confirmed non-blank).
Along the way, hit a third real Odoo 19 API change: res.users.groups_id
was renamed to group_ids.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
