Repository navigation
Add entry requirements and overrides to attendee logs - #66
Conversation
Attendee logs can now restrict who gets logged as an attendee. An attendee is allowed in if they meet any of the requirements that are set: - a ConCat registration level, matched by product name or ID - a Tracker role of Staff or above - a minimum number of earned volunteer hours for the log's event Admins configure the requirements on the log page. The registration levels to choose from are built from ConCat registrations and cached for six hours, with a button to reload them. Requirements based on Tracker data are checked first so ConCat is only contacted when necessary.
A denied attendee can be let in anyway with an override, which records the user that approved it and an optional reason. Managers and admins can always override denials, and each log can also allow its gatekeepers to. Overrides are shown under the attendee's name in the log and included in the attendee log export. The export escapes text that a spreadsheet would treat as a formula. The override reason field is never focused automatically and ignores Enter, and reasons containing long numbers are rejected, so a badge scanned at the wrong moment can't submit an override.
Banned users are now denied on every attendee log, including logs without entry requirements. The denial lists the ban alongside any requirement the user also fails, and only managers and admins can override it, even on logs that let gatekeepers override other denials. Denial messages now show an attendee's exact volunteer hours only to users that can override the denial. Everyone else sees the required number of hours instead.
Describe entry requirements, overrides, and how banned users are handled in the architecture wiki, and list both features in the README.
travismolick
added
documentation
Tracker's banned role is a volunteer ban, and a user banned from volunteering can still be a registered attendee, so attendee logs no longer check it. Banned users are logged the same way as on main. Denial messages still show exact volunteer hours only to users who can override them.
|
I've removed the banned-user check from this PR (910dc11). Tracker's Banned role is a volunteer ban, and someone banned from volunteering can still be a registered attendee (for example, a Super Sponsor at a Super Sponsor event). Denying them on every attendee log was wrong, so attendee logs no longer look at the Banned role, the same as on main. Volunteer bans and ConCat registration bans will be handled later as a separate feature. Everything else in the description still applies, except:
|
Gawdl3y
left a comment
Gawdl3y
left a comment
There was a problem hiding this comment.
This is pretty good! Some improvements to make later, but nothing deal-breaking. Given we want to use this ASAP, I'm approving & merging now.
Thanks for the tests, btw! I've been wanting to start that somewhere for a while now.
| public function refreshRegistrationLevels(Request $request): JsonResponse|RedirectResponse { | ||
| $this->authorize('create', AttendeeLog::class); | ||
|
|
||
| Cache::forget(static::REGISTRATION_LEVELS_CACHE_KEY); |
There was a problem hiding this comment.
Forgetting first means that if the refresh fails for any reason, we don't have the old data around anymore to keep using. It'd probably be better to refresh & just overwrite without forgetting first.
| ? response()->json(['error' => "{$typeName} {$user->audit_name} is already present in the log."], 422) | ||
| : redirect()->back()->withErrors(['badge_id' => "{$typeName} {$user->audit_name} is already present in the log."]); | ||
| } | ||
| $overrideReason = $overriddenBy ? (trim($request->validated('override_reason') ?? '') ?: null) : null; |
There was a problem hiding this comment.
Input is already trimmed by the TrimStrings middleware which is part of the default Laravel middleware stack.
| static::escapeFormula($user->display_name), | ||
| $excelDates ? Date::dateTimeToExcel($arrival) : $arrival, | ||
| static::escapeFormula($this->getOverriderName($user->pivot->overridden_by_id)), | ||
| static::escapeFormula($user->pivot->override_reason), |
There was a problem hiding this comment.
Does PhpSpreadsheet not take care of escaping already?
This escaping is going to apply to the rendered HTML form of the report too (which is never linked anywhere, but technically exists). There may be other places this would be useful as well, but we should probably pursue separating report data into two forms (raw for the web page, escaped for exports). Definitely not a task for this!
|
|
||
| <AttendeeCreatePanel v-if="isManager" :attendee-log :read-only gatekeeper class="grow basis-1" /> | ||
|
|
||
| <AttendeeLogRequirementsPanel v-if="isAdmin" :attendee-log :registration-levels class="grow basis-1" /> |
There was a problem hiding this comment.
When some requirements are turned on and the panel gets taller as a result, it ends up making the actual attendees/gatekeepers panels almost unusably short. This shouldn't be a huge issue for now since gatekeepers usually won't be seeing this panel.
3 participants
Summary
Attendee logs can now restrict who gets logged as an attendee. Admins set optional requirements per log, and an attendee is allowed in if they meet any of them:
Requirements based on Tracker data are checked first, so ConCat is only contacted when a registration level must be checked or the badge doesn't belong to a known user yet.
Overrides
A denied attendee can be let in anyway with Allow Anyway, which records who approved it and an optional reason. Managers and admins can always override; each log can also allow its gatekeepers to. Overrides are shown under the attendee's name and included in the attendee log export.
Denial messages show an attendee's exact volunteer hours only to users who can override the denial; everyone else sees the required number of hours.
The reason field is never focused automatically, it and the Allow Anyway button ignore Enter, and reasons containing long numbers are rejected, so a badge scanned at the wrong moment can't submit an override.
Banned usersBanned users are denied on every attendee log, including logs without requirements. The denial lists the ban alongside any requirement they also fail. Only managers and admins can override a ban, even on logs that let gatekeepers override other denials.(See link)
Other changes
Database
Two migrations, both nullable or defaulted, so existing logs keep working unchanged apart from the ban rule:
attendee_logs:allowed_registration_levels(json),allow_staff(bool),min_volunteer_hours(decimal 5,2),gatekeepers_can_override(bool)attendee_log_user:overridden_by_id(nullable FK to users, null on delete),override_reason(string 255)Behavior changeBanned users can no longer be logged into attendee logs without requirements unless a manager or admin overrides it.(See link)
Testing
tests/Feature/AttendeeLogEntryRequirementsTest.php, covering each requirement, overrides and permissions, bans, ConCat failures, validation, and the export (xlsx and CSV).