Feature/message email notifications queue#637
Feature/message email notifications queue#637Juergen-Coding wants to merge 2 commits intoNuSkooler:masterfrom
Conversation
| @@ -0,0 +1,1071 @@ | |||
| { | |||
There was a problem hiding this comment.
This is YOUR bbs file, not the menu template file
| // Hide soft-deleted messages (we mark them by subject = "[DELETED]") | ||
| // Set filter.includeDeleted = true if you ever want to include them again. | ||
| if (true !== filter.includeDeleted) { | ||
| appendWhereClause(`IFNULL(m.subject, '') <> '[DELETED]'`, 'AND'); |
There was a problem hiding this comment.
We don't yet have soft deleted implemented, so this wouldn't work in the master branch
| self.updateUserAndSystemStats(callback); | ||
| }, | ||
| function queueNotifications(callback) { | ||
| fs.appendFileSync( |
There was a problem hiding this comment.
A couple issues here:
- We can't call sync code in the async context
- Hard coded paths, writing to a file like this, etc. isn't really the way to go. We have logging facilities. Queuing/etc., we have existing systems to look at (e.g. use the DB, or in memory if you're not worried about persistence)
| const PROMPT_VIEW_ID = 2; | ||
| const MAX_RENDER_LINES = 10; | ||
|
|
||
| const C_RESET = '\x1b[0m'; |
There was a problem hiding this comment.
Enigma uses a theming system, not hard coded colors/etc. For IDs, so on, see existing menu modules.
OpenAI should especially be able to follow the existing patterns. :)
|
Hi Nu, Thank you for taking the time to review my pull request and pointing out where my implementation doesn't yet fully conform to existing ENiGMA patterns. I tend to generate a lot of ideas quickly, but I also understand that for working on the upstream project, I need to study the project structure more closely and better adapt to the framework established in ENiGMA. That's exactly what I'm trying to do right now. To structure this process, I've written a short Markdown document summarizing the rules and patterns that I believe can be derived from your comments, the master tree, and the ENiGMA documentation. It's not an official project document, but simply a working framework for me to make the feature cleaner and more upstream-friendly. Would you please take a quick look at the Markdown file and let me know if my understanding is essentially correct? My goal is to use this as a guideline for the next revision, ensuring my ideas remain within the bounds of what makes sense for ENiGMA and don't drift into overly localized or individualized solutions. ;) enigma_upstream_starters.zip: The goal isn't to introduce additional abstraction, but rather to make the expected patterns of ENiGMA easier to understand in practice. Specifically, it could help contributors distinguish between local BBS-specific changes and changes suitable for the upstream project, and provide small reference structures for menu modules, module persistence, and planned internal tasks. I hope this will reduce misunderstandings in future pull requests and facilitate the development of new features that adhere to the established ENiGMA structure from the outset. Basically, it's for my understanding. ;) Then next week I'll get to work adapting the new "features" to the Enigma BBS framework. I also need to familiarize myself with GitHut first. :) Thanks & Cheers! Have fun! Jürgen |
|
Without looking, I would make sure that at least the following details were allowed to be set globally as well as to individual message boards.
This way you don't overload someone's inbox to the point they just ignore everything. |
|
On the coding guidelines, I would maybe suggest a separate pull request, expanding on the CONTRIBUTING.md document, which is where developer documentation tends to start, maybe with a ./docs/dev/ directory reference for expanded documentation. Agents are pretty good at looking for at least README.md (which should reference CONTRIBUTING.md), or you can create a .gitignor'd YOURAGENT.md file that references CONTRIBUTING.md directly... Personally I try to make the documentation good for both people and agents when working with AI, assuming you are doing so. I don't know how @NuSkooler would feel about a CLAUDE.md and/or AGENTS.md that simply contains |
|
Definitely need to beef up docs for AI consumption - |
3 participants
Summary
This PR adds email notifications for message areas, including a per-area user settings menu inside ENiGMA BBS.
Users can now configure notification preferences for selected message areas and receive email notifications for:
The implementation uses a queue-based approach with scheduled processing, so notification delivery is decoupled from message posting.
What this PR adds
1. Queue-based email notification delivery
Instead of sending notification emails directly during message posting, this PR introduces a queue-based workflow:
This keeps message posting responsive and makes delivery more robust.
2. Scheduled worker integration
The notification worker can be triggered through ENiGMA's event scheduler, which makes the solution suitable for both Linux and Windows environments without requiring a Linux-specific daemon/service model.
The worker:
3. Per-user notification settings menu
A new Notifications entry was added to the Message Menu.
Users can enter the notification settings screen and configure email behavior per eligible message area.
Current per-area options:
N= email on new postsR= email on replies to the user's own postsOnly areas explicitly allowed by configuration are shown to the user.
4. Per-area policy support
This PR adds policy handling so that each area can independently allow:
This keeps the feature flexible and prevents notification options from appearing where the sysop does not want them.
5. Notification UI / ANSI integration
The notification settings screen now uses dedicated art files:
NTFMNU.ANSfor the main screenNTFPMPT.ANSfor the prompt areaThe dynamically generated area list is rendered inside the menu module, while the static layout remains in ANSI art.
The list was also visually improved so that:
N:andR:labels are clearerON/OFFstates are color-codedImplementation details
Core behavior
Notification queueing is integrated into message posting/view logic and related notification policy checks.
New modules
This PR introduces notification-related modules for:
Menu integration
The Message Menu now includes an
Ncommand to enter notification settings.Configuration
The worker interval and related behavior are configurable through the existing config structure.
Files included in this PR
New files
art/general/NTFMNU.ANSart/general/NTFPMPT.ANSconfig/menus/the_news_bbs-message_base.hjsonmods/notification_db.jsmods/notification_policy.jsmods/notification_queue_worker.jsmods/notification_settings_menu.jsUpdated files
core/message.jscore/msg_area_post_fse.jscore/msg_area_view_fse.jspackage.jsonpackage-lock.jsonyarn.lockBehavior from a user perspective
A user can now:
Nfor Notifications1Nfor new-post email notifications in area 11Rfor reply email notifications in area 1Testing performed
The feature was tested locally with real message posting and real email delivery scenarios.
Verified during testing:
Notes
Known limitations / future follow-up ideas
Possible follow-up improvements:
Why this approach
A queued notification model is safer and cleaner than sending email directly from the posting path.
It provides: