feat: 관리자 마케팅 알림 발송 기능 추가

[hyoj-dev]

변경 사항

• 관리자 마케팅 푸시 발송 API를 추가했습니다.
  • POST /api/v1/admin/notice-pushes
  • ALL, SELECTED_USERS 대상 유형 지원
  • SUPER_ADMIN 권한 적용
• 기존 FCM 발송 구조를 재사용해 사용자별 푸시를 발송합니다.
• 푸시 성공 처리 후 ADMIN_MARKETING 유형의 앱 내 알림 히스토리를 저장합니다.
• 사용자별 발송 실패가 전체 발송을 중단하지 않도록 처리하고 감사 로그에 대상·성공·실패 건수를 기록합니다.
• 관리자 공지 이메일의 전체/선택 발송 대상을 마케팅 수신 동의 사용자로 제한했습니다.
• 관리자 푸시 REST Docs를 추가했습니다.

변경 이유

관리자가 마케팅 목적의 푸시 알림을 발송할 수 있는 기능이 없었고, 기존 관리자 전체 이메일은 마케팅 수신 동의 여부를 확인하지 않고 있었습니다. 마케팅 수신 동의 정책을 이메일과 푸시 발송 대상 조회에 일관되게 적용하기 위해 변경했습니다.

영향

• 마케팅 미동의자, 탈퇴자, 동의 정보가 없는 사용자는 관리자 마케팅 이메일과 푸시 대상에서 제외됩니다.
• 이메일은 이메일 주소가 있는 사용자만, 푸시는 이메일 여부와 관계없이 마케팅 동의 사용자에게 발송됩니다.
• 푸시 요청의 link를 통해 클라이언트가 알림 클릭 시 관련 화면으로 이동할 수 있습니다.

검증

• 전체 테스트 통과
• pre-push 테스트 통과
• spotlessCheck 통과
• asciidoctorAdmin 문서 빌드 통과
• git diff --check 통과

참고

현재 감사 로그의 sentCount는 실제 기기 도달 수가 아니라 서버에서 발송 처리가 예외 없이 완료된 사용자 수입니다.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 8d73c35a45

ℹ️ 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".

[chatgpt-codex-connector]

Honor night-push consent for nighttime campaigns

When this endpoint is invoked during the application's night period (21:00–08:00), both target queries select users solely by marketing consent, so users with nightPushConsent = false still receive the campaign. The existing reminder query in NotificationSettingRepository explicitly excludes such users at night; apply the same consent check here or prevent administrators from initiating campaigns during that period.

Useful? React with 👍 / 👎.

[chatgpt-codex-connector]

Reject payloads that cannot be stored in history

Limit title, body, and link to the 255-character capacity of the corresponding notification_histories columns (or enlarge those columns). With, for example, a 256-character body that FCM accepts, the push is sent first and history persistence then fails; runCatching suppresses that failure, the endpoint returns 204, and the audit reports the delivered push as failed, which can prompt an administrator to retry and send duplicates.

Useful? React with 👍 / 👎.