9.13 Legacy MultiTenancyApi Stack
⚠ This entire stack is classified "Stack B — SignalR hub + entity services", confirmed live, and explicitly not migrated into the Notification Framework packages ("Stack C"). It is frozen — do not build new features against it; it exists here purely so nothing in the platform's HTTP surface goes undocumented. Source:
NOTIFICATION_FRAMEWORK_LEGACY_ASSETS_VERIFICATION_REPORT.md(repository root), which states directly: "All entity services (59 files)... Cannot move... Keep."
Repository: Shumoul.Saas.MultiTenancyApi · Controllers under
Shumoul.Framework.MultiTenancy.Api\Controllers\ · Permissions come from a different constants class,
TenancyPermissions (not PermissionConstants).
9.13.1 NotificationsController — api/notifications
[AllowAnonymous] at controller level (each action still individually gated by [MustHavePermission]).
| Verb + route | Permission | Response |
|---|---|---|
GET Get | TenancyPermissions.Notifications.ViewAll | List<NotificationDto> |
POST GetDataTable | TenancyPermissions.Notifications.ViewAll | DtResult<NotificationDto> |
GET GetDetails/{id} | TenancyPermissions.Notifications.View | NotificationDto |
GET GetEdit/{id} | TenancyPermissions.Notifications.Edit | NotificationEditDto |
POST Create | TenancyPermissions.Notifications.Create | string |
DELETE Delete/{id} | TenancyPermissions.Notifications.Delete | string |
PUT Update/{id} | TenancyPermissions.Notifications.Edit | string |
Underlying entity: NotificationRecord (renamed from Notification during Phase 4.0.2 of the Notification
Framework project to resolve a CS0118 namespace collision with Shumoul.Notification.* — table name
[Saas].Notifications unchanged, zero schema impact).
9.13.2 NotificationTemplatesController — api/Notifications/Templates
Same shape as above, for NotificationTemplateDto/NotificationTemplateEditDto, permission group
TenancyPermissions.NotificationTemplates.*. This is a separate template system from
AppNotificationTemplate (§9.2) — the two are not interchangeable and
serve different stacks entirely.
9.13.3 NotificationTopicsController — api/Notifications/Topics
⚠ Every [MustHavePermission] attribute in this controller is commented out in source. Effective
authorization today is whatever bare [Authorize]/[AllowAnonymous] is left on each action — permission
checks are not actually enforced for topic management, despite TenancyPermissions.NotificationTopics.*
constants existing and being referenced only in comments.
| Verb + route | Effective auth | Commented-out permission (not enforced) |
|---|---|---|
GET Get | [AllowAnonymous] | ViewAll |
POST GetDataTable | [AllowAnonymous] | ViewAll |
GET GetDetails/{id} | [Authorize] only | View |
GET GetEdit/{id} | [AllowAnonymous] | Edit |
POST Create | [AllowAnonymous] | Create |
DELETE Delete/{id} | [AllowAnonymous] | Delete |
PUT Update/{id} | [AllowAnonymous] | Edit |
This is a real authorization gap, not a documentation simplification — flag it to platform security owners if topic management is reachable in production; do not treat the commented-out attributes as equivalent to enforced permissions.
9.13.4 NotificationTopicSubscribersController — api/Notifications/Topics/Subscribers
Same commented-out-permission pattern as Topics:
| Verb + route | Effective auth |
|---|---|
POST Subscribe | [AllowAnonymous] |
POST Unsubscribe | [AllowAnonymous] |
GET GetDropDownList?topicId= | [Authorize] (no permission check) |
9.13.5 UserNotificationsController — api/UserNotifications
[Authorize] at controller level; no [MustHavePermission] anywhere in this controller — any
authenticated user can call every action (this is arguably intentional, since these actions only ever act on
the caller's own notifications, but it is worth noting the controller enforces that scoping in its query
logic, not via a permission attribute).
| Verb + route | Response |
|---|---|
GET Get | List<UserNotificationDto> |
POST GetDataTable | DtResult<UserNotificationDto> |
GET GetDetails/{id} | UserNotificationDto |
POST MarkAsRead/{id} | string |
POST MarkAsIgnored/{id} | string |
UserNotificationDto (bilingual Title/FTitle, Message/FMessage, Url, Status
(SaaSNotificationScheduleStatus), DisplayingHoursCount, CanBeIgnored, Read, Ignored) is the payload
delivered over the legacy SignalR hub — see Chapter 10 — SignalR.
9.13.6 NotificationHub — SignalR, not an HTTP controller
Shumoul.Framework.MultiTenancy.Api\Notifications\SignalR\NotificationHub.cs — [Authorize] class extending
Hub. Fully documented in Chapter 10 — SignalR. Included here only for completeness; it
has no [HttpX]/[Route] verbs.