MyLife alerts

[Mookse]

establish mechanic for Cosmos to host a set of potential alerts that would appear on site Have it based on Q-session, and provide external way to reset this var, as alerts could happen any moment input mechanic for azure could just be vs-code, not concerned about that at the moment

• [x] specifications
• [x] container/table [same/system/alerts + test-data
• [x] create datamanager system variant
• [x] pipeline
• [x] frontend

[Mookse]

specifications

• [x] Identify different types of alerts needed (e.g., system messages, user notifications)
• [x] Specify what events or conditions will trigger each type of alert
• [x] Define how users will interact with these alerts (dismiss, follow-up actions)
• [x] Establish how and where on the site these alerts will be displayed
• [x] Consider accessibility and responsiveness in design
• [x] Define/Develop pipeline
• [x] Define testing criteria for different alert scenarios

[Mookse]

specifications

triggers

• [ ] Session Start Trigger: Initiating the alert structure at the start of a session is a smart approach. It ensures that alerts are relevant and timely. Incorporating a push notification mechanism or an extensible hook for future enhancements sounds like a solid plan. This allows for scalability and adaptability as the system evolves.
• [ ] System Interaction Trigger: Chats, and other identified meaningful interactions with the system could carry an "alerts" array from which the alert would display for member.
• [ ] System Member Login: Upon login, getAlerts() [or really any on-demand] is run

data

• "required": ["audience", "being", "content", "dismissable", "id", "mbr_id", "parent_id", "timestampRange", "type", "urgency"]

technical architecture

Frontend

• [x] Technology review: EJS with Koa, and Flex for design.
• [ ] Implement getAlerts() function to fetch alerts at session start and as part of the chat response.
• [ ] Design a container for alerts, allowing users to read, browse multiple alerts, and dismiss them easily.
• [ ] Utilize color coding for class-styling on different urgency levels: ["high", "medium", "low"] ^currently
• [ ] shown: once frontend has created and shown alert, send backend notice so that this alert id can be added to session.alerts.seen()

Backend

• server.js
  • ctx.MyLife searches live alerts periodically (e.g., once per minute).
  • check session to see if shown, shown=omit, put in state
  • on appropriate middleware/routes, makes call to data manager
  • start session
  • login
  • chat
• mylife-datamanager.mjs
  • Configure DataManager to retrieve relevant alerts based on predefined criteria
• session.mjs
  • pipeline for getAlerts() - session should be the one asking the dataservices I think, or it could ask Maht, but this is Maht, oy!
  • Store all alerts in the MyLife root session for timely dispensing.
  • store user-shown alerts in this.#alerts
• routes.mjs, functions.mjs
  • add getAlerts()
  • chat alerts node added

Database

• [x] new container: system partition on mbr_id
• [x] new table: alerts: see JSON-schema representation
• [ ] Restrict access to the system table to MyLife only, ensuring security and data integrity.

UI

• [ ] Alerts appear underneath the main navigation bar, making them highly visible without being intrusive.
• [ ] Different urgency levels are distinguished by color coding, aiding quick user recognition and response.

UX

• [ ] Users can dismiss alerts using a standard X-icon, offering a familiar and intuitive way to manage notifications.

testing

• create new alert
• alert is in timerange and shows user/member
• dismiss alert, does not show again for session

out-of-scope

• [ ] Frequency and Volume: It's good to start with basic functionality and then expand. Providing hooks or placeholders for future frequency control features is a prudent way to plan for scalability without overcomplicating the current build.
• [ ] User Customization: For now, skipping user customization simplifies development. Focusing on delivering a robust basic system before adding complexity is often a wise strategy.
• [ ] Member-Generated Alerts: Planning for member-generated alerts in a future ticket is a great way to manage project scope. It keeps the current focus clear while laying the groundwork for future enhancements.
• [ ] alert history
• [ ] System Error Triggers: Integrating alert triggers in every chat packet received is an innovative way to handle system errors. This method can efficiently notify users of any issues during their interaction with MyLife. It's a proactive approach to maintaining smooth user experiences.

[Mookse]

Backend Coding Task List

Database Integration

• [x] Setup Alert Table: Ensure the new alerts table in the database is properly configured and integrated.
• [x] Security Measures: Implement security protocols to restrict access to the system table, ensuring data integrity and privacy.

  Data Management

• [x] Update mylife-datasource-config.mjs
  • [x] set up datasource = this.system
  • [x] update .env and sample.env = MYLIFE_SYSTEM_DB_CONTAINER_NAME
• [x] Create alert.json: create schema for Alerts
• [x] Update mylife-datamanager.mjs
  • [x] Configure to retrieve and alerts based on specific criteria: nothing special, just getItems, but routed to system container
• [x] Update mylife-data-service.mjs
  • [x] getAlerts(_mbr_id): connects to correct container
  • [x] getAlert(_alert_id): connects to correct container

    Route and Function Updates

• [x] Update routes.mjs, functions.mjs, mylife-agent-factory.mjs
  • [x] Add getAlert[s]() functions

    Server Configuration

• [x] Modify server.js:
  • [x] Implement periodic searching for live alerts (e.g., every minute).
  • [x] Configure session checking for already shown alerts.
  • [x] Integrate appropriate middleware/routes for session start, login, and chat to trigger alert checks.
• [x] update mylife-agent-factory.mjs: master storage (modular) for server
  • [x] create system alert space in modular scope
  • [x] alerts getter references modular scope
  • [x] getAlerts() functionality gets and sets the modular array
  • [ ] add logic for date discrimination and anything else global

    Session Management

• [x] Enhance session.mjs:
  • [x] Implement pipeline for getAlerts() function.
  • [x] Ensure all alerts are stored in the MyLife root session.
  • [x] Manage user-shown alerts in session's alerts property.

    Testing and Validation

• [x] Test New Alert Creation: Verify the creation of new alerts and their proper functioning in the system.
• [x] Validate Alert Visibility: Check if alerts are visible to the user/member within the specified timerange.
• [x] Dismissal Functionality: Ensure that once dismissed, alerts do not show up again for the session.