Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Feature] Add opt-in SMTP email delivery for new notifications

Open
  • Is something wrong?
#978 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@XiaoSeS is already working on this.

Since Oct 22, 2026.

  • #1004 by @XiaoSeS — open

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
java, spring, spring-boot
Domain
api, authentication, backend

Research direction

Start with NotificationChannel.java and NotificationService.java in server/skillhub-notification, then read docs/19-smtp-password-reset-email-setup.md for the existing SMTP setup. Trace how notification preferences and event handling are stored and exposed before estimating the work. Done means opt-in email delivery meets the listed transaction, retry, deduplication, recipient eligibility, preference, and documentation criteria while preserving in-app and password-reset behavior.

Written by the indexing model from the issue text.

Description

effort/l priority/p1 risk/high triage/core
Problem

Users who are away from the SkillHub web UI can miss new notifications, such as a pending review, a review decision, or an update to a subscribed skill. This can delay approvals and make subscriptions less useful for people who do not keep the site open.

In v0.2.23, notification delivery is limited to the in-app channel:

The default branch's channel enum also still lists only IN_APP at the time of this request.

Example: A namespace admin receives a new review request while the browser is closed. An email with a brief summary and a link to the review page would let them discover and act on the request promptly.

Proposed Solution

Add an optional EMAIL delivery channel for existing notification events, alongside in-app notifications.

Suggested initial scope:

  1. Operator enablement: Reuse the existing Spring Mail/SMTP transport configuration. Add a separate notification-email enable flag and sender settings with documented defaults; keep delivery disabled by default for existing installations.
  2. User preferences: Allow users to opt in or out of email independently for the existing PUBLISH, REVIEW, PROMOTION, and REPORT categories. Disabling in-app notifications should not implicitly disable an explicitly enabled email channel.
  3. Recipients and content: Use the recipient's eligible account email under the project's email trust policy. If none is available, skip email with a clear setting/status message. Include the event summary and a link built from the configured instance URL. Keep private details minimal and retain authorization checks when the link is opened.
  4. Delivery behavior: Send asynchronously after the triggering transaction commits. SMTP failure must not roll back publishing/review actions or prevent the in-app notification from being stored. Provide bounded retries and deduplication for normal event reprocessing, with observable terminal failures.
  5. Manageability: Include a link to notification preferences and support existing interface languages where practical.

Suggested acceptance criteria:

  • With SMTP configured, operator enablement on, and a category opted in, an eligible new event generates an email even when the recipient has no browser session.
  • Operator disablement and per-category opt-out suppress notification emails.
  • In-app and email preferences work independently.
  • A rolled-back transaction sends no email; SMTP errors leave the business action and in-app notification intact.
  • Missing/ineligible recipient email is handled explicitly, without sending to an untrusted fallback address.
  • Tests cover successful delivery, preferences, transaction boundaries, failure/retry behavior, and duplicate event processing.
  • Operator documentation explains configuration, sender identity, expected delivery behavior, and troubleshooting.

Digests, chat integrations, arbitrary recipient addresses, and a general notification-rules engine can remain separate follow-ups.

Alternatives Considered
  • In-app notifications only: Useful while using the site, but do not reach users who are away from it.
  • External polling scripts or database integrations: Require each deployment to reproduce recipient selection, authorization, preferences, and delivery handling.
  • Email digests first: Could reduce volume, but add scheduling and aggregation to the initial scope. Per-event opt-in delivery would address the immediate need.
Impact
  • UX: Add an email channel and delivery-eligibility guidance to notification settings.
  • Backend/persistence: Extend channel handling and preference storage as needed. Any durable delivery tracking should use an additive migration.
  • Deployment: Reuse SMTP credentials and document new notification-specific settings for supported deployment methods.
  • Observability: Expose delivery failures and retry exhaustion without logging credentials or sensitive message bodies.
  • Compatibility: Preserve current in-app behavior and password-reset email behavior when notification email is disabled.
Contract Or SDK Impact

The notification preference API and channel enum would gain EMAIL; update OpenAPI and regenerate affected web types/SDKs if these contracts change. No CLI protocol change is requested. Update operator and user documentation.

This is a feature proposal for maintainer discussion; the exact configuration names and delivery implementation can follow the project's architecture conventions.

Dominant language
Java
Stars
5.2k
Forks
841
Avg merge
1d 4h
Merged PRs (30d)
77

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from iflytek/skillhub

All issues in iflytek/skillhub

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.