forked from CGM_Public/pretix_original
upstream/2026.7.0 #21
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: CGM_Public/pretix_cgo#21
Reference in New Issue
Block a user
* Add event placeholder support to more fields I found it useful to be able to use the `{event}` placeholder in some fields such as the "End of presale text" because I don't need to fix the texts creating a new event by cloning another event. I made placeholders available to the other fields as well (where not too difficult). Specifically `presale_has_ended_text`, `voucher_explanation_text` `banner_text`, `banner_text_bottom` and `event_info_text`. In addition, I grouped them under a new `texts` variable in the `context` (including `frontpage_text` which was part of the root `context` previously). * change compute location --------- Co-authored-by: Raphael Michel <michel@rami.io>* Improve subject lines for admin-facing emails A few of the current subjects are ambiguous about the expected action, and some omit context that would help in an inbox preview (which event, which address). The rewrites bring them closer to common conventions in modern transactional email (verb-led, recipient-addressed, with recipient-meaningful variables). Two themes: - Action-required emails lead with the action verb. "Reset your password", "Confirm event cancellation and bulk refund", and "Confirm <address> as a sender address" tell the recipient up front what's expected, where "Password recovery", "Bulk-refund confirmation" and "Sender address verification" did not. - Surface the relevant variable when the email is about something specific. "Data shredding completed for <event>" is more useful than the generic version when an admin manages several events. "You've been invited to join <organizer>" names the inviting organizer. "Confirm <address> as a sender address" names the address. The remaining rewrites are lighter rewordings. "New sign-in to your account" replaces "Login from new source detected" because "source" is jargon a non-technical recipient wouldn't recognise. "Changes to your account" replaces "Account information changed" because the possessive frames the email as being about the recipient's own account. Also fixes a hardcoded "pretix" in the confirmation-code subject. * Standardise admin email sign-offs as "Thanks, The <instance> Team" The current sign-offs ("Best regards, Your <instance> team") have a formal tone. A review of the last ~20 transactional emails in my inbox showed most senders use something friendlier: - Thanks: Deliveroo, Starling Bank, GitHub, Cloudflare - Thank you: AWS - Sincerely: Google Workspace A small minority (e.g., Sentry) had no sign-off at all. "Thanks" was the most common, and among that group "The <instance> Team" was the consistent phrasing rather than "Your <instance> team". Two templates (cancel_confirm, export_failed) didn't have a sign-off; they now get one for consistency. Notification emails are deliberately excluded: they're system alerts rather than direct correspondence. * Add anti-phishing notice to admin emails containing confirmation codes Three admin emails send the recipient a confirmation code to enter back into a form: confirmation_code, email_setup, and cancel_confirm. Only confirmation_code had an anti-phishing warning, and its wording was awkward ("Please do never give this code to another person. Our support team will never ask for this code."). This commit standardises the warning across all three: > Don't share this code with anyone. The <instance> team will > never ask you for it. * Add structured details to login-notice email The single-sentence body ("The login was performed using <agent> on <os> from <country>.") is replaced with a labelled bullet list: Time, Browser, Operating system, Device, Country. Time and Device are new fields. Device is omitted when ua-parser can't identify the device, Country when GeoIP isn't available, so the user only sees fields with real values. * Restructure notification.txt for clearer layout - Attributes: bullet list instead of paragraph-per-attribute. - Actions: label gets a colon, URL on its own paragraph (was 4-space-indented code block). - Footer: separated by --- and bulleted (manage / disable links). "Click here X" phrasing dropped (incidentally moots a missing-"to" typo). - Minor whitespace fix: detail-block endif now matches the placement of the rest of the template. notification.html's footer text is also updated, only to match the new .txt wording (link labels and intro line). No structural changes to the HTML template. * Improve confirmation-code email reason strings - Drop the redundant "to confirm" opener. - Replace hardcoded "your pretix account" in email_verify with "{instance}". * Polish admin email body copy A small wording and formatting pass on the admin email bodies, in three loosely-grouped themes: 1. Sentence case for body text (previously lowercase after "Hello,"), matching standard English convention. 2. Light restructuring where helpful: bullet lists for sets of labelled facts; 4-space-indented code blocks for codes the recipient is meant to type back. 3. Phrasing polish. Some sentences tightened or shortened. Largely matters of taste, but generally read smoother. --------- Co-authored-by: Raphael Michel <michel@pretix.eu>* Add trace IDs from request to celery task Celery tasks will log the request ID they were triggered from: [2026-07-02 10:33:17,614: INFO/MainProcess] Task pretix.base.services.orders.cancel_order[5f3104b3-0a54-4e49-921e-c866c4dc4c6d] received [2026-07-02 10:33:17,614: INFO/MainProcess] Task 5f3104b3-0a54-4e49-921e-c866c4dc4c6d has trace 4d389638-00ab-4c4d-bdec-d73ac322bf44 Nested celery tasks will then contain both the request ID as well as the previous tasks: [2026-07-02 10:33:18,354: INFO/MainProcess] Task pretix.base.services.notifications.notify[d52a3a49-9c89-4f67-bdde-9f773586fc07] received [2026-07-02 10:33:18,354: INFO/MainProcess] Task d52a3a49-9c89-4f67-bdde-9f773586fc07 has trace 4d389638-00ab-4c4d-bdec-d73ac322bf44 5f3104b3-0a54-4e49-921e-c866c4dc4c6d * Apply suggestion from @luelista Co-authored-by: luelista <weller@rami.io> --------- Co-authored-by: luelista <weller@rami.io>As a security precaution, we change the contract of some signals such that a SafeString needs to be returned if HTML should be rendered without further escaping. Before, the `{% signal ... %}` and `{% eventsignal ... %}` template tags called mark_safe themselves on all strings returned from signals. That could lead to unsafe coding practices, where untrusted values are interpolated into HTML format strings. However, such interpolations should usually be performed using helpers such Django's format_html, which automatically escapes inputs and returns a SafeString. Now, we call conditional_escape on signal results, so that any HTML not explicitly marked as safe gets escaped. Most plugins are not affected by this change as they return a SafeString as a result of Template.render already.