Notifications API / Saas

Using PHPRunner with a centralized database for multi-tenant applications can be a bit tricky, especially when it comes to features like the Notifications API. The core issue you're facing seems to revolve around permissions and the correct handling of notifications across different tenants in your application.

Here are some steps and suggestions that may help you troubleshoot and potentially resolve the issue:

1. Check Permissions Configuration: Ensure that the permissions for notifications are correctly set up for each tenant. You might need to customize the permissions handling in the classes/notifications.php file to accommodate multi-tenant logic.

   
   

2. Review the Notifications API Documentation: Make sure you've reviewed the PHPRunner documentation regarding the Notifications API. Look for any notes or examples that might pertain to multi-tenant setups.

   
   

3. Custom Code Implementation: If the built-in functionality does not meet your needs due to the centralized database structure, consider implementing custom logic to handle notifications. You can create a custom function that checks which tenant should receive which notifications based on the user or tenant context.

   
   

4. Database Structure: Ensure that your database schema supports multi-tenancy effectively. For example, you may want to have a tenant_id column in your notifications table to filter notifications based on the tenant.

   
   

5. Testing: Create test cases for different scenarios where notifications should be sent to users from different tenants. This can help identify if the problem lies in the logic or the integration of the Notifications API.

   
   

6. PHPRunner Support Forum: If you haven't already, consider posting your issue on the PHPRunner support forum or community. Other users who have experience with similar setups might have encountered the same issue and can provide insights or solutions.

   
   

7. Update PHPRunner: Since you're using version 10.91.2, check if there are any updates or patches available. Sometimes, issues are resolved in newer versions.

   
   

8. Error Logging: If you encounter any errors, enable error logging in PHPRunner to capture detailed error messages that can provide clues about what's going wrong.

   
   

By following these steps, you should be able to diagnose the issue further and determine a viable solution for implementing the Notifications API in your multi-tenant application. If you have specific error messages or behavior you're observing, feel free to share, and I can provide more tailored advice.

Unfortunately I have no idea what "class code for permissions in classes / notifications file" is. Since this is a SaaS kind of project you need to make sure that notofication tables are located individual tenant databases.

So Yes it is the classes/notifications.php in the source code.
As far as the tenant table for _noti my code below is writing _noti data to the project _noti table in the users database _noti table instead of the tenanant _noti table and security tables are all correct as all other tables and permissions work correctly .

I get infinite loading error because , the notification data is not present in the teanant _noti table and is writing to the wrong table. Unless you have to explicitly select it with a database connection which defeats the purpose of the dbname and SaaS setup as documented.

// Target salesman login (resolved via dependent dropdown)
if (empty($values["username_email"])) {
return;
}

// Build notification message
$message =
"A new allocation has been assigned to you.\n\n" .
"Allocation: " . $values["allocation_name"] . "\n" .
"Brand: " . $values["brand_desc"] . "\n" .
"Brand / Size: " . $values["brandandsize"] . "\n" .
"Expires: " . $values["date_expire"];

// Optional expiry
$expire = !empty($values["date_expire"])
? $values["date_expire"]
: null;

// Send notification
addNotification(
$message,
"New Allocation Assigned",
"fa-box",
null, // ❗ NO URL
$expire,
array("user" => $values["username_email"]),
false
);

Update:
It appears I may be the first one who uses the SaaS setup and tried the Notifications API , as I find nothing about this anywhere in forums or videos.

This is what I found in multiple tests and why this will never work without an updated class for classes/notifications.php and possilbe some othe rendering page also. Ex. Bootstrap UI

In my setup:

This is a true SaaS deployment with one central users database and separate physical databases per tenant
Authentication and session state are centralized
Tenant databases are switched at runtime after login
This setup was recommended and already works correctly for:

authentication

security

user settings (column widths, layouts, etc.) stored in the users database

When the Notification API is enabled:
PHPRunner always writes notifications to the users database (this works correctly)
PHPRunner always reads notifications during page bootstrap / header rendering
This happens regardless of whether permissions are set, null, or same-user
I tested the following explicitly:

Notifications with all parameters null

Notifications sent to the same logged-in user

Notifications sent to another user

Notifications with no unread records

In all cases, the moment addNotification() is called:

The page enters an infinite loading loop

Logout also breaks

The notification bell never renders
This occurs even though the notification row is written correctly to the users database.
This confirms the issue is not permissions, not user matching, and not table location, but rather that the notification subsystem initialization itself is not DB-context-safe when tenant pages are rendered from a different database than the users database.

Placing _noti tables in each tenant database does not help, because:
The Notification API never queries tenant notification tables
It is hard-wired to the users/security connection
Rendering notifications assumes the page and notification tables share the same database context
This is fundamentally different from user settings, which are passive, late-bound, and do not participate in bootstrap or security flow.

From testing, it appears that the Notification API cannot be invoked at all in a DB-per-tenant SaaS setup without causing a bootstrap recursion.

I believe this is not a usage error, but an architectural limitation of the current Notification API design.

But since it is writing to the users _notification table correctly , this is the line of why it won't render ans is still permission related

public function __construct( $params ) {
$this->enabled = $params["enabled"];
$this->table = $params["table"];
// THIS LINE BELOW SEEMS TO BE THE ISSUE , IT can't switch the database from tenant to users for SaaS setup. And yes the notifications API automatically sends data
// to the users table not each tenant and there is no choice in MISC tab when turning on this API to choose which connection to use.

in th class/notifications.php source code.

Therefore the only way to fix is
The notification table should remain centralized in users; the fix is to decouple notification initialization from tenant bootstrap and avoid re-entering Security::* during header rendering.