Notifications Module: Generator hardcodes ‘NoteTest’ API and uses inconsistent, failing logic for Profile emails
I wasted a lot op MY API data getting nowhere with the Scriptcase API… here is the output it gave me to report this bug.
Scriptcase Version: 10.1.001 (Build 1) Module: Security / Notifications Module
Description
When generating the standard Notifications Module and selecting “Use the same API as the rest of the project”, the generated application fails to send emails to Profiles (Groups), while successfully sending emails to individual Users.
Upon inspecting the generated source code in the send_to_inbox method of the notif_form_sec_notifications application, there are two distinct generator bugs preventing Profile emails from dispatching.
Steps to Reproduce
Create a project with a custom dynamic SMTP array (e.g., stored in a global variable [sett_smtp]).
Generate the Notifications Module.
During the wizard, select the option to use the project’s existing email/API settings.
Run the application and send a notification to an individual “User”. (This works perfectly).
Send a notification to a “Profile”. (The notification appears in the database inbox, but the email fails silently).
Bug 1: Hardcoded ‘NoteTest’ API Profile
In the send_to_inbox method, the generator writes completely different logic for Users (f_type == 2) vs. Profiles (f_type == 1).
For Profiles, the generator forces the use of the sc_send_notification macro but fails to apply the project’s API settings. Instead, it hardcodes a dummy API profile:
PHP
else if( {f_type} == 1 ){
sc_send_notification([
// ... other parameters ...
'destiny_type' => 'profile',
'profile' => 'NoteTest', // BUG: Generator hardcodes this placeholder
]);
}
Copy
Because the API profile NoteTest does not exist, the macro silently fails to send the emails.
Bug 2: Incompatible Logic for Dynamic SMTP Configurations
For individual Users (f_type == 2), the generator uses a custom loop that calls a generated send_email() method. This method correctly utilizes sc_send_mail_api() and supports merging dynamic SMTP configurations (like [sett_smtp]).
However, for Profiles, it forces the sc_send_notification macro. This macro strictly requires a string representing an IDE-saved API Profile (like 'my_smtp_profile') and does not accept dynamic array configurations. Therefore, if a developer is using a dynamic, database-driven SMTP configuration for the rest of their project, the Profile notification send is fundamentally broken out-of-the-box and cannot be used without entirely rewriting the {f_type} == 1 block to bypass the macro.
Expected Behavior
The generator should accurately map the chosen API profile to the 'profile' parameter in sc_send_notification, rather than leaving 'NoteTest'.
Ideally, the logic should be unified. The Profile send (f_type == 1) should resolve the profile users into an array and pass them to the exact same send_to_inbox_users() and send_email() engine used by the User send (f_type == 2), ensuring 100% compatibility with custom/dynamic SMTP configurations.
Impact
Developers are forced to manually reverse-engineer and rewrite the generated code for Profile notifications, defeating the purpose of the automated module. Furthermore, because the macro fails silently, developers are completely unaware that their users are not receiving group emails until reported.