fossasia/eventyay-teamshifts

Summary When creating repeating shifts, organizers can only use a shift length that divides exactly into the time between start and end. For example, 09:00–18:00 (540 minutes) with a 120-minute shift length is rejected with "The shift length must divide evenly into the total duration between start and end time." Expected behavior Organizers can enter any shift length. The system creates full-length shifts from the start time, and if time is left over, it adds one final shorter shift that ends exactly at the end time. Example: 09:00–18:00 with 120-minute shifts creates 09:00–11:00, 11:00–13:00, 13:00–15:00, 15:00–17:00 and 17:00–18:00 (60 minutes). "Preview occurrences" shows the same list before saving, with the shorter final shift clearly marked (e.g. "60 min, shorter than the others"), so the organizer can adjust the times if they don't want it. Acceptance criteria 09:00–18:00 with a 120-minute shift length is accepted and creates 5 shifts, the last one 17:00–18:

Description A placeholder numwidget showing "-" with the label "TeamShifts" appears in the stats row on both the common event dashboard and the tickets dashboard. It doesn't need to belong there — TeamShifts already has a proper component box (title + description + link) and a sidebar nav entry. Current behavior The stats row (which shows attendees ordered, attendees paid, revenue, quota, etc.) contains a "TeamShifts -" tile. It always shows - because there's no real stat being surfaced. Expected behavior No TeamShifts entry in the stats row. The component box and sidebar entry are unaffected. Cause teamshifts/signals.py registers a receiver on event_dashboard_widgets (teamshifts_dashboard_widget) that injects a numwidget with a hardcoded - value. This signal slot is meant for ticket-style stats. The plugin already registers the correct surface via event_dashboard_components (teamshifts_dashboard_component), so the event_dashboard_widgets receiver is redundant and wrong. Acceptance

Currently, when creating vouchers for volunteers in TeamShifts, users are redirected to the general voucher creation area. However, in Exhibitors & Sponsors, clicking Create Vouchers Pool directly opens Create Multiple Vouchers. TeamShifts should follow the same flow to keep the voucher creation experience consistent across Eventyay and reduce the number of steps for users. Steps to reproduce TeamShifts → Ticket Vouchers → Create a Voucher Batch in Tickets → redirects to the general voucher creation area. Exhibitors & Sponsors → Settings → Vouchers → Create Vouchers Pool → redirects directly to Create Multiple Vouchers. 20260914-1425-26.1190864.mp4 Expected behavior Clicking Create a Voucher Batch in Tickets in TeamShifts should directly redirect users to Create Multiple Vouchers, similar to the Exhibitors & Sponsors flow.

Description The phone number field on the public volunteer application form accepts any arbitrary string with no length or format constraints. A volunteer can submit a phone number that is 1 character long or 50+ characters long and the form will accept it without complaint. Cause The phone field is built programmatically inside TeamMemberApplicationForm.__init__ and is never assigned a max_length, min_length, or validator. Django's CharField defaults to unlimited length when no constraint is supplied, so the form layer passes any input straight through to the database and the stored application record. Current Behavior Submitting "1" (1 digit) succeeds. Submitting "12345678901234567890" (20+ digits) succeeds. Submitting non-numeric strings like "abc" or "hello world" succeeds. The stored phone number in the application record can be arbitrarily long or malformed, making it useless for actual contact. Expected Behavior Phone numbers shorter than 7 digits should be rejected with a c

Description: The certificate feature was originally designed so that the "Certificate of Appreciation" heading and the member name on generated certificates automatically use the event's primary color (set in Common Event Settings). This gives each event's certificate a consistent branded look without organizers needing to manually update the layout editor. This behavior was removed as a side effect of PR #146, which attempted to fix a separate bug (custom editor colors not persisting in preview/download). Root cause PR #146 (fix: apply selected text color in certificate preview and download, merged in commit a1e28d1) deleted the event-color injection mechanism from teamshifts/pdf.py and teamshifts/services/certificates.py entirely. Specifically it removed: hex_to_rgba() utility function _event_color key from preview_context() and application_context() The block in CertificateRenderer.draw_page() that read _event_color from context and applied it to certificate_title and member_name l