Skip to content

Add admin-editable registration info to barrio signup page#216

Merged
peterdrier merged 4 commits intomainfrom
sprint/2026-04-10/batch-6
Apr 13, 2026
Merged

Add admin-editable registration info to barrio signup page#216
peterdrier merged 4 commits intomainfrom
sprint/2026-04-10/batch-6

Conversation

@peterdrier
Copy link
Copy Markdown
Owner

Summary

  • Add RegistrationInfo markdown field to CityPlanningSettings with EF migration
  • Add textarea on Barrio Admin page (/Barrios/Admin) to edit the registration info content
  • Render the markdown content as an info card at the top of /Barrios/Register when non-empty

Issues

Test plan

  • Navigate to /Barrios/Admin and verify the "Registration Info" textarea is visible
  • Enter markdown content (paragraphs, lists, links, bold, italic) and save
  • Navigate to /Barrios/Register and verify the info card appears above the form with rendered markdown
  • Clear the registration info field and save; verify no info card appears on the register page
  • Verify only CampAdmin/Admin roles can access the edit functionality

🤖 Generated with Claude Code

peterdrier and others added 2 commits April 10, 2026 16:34
…ns, and resources

Closes nobodies-collective#464

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Add a RegistrationInfo markdown field to CityPlanningSettings that
admins can edit from the Barrio Admin page. When non-empty, the
content renders as an info card at the top of /Barrios/Register,
above the registration form. Uses the shared SanitizedMarkdown
helper for safe rendering.

Closes nobodies-collective#464

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Copy link
Copy Markdown

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 12a2ce5d16

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

Comment on lines +103 to +104
var cityPlanningSettings = await _cityPlanningService.GetSettingsAsync();
ViewData["RegistrationInfo"] = cityPlanningSettings.RegistrationInfo;
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 Badge Load registration info for the active registration year

This reads registration info from CityPlanningService.GetSettingsAsync(), which is keyed to CampSettings.PublicYear, but camp registration itself targets the highest open season year (OpenSeasons.OrderByDescending(...).FirstOrDefault()). Because opening a season and changing PublicYear are separate admin actions, a common transition state (next season open while public year is still old) will show/edit the wrong year's registration info on /Barrios/Register, leading to stale or missing instructions for registrants.

Useful? React with 👍 / 👎.

Copy link
Copy Markdown
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in dc93323. Added ICityPlanningService.GetRegistrationInfoAsync and a private GetOrCreateRegistrationSettingsAsync helper that keys the row to max(OpenSeasons) ?? PublicYear — the same year CampController.PopulateRegisterSeasonYearAsync uses for the registration form. Both the read path (CampController/CampAdminController) and the write path (UpdateRegistrationInfoAsync) now use this helper, so during the next-season-open / old-PublicYear transition window admins edit and registrants see the same row.

Resolves the CampAdminController conflict from PR #219 (service ownership
phase 2): drop the direct HumansDbContext dependency in favor of
ICityPlanningService, keeping the new registration-info editor wired
through the service layer.

Codex P2: registration info was keyed to CityPlanningSettings.PublicYear
but /Barrios/Register targets the highest open season year, so during
season transitions admins would edit/view the wrong year's row. Add
GetRegistrationInfoAsync and key both read and write to max(OpenSeasons)
(falling back to PublicYear) so the info shown matches the year the
register page targets.

Renumber the migration to 20260413131100 so it sorts after two newer
migrations that landed on main during the merge, and refresh its designer
snapshot to reflect the full merged model.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@github-actions github-actions bot added the db PR includes EF Core migration label Apr 13, 2026
The accordion ("What Your Barrio Gets", "Your Obligations", "Useful
Resources") was fabricated content — benefits, obligations, and resource
details were invented without any source. The real design is that this
information is admin-editable markdown set via /Barrios/Admin and rendered
through the RegistrationInfo ViewData card at the top of the page.

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
@peterdrier peterdrier merged commit 91b890b into main Apr 13, 2026
3 checks passed
@peterdrier peterdrier deleted the sprint/2026-04-10/batch-6 branch April 13, 2026 16:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

db PR includes EF Core migration

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Explain Barrio requirements when signing up

1 participant