Skip to content

HOLD: Add communications/notifications section to person edit#1864

Draft
maebeale wants to merge 1 commit into
mainfrom
maebeale/person-edit-notifications
Draft

HOLD: Add communications/notifications section to person edit#1864
maebeale wants to merge 1 commit into
mainfrom
maebeale/person-edit-notifications

Conversation

@maebeale

Copy link
Copy Markdown
Collaborator

What is the goal of this PR and why is this important?

  • Admins managing event registrations already get a communications log on the registration edit page; the same context is valuable when working a person record directly.
  • This mirrors that section on the person edit page so admins can see and log communications without bouncing through a registration.

How did you approach the change?

  • Added a notifications polymorphic association (as: :noticeable) and nested attributes to Person, matching EventRegistration.
  • Added Person to Notification::NOTICEABLE_TYPES so person-logged communications appear in the notifications index "Record" filter and links resolve.
  • Permitted notifications_attributes in PeopleController#person_params and set recipient_email on new manual logs in #update (mirrors the registration controller).
  • New app/views/people/_notifications.html.erb partial mirroring event_registrations/_notifications — read-only paginated history (matched by preferred_email, newest first) plus inline "Add notification" logging.
  • Rendered the section in the person form above comments, gated by NotificationPolicy#index? (admin-only — owners editing their own profile don't see it).
  • Generalized the shared notifications/_notification_fields partial's event_registration: local to a neutral record: local; updated both the registration and person callers.

Anything else to add?

  • Marked HOLD pending review — confirm the desired styling/placement and admin-only gating before merging.
  • Rebased onto current main (resolved conflicts in Notification::NOTICEABLE_TYPES and comments_attributes).
  • Tests: new spec/requests/people_notifications_spec.rb (creates a manual log from nested attributes, ignores blank entries, lists past communications on the edit page). Verified no regressions across people_notifications, event_registrations, and the event_registration_edit system spec (98 examples, 0 failures). Lint clean.
  • No browser screenshot captured here; the shared-partial system spec passes, but a visual spot-check of the person edit page is worth doing before un-holding.

🤖 Generated with Claude Code

Admins managing event registrations already had a communications log on
the registration edit page; the same context is useful when working a
person record directly, so mirror that section on person edit.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
<% sender_options = sender_users.sort_by { |u| u.full_name.to_s.downcase }.map { |u| [ u.full_name, u.id ] } %>
<% channel_default = Notification::MANUAL_CHANNELS.include?(f.object.channel) ? f.object.channel : "email" %>
<% record = local_assigns[:event_registration] %>
<% record = local_assigns[:record] %>

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

🤖 From Claude: Renamed the event_registration: local to a neutral record: so this partial can be shared by both the registration and person notification sections. Both callers updated.

@person.comments.select { |c| c.persisted? && c.body_changed? }.each { |c| c.updated_by = current_user }

# Inline-logged notifications are addressed to the person.
recipient_email = @person.preferred_email.presence || "n/a"

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

🤖 From Claude: Falls back to "n/a" when the person has no email, mirroring the registration controller — recipient_email is presence-validated on Notification, so a manual log against an email-less person still saves.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant