6.3 KiB
Requirements Clarification Questions — Master CMS Module
Please answer each question by filling in the letter choice after the [Answer]: tag.
If none of the options match your needs, choose the last option (Other) and describe your preference.
Question 1
The CMS page (/cms) currently exists in the frontend but shows no content. What should the Master Module display on this page?
A) A list of registered slave CMS instances with their current availability status and controls to enable/disable them B) A dashboard combining both slave CMS management and module configuration (e.g., toggle Master Module on/off) C) Only module configuration — the slave CMS list is managed elsewhere (e.g., a separate admin API) D) Other (please describe after Answer: tag below)
Question 2
What are "other CMSes" in this context? How should slave CMS instances be registered with the Master?
A) Other deployed instances of the same SlpModularCms application — registered via URL + API key in the Master's database B) Abstract "tenants" or "sites" stored in the Master's database — not necessarily running SlpModularCms C) The slave CMSes share the same database as the Master — just different data rows (multi-tenant, single DB) D) Other (please describe after Answer: tag below)
Question 3
When the Master Module sets a slave CMS as "unavailable", how does the slave CMS enforce this?
A) The slave CMS calls the Master's API on every request to check if it is still available (pull model)
B) The Master pushes availability status to the slave CMS (webhook / push model)
C) The slave CMS and Master share a database — the slave reads the Master-controlled status directly from a shared table
D) The Master sets availability via the slave's own availability API endpoint (the existing PUT /api/availability/status)
E) Other (please describe after Answer: tag below)
Answer: E, probably a combination of A and D. For context: As a developer I have clients using the slave CMSes. In the event the client doesn't pay or violate another agreement I want to have the possibility to disable the slave CMS. To prevent the client from circumventing this by editing a value in their own database I want it to pull it from the master. But in the event the master is unavailable it is also stored in their own DB. The slave CMS can also just check their own value to prevent excessive traffic to the master and just get the status only a few times or once per session within a few hours for example.
Question 4
The existing availability middleware currently checks a local IAvailabilityService. How should the middleware on a slave CMS know to consult the Master instead of its local service?
A) A new configuration flag in appsettings.json (e.g., MasterModule:MasterUrl) — if set, the slave uses the Master; if not set, local check
B) The Master Module is installed on the slave CMS too but in "slave mode" — it overrides the local availability service
C) A separate middleware or service replaces the existing one when a Master URL is configured
D) Other (please describe after Answer: tag below)
Answer: D, The availability check should be hardcoded to check the master if the master module is enabled, but it should also keep sits current functionality. The master module should be enabled by the owner of the master CMS and not by the client. The client should not be able to configure this.
Question 5
The CMS that has the Master Module enabled should be exempt from the external availability check. How should this exemption be implemented?
A) Configuration-based: a flag in appsettings.json (e.g., MasterModule:IsMaster: true) bypasses the external check entirely
B) Auto-detected: if the Master Module is registered and active, skip the external check automatically
C) The Master CMS still has a local availability check (its own IAvailabilityService) but ignores external Master checks
D) Other (please describe after Answer: tag below)
Answer: B + C
Question 6
Which roles can use the Master Module features (viewing/managing slave CMSes)?
A) Owner only B) Owner and Administrator C) All authenticated users can view; only Owner can modify D) Other (please describe after Answer: tag below)
Question 7
Does the Master Module require changes to the existing availability middleware (AvailabilityMiddleware) in the Availability module, or should it be implemented as a new separate module?
A) Extend the existing Availability module — add Master Module logic there
B) Create a new separate module SlpModularCms.Modules.Master that works alongside the Availability module
C) Create a new module that REPLACES the Availability module on Master CMS instances
D) Other (please describe after Answer: tag below)
Answer: B, it should be a separate module, because only the master CMS should install the module. The slaves should not have the module installed and should still be able to use the current functionality.
Question 8
Should the Master Module include a new database entity to store slave CMS registrations (name, URL, current availability status), or reuse an existing entity?
A) Yes — new CmsInstance entity in the database (name, URL, status, last updated)
B) New entity but only in-memory / configuration — no database persistence for slave CMSes
C) Reuse the existing GlobalAvailabilityState concept, extended with a multi-tenant key
D) Other (please describe after Answer: tag below)
Question 9
For the frontend: the /cms route is currently restricted to the Owner role. Should this change?
A) No change — keep /cms Owner-only
B) Allow Administrator role as well (read-only or full access)
C) Allow any authenticated user to view, but restrict modifications to Owner
D) Other (please describe after Answer: tag below)
Question 10
Should the Master Module be part of this same codebase (monorepo), or is it a separate deployment concern?
A) Same codebase — a new project SlpModularCms.Modules.Master within the existing solution
B) Same codebase AND the frontend changes to show the Master UI are included in this feature
C) Backend only — frontend changes are a separate follow-up feature
D) Other (please describe after Answer: tag below)