backend-manager 5.0.89 → 5.0.92

package/test/routes/admin/email.js

@@ -1,14 +1,48 @@
 /**
  * Test: POST /admin/email
- * Tests the admin send email endpoint
- * Requires admin authentication and SendGrid API key configured
+ * Route-level tests: auth, permissions, HTTP status codes, basic send/queue
+ *
+ * Library-level tests (validation, dedup, recipients, features) are in test/helpers/email.js
  */
 module.exports = {
-  description: 'Admin send email',
+  description: 'Admin send email (route)',
   type: 'group',
   skip: !process.env.TEST_EXTENDED_MODE ? 'TEST_EXTENDED_MODE env var not set (skipping email tests)' : false,
   tests: [
-    // Test 1: Missing subject returns 400 error
+    // --- Auth / Permissions ---
+
+    {
+      name: 'unauthenticated-rejected',
+      auth: 'none',
+      timeout: 15000,
+
+      async run({ http, assert, config }) {
+        const response = await http.post('admin/email', {
+          subject: 'Test Email',
+          to: [{ email: `_test-receiver@${config.domain}` }],
+        });
+
+        assert.isError(response, 401, 'Send email should fail without authentication');
+      },
+    },
+
+    {
+      name: 'non-admin-rejected',
+      auth: 'basic',
+      timeout: 15000,
+
+      async run({ http, assert, config }) {
+        const response = await http.post('admin/email', {
+          subject: 'Test Email',
+          to: [{ email: `_test-receiver@${config.domain}` }],
+        });
+
+        assert.isError(response, 403, 'Send email should fail for non-admin user');
+      },
+    },
+
+    // --- Basic Validation ---
+
     {
       name: 'missing-subject-rejected',
       auth: 'admin',
@@ -18,14 +52,14 @@ module.exports = {
         const response = await http.post('admin/email', {
           to: [{ email: `_test-receiver@${config.domain}` }],
           copy: false,
-          ensureUnique: false,
         });
 
         assert.isError(response, 400, 'Missing subject should return 400');
       },
     },
 
-    // Test 2: Status 'sent' - Email sent successfully via SendGrid
+    // --- Happy Path ---
+
     {
       name: 'status-sent',
       auth: 'admin',
@@ -36,7 +70,6 @@ module.exports = {
           subject: 'BEM Test Email - Status Sent',
           to: [{ email: `_test-receiver@${config.domain}`, name: 'Test Receiver' }],
           copy: false,
-          ensureUnique: false,
           data: {
             email: {
               subject: 'BEM Test Email - Status Sent',
@@ -47,11 +80,10 @@ module.exports = {
 
         assert.isSuccess(response, 'Admin should be able to send email');
         assert.hasProperty(response, 'data.status', 'Response should have status');
-        assert.equal(response.data.status, 'sent', 'Status should be sent when ensureUnique is false');
+        assert.equal(response.data.status, 'sent', 'Status should be sent');
       },
     },
 
-    // Test 3: Status 'queued' - Email scheduled beyond 71 hours
     {
       name: 'status-queued',
       auth: 'admin',
@@ -64,7 +96,6 @@ module.exports = {
           subject: 'BEM Test Email - Status Queued',
           to: [{ email: `_test-receiver@${config.domain}`, name: 'Test Receiver' }],
           copy: false,
-          ensureUnique: false,
           sendAt: sendAt,
           data: {
             email: {
@@ -79,85 +110,5 @@ module.exports = {
         assert.equal(response.data.status, 'queued', 'Status should be queued when sendAt is beyond 71 hours');
       },
     },
-
-    // Test 4: Status 'non-unique' - Duplicate email detected
-    {
-      name: 'status-non-unique',
-      auth: 'admin',
-      timeout: 120000,
-
-      async run({ http, assert, config }) {
-        const uniqueSubject = `BEM Test Email - Unique Check ${Date.now()}`;
-
-        const response1Promise = http.post('admin/email', {
-          subject: uniqueSubject,
-          to: [{ email: `_test-receiver@${config.domain}` }],
-          copy: false,
-          ensureUnique: true,
-          categories: ['bem-test-unique'],
-          data: {
-            email: {
-              subject: uniqueSubject,
-              body: 'Testing ensureUnique feature.',
-            },
-          },
-        });
-
-        const response2Promise = http.post('admin/email', {
-          subject: uniqueSubject,
-          to: [{ email: `_test-receiver@${config.domain}` }],
-          copy: false,
-          ensureUnique: true,
-          categories: ['bem-test-unique'],
-          data: {
-            email: {
-              subject: uniqueSubject,
-              body: 'Testing ensureUnique feature.',
-            },
-          },
-        });
-
-        const [response1, response2] = await Promise.all([response1Promise, response2Promise]);
-
-        assert.isSuccess(response1, 'First email should succeed');
-        assert.isSuccess(response2, 'Second email should succeed');
-
-        const statuses = [response1.data.status, response2.data.status].sort();
-        assert.equal(statuses[0], 'non-unique', 'One email should have status non-unique');
-        assert.equal(statuses[1], 'sent', 'One email should have status sent');
-      },
-    },
-
-    // Test 5: Unauthenticated request fails
-    {
-      name: 'unauthenticated-rejected',
-      auth: 'none',
-      timeout: 15000,
-
-      async run({ http, assert, config }) {
-        const response = await http.post('admin/email', {
-          subject: 'Test Email',
-          to: [{ email: `_test-receiver@${config.domain}` }],
-        });
-
-        assert.isError(response, 401, 'Send email should fail without authentication');
-      },
-    },
-
-    // Test 6: Non-admin user fails
-    {
-      name: 'non-admin-rejected',
-      auth: 'basic',
-      timeout: 15000,
-
-      async run({ http, assert, config }) {
-        const response = await http.post('admin/email', {
-          subject: 'Test Email',
-          to: [{ email: `_test-receiver@${config.domain}` }],
-        });
-
-        assert.isError(response, 403, 'Send email should fail for non-admin user');
-      },
-    },
   ],
 };

package/REFACTOR-BEM-API.md

@@ -1,76 +0,0 @@
-We need to do a pretty significatn refactor of our BEM API now.
-
-Since that was orignally implemented, I built a much better process for hading incoming http requests. That is, the route/schema system found here:
-/Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/helpers/assistant.js
-/Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/helpers/middleware.js
-/Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/helpers/settings.js
-
-You can see an example of it in our consuming project:
-/Users/ian/Developer/Repositories/ITW-Creative-Works/ultimate-jekyll-backend/functions/index.js
-/Users/ian/Developer/Repositories/ITW-Creative-Works/ultimate-jekyll-backend/functions/routes/example/index.js
-/Users/ian/Developer/Repositories/ITW-Creative-Works/ultimate-jekyll-backend/functions/schemas/example/index.js
-
-We built a single unified bem_api function that handles all http requests in a single place, and then routes them, see here:
-/Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/index.js
-.https.onRequest(async (req, res) => self._process((new (require(`${core}/actions/api.js`))()).init(self, { req: req, res: res, })));
-
-We should refactor this system to USE THE NEW ROUTE/SCHEMA SYSTEM rather than the old way of doing things. This will make it much easier to maintain and extend in the future.
-
-We can start with a simple one like:
-/Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/functions/core/actions/api/general/generate-uuid.js
-
-and once we perfect that we can move on to the others.
-
-For each BEM refactor, we should create a route and a schema for the expected input. As you can see, BEM APIs epect a command and payload in the body, requiring it to be a POST operation. I would like to rebuild this system to be more proper, so that each BEM api can be GET, POST, etc as appropriate.
-
-Previously:
-request('/backend-manager', {
-  method: 'POST',
-  body: {
-    command: 'generate-uuid',
-    payload: { ... }
-  }
-})
-
-but i think it owud be more intuitive if going forward we just had endpoints like:
-request('/backend-manager/general:uuid', {
-  method: 'POST',
-  body: { ... }
-})
-OR
-request('/backend-manager/general/uuid', {
-  method: 'POST',
-  body: { ... }
-})
-
-Im not sure how we can do this to be backwards compatible with existing BEM API consumers, but it does need to be backwards compatible.
-
-If you look at the firebase.json in the consuming project we can see that
-/Users/ian/Developer/Repositories/ITW-Creative-Works/ultimate-jekyll-backend/firebase.json
-{
-  "source": "/backend-manager",
-  "function": "bm_api"
-},
-
-So maybe we could make it:
-{
-  "source": "/backend-manager/**",
-  "function": "bm_api"
-},
-and then parse the route inside the bem_api function to determine which route/schema to use, falling back to the old system if the route is just /backend-manager with a "command" in the body, and then use the new route/schema system if the path is /backend-manager/something?
-
-Either way, i think we need a minimal intermediary step where we determine which one to use based on the incoming request and then either just route to the old one or route to the new "middleware", "settings", route/schema system
-
-I would like each new route to have a great name clearly indicating its purpose, the method should be appropriate for the action (GET for fetches, POST for creates, etc) and the schema should be well defined for each route.
-
-Since we can build this new API system however we want, i also expect you to rewrite and refactor the BEM api endppints to be kickass, modern, and well designed.
-
-Also, certain VERBS should be removed from the actual file/function names since they are implied by the HTTP method. For example, instead of having a generate-uuid.js file, we could just have uuid.js since the POST method implies that we are generating/creating a new one, or insetad of add-marketing-contact we could just have marketing-contact.js since the POST method implies adding a new one and GET would imply fetching them.
-
-Next, some fucntions have a lot crammed isnide them that could use some separation. For example, in add-marketing-contact.js we have code for handling multiple email providers (SendGrid, Beehiiv) all jammed into a single file. I think we should refactor this to have a separate file for each provider in subfolder that handles the specifics of that provider, and then the main route file just calls those provider-specific files as needed. This will make it much easier to maintain and extend in the future as we add more providers.
-
-Also, sometimes there are two endpoints that should be combined,for example
-* /Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/functions/core/actions/api/general/add-marketing-contact.js
-* /Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/functions/core/actions/api/general/remove-marketing-contact.js
-These could be combined into a single marketing-contact.js file that handles both adding and removing based on the HTTP method (POST for add, DELETE for remove). This will make the API more RESTful and easier to understand.
-

package/REFACTOR-MIDDLEWARE.md

@@ -1,62 +0,0 @@
-MIDDLEWARE REFACTOR
-We have a system where we handle incoming requests using a route/schema system found here:
-/Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/helpers/assistant.js
-/Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/helpers/middleware.js
-/Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/manager/helpers/settings.js
-
-You can see an example of it in our consuming project:
-/Users/ian/Developer/Repositories/ITW-Creative-Works/ultimate-jekyll-backend/functions/index.js
-/Users/ian/Developer/Repositories/ITW-Creative-Works/ultimate-jekyll-backend/functions/routes/example/index.js
-/Users/ian/Developer/Repositories/ITW-Creative-Works/ultimate-jekyll-backend/functions/schemas/example/index.js
-
-I have some ideas iw as thinking about and id like to know your thoughts:
-* new design so that each route is modern JS that does a single export instead of exportting a class with an init() and a main() method.
-* schema system currently uses the user's plan when designing the schma like
-module.exports = function (assistant) {
-  return {
-    // DEFAULTS
-    ['defaults']: {
-      key: {
-        types: ['string'],
-        value: undefined,
-        default: '',
-        required: false,
-        min: 0,
-        max: 2048,
-      },
-    },
-
-    // Premium plan
-    ['premium']: {
-      key: {
-        types: ['string'],
-        value: undefined,
-        default: 'premium-default',
-        required: false,
-        min: 0,
-        max: 4096,
-      },
-    }
-  };
-}
-
-however it hink we should instead eliminate the toplevel plan/default system and code each plan changes into the individual keys like:
-  const schema = {
-    id: {
-      types: ['string'],
-      value: () => assistant.Manager.Utilities().randomId(),
-      required: false,
-    },
-    feature: {
-      types: ['string'],
-      default: '',
-      required: true,
-      min: 1,
-      max: 4,
-    },
-  };
-
-  // Adjust schema based on plan
-  if (assistant.user.plan === 'premium') {
-    schema.feature.max = 8;
-  }

package/REFACTOR-PAYMENT.md

@@ -1,66 +0,0 @@
-PAYMETN SYSTEM REFACTOR
-Question
-Propose a schema for storing user's subscription data in their firestore user document. Currently the user looks like this
-users/{uid}
-{
-  auth: {
-    uid: string,
-    email: string,
-  },
-  roles: {
-    admin: boolean,
-  },
-  ... (other stuff that is not really relevant)
-}
-I will be using a variety of payment processors including Stripe and PayPal, so I need a flexible way to store subscription data that can work with multiple providers.
-Before inserting the subscription data, we wil need to receive the processor webhooks.
-We will be keeping track of the subcsription data in the user doc AS WELL AS a dedicated subscription doc where we can have more information
-Thus, the user doc doesnt need to contain the entire subscription Object, just enough to grant the user access to premium features in the backend or frontend as well as display important info in the user's account page like next billing date, plan name, status, anything else that is important.
-Also, since we will be checking subscription status often, I thought it would be nice to store 2 main objects:
-1. the original subscirpiton object from the payment provider, unmodified
-2. a unified and standardized subscription object that we define, so that when checking subscription status we dont have to deal with the differences between payment providers (both for displaying info and for checking status/plan/etc to grant access when making requests or on the frontend)
-We could store BOTH in both the user doc and the subscription doc, or only store the unified object in the user doc and both in the subscription doc.
-
-For our standardized Object, we should be able to get the current plan and whether the subscription is active or not EXTREMELY easily. LIke a single if statement, allowing us to grant access if if the user is premium or whatever.
-
-However, i would like it to be flexible enough so that we can show something like:
-  - User is on premium plan and paid up --> grant access to premium features, show "You are Premium and your next billing date is X"
-  - User is on premium plan but payment failed --> restrict access to premium features, show "Your payment failed, please update your payment method"
-  - User was on premium plan but cancelled --> restrict access to premium features, show "You WERE premium but it was cancelled so now youre on Free plan"
-  - User was on premium plan but cancellation is pending --> grant access to premium features, show "You are Premium until X date when your plan will be cancelled"
-  - User is on trial --> grant access to premium features, show "You are on a free trial that ends on X date"
-So essentially we need a way to be able to determine all of these different scenarios EASILY (SINGLE IF STATEMENT)
-
-I know all payment proivders are different and ahve different concepts of how exaclty a subscirption is active, cancelled, past due, trialing, etc but we need to come up with a unified way of representing this data in our standardized object so that we can easily check status and display info regardless of payment provider.
-
-Like, i i think stripe you can "cancel at period end" and thus the sub will not actually be cancelled until the end of the billing period, but paypal might be slightly different.
-
-BEM API ENDPOINTS
-* For our payment system to work, we shoudl implemnt some BEM API endpoints to create, listen for webhooks, and manage subscriptions.
-* anytime there is an aciton that handles multiple payment providers, we should have the entryppoint import a file for each provider, where each provider handles the request in its own way, but STILL STANDARDIZED and similar across all providers.
-
-backend-manager/payments/intent
-* handle creating payment intents or equivalent in other providers
-* various checks like
-  * is the user currently subscribed? if so block
-  * is the user allowed to have a trial (havent had one before)? if not block their trial
-  * validate their gcaptcha token. block if invalid or missing
-  * create the payment intent or equivalent at "payments-intents/{id}" in firestore
-
-backend-manager/payments/webhook (or something similar)
-* handle receiving webhooks from payment providers to update subscription status
-* different file for processing each paymnt processor (returning some comon things like the event id)
-* various checks like
-  * verify the webhook by checking the querystring for the BEM token (same as .env BACKEND_MANAGER_KEY)
-  * check for payment-webhooks/{id} doc to see if we already processed this webhook (id is provided by the payment provider in the webhook payload)
-  * Immediately save the raw webhook data to "payments-webhooks/{id}" in firestore so we can return a 200 as soon as possible. THe webhook will be processed in a firestore function trigger onWrite for that doc (status === pending)
-
-Firestore trigger for payments-webhooks/{id}
-* process the webhook data and update the user's subscription data in both their user doc and their subscription doc
-* various checks like
-  * if status === completed, do nothing
-
-THen, we need to plan an effective way to test all of these scenarios in our emualted testing environment which you can explore here: /Users/ian/Developer/Repositories/ITW-Creative-Works/backend-manager/src/test
-* we should be able to START with certain subscripton levels (basic/free, premium etc) and then see how events influence and change the subscription status and data in the user doc, subscription doc, webhook event doc, etc
-
-So webhook comes in --> save immediateyl to return 200 to the payment provider --> process the webhook in a separate function trigger to update subscription data and user access (reprocess if something goes wrong, etc)