|
|
users.png (57,616 bytes) |
|
|
Attached is what a non-admin user sees on the SMS Relentless settings page. As you can see, there is (1) no option to generate the webhooks; and (2) a Javascript `Uncaught TypeError: settingsfromdb is null` error that is likely causing the page to display incorrectly. user-settings.png (150,416 bytes) |
|
|
Also attached are some of the approximately 154 errors that appear in the log each time the SMS Relentless main app page is opened as a non-admin user. The app does not appear to trigger any errors for the admin user. logs-top.png (202,963 bytes) logs-bot.png (199,481 bytes) |
|
|
Today we had a chance to completely delete the app and all traces of it within Nextcloud (including dropping the `oc_sms_relent_*` tables and all related records in `oc_migrations`) for a fresh reinstall, so we could try again with a brand new empty configuration. The app's behavior did not change. It's also worth mentioning that some notifications and records of sent messages seem to be registered twice: typically sent messages show two identical records, spaced one second apart. This could just be a symptom of the bigger underlying issue we're facing, but wanted to point it out in case it's relevant. |
|
|
This is what the settings page should look for non-admin users. The options for generating webhooks are there. The issue is why in your installation this page isn't displayed properly. The JavaScript error that you mention above signals that an SQL query that gets data from the database fails. To begin debugging this issue please check if you logged in as admin and saved the name of the non-admin user in the 'Users Allowed' box, in the Telnyx section on the admin settings page of the app. Also, it would be useful to know if you installed Nextcloud directly on the server or you used the All-In_One docker image. What web server and MariaDB version are you using ?. non-admin_user.png (387,561 bytes) |
|
|
Also, since it was mentioned at https://github.com/DoubleBastionAdmin/sms-relentless/issues/6, it's worth adding that Nextcloud was manually installed and is not a Docker instance. |
|
|
So, if you log in as admin to Nextcloud, do you see the non-admin user on the 'Accounts' page of Nextcloud, belonging to a group different from 'admin'? Then, if you look at the admin settings page of SMS Relentless, do you have the non-admin user's name in the 'Users Allowed' box, in the Telnyx section on that page ? |
|
|
Issue 0000020 presents a problem that can have something in common with your issue. I was mentioning there: "The app tries to obtain the 'Display Name' for 'cloudadmin' from the table 'oc_accounts_data' of your Nextcloud installation. So, if you inspect your Nextcloud database and look into the 'oc_accounts_data' table and you see: cloudadmin displayname [empty space] it means this is the cause of the problem. " Do you see a regular display name in the 'value' column of the 'oc_accounts_data' table of your Nextcloud database, for your non-admin user ? |
|
|
Hi, thanks for the reply! 1. Nextcloud lists both users, one of which is "admin". Only the "admin" user is assigned to a group (the "admin" group); the other one is not assigned to any groups. 2. Executing "select * from `oc_accounts_data`" shows that both the regular user and the admin user have 'displayname' values equal to their uids (something we took care to change after reading issue 0000020!). Both the uids and display names consist only of a-z characters. 3. To further test the issue, we also temporarily created a user named "test" and changed the displayname value to "test", but the SMS Relentless user settings once again showed the incomplete page as in the image attached previously. When clicking Save at the bottom of that page, the fields are appended to the URL, so it is clearly not functioning as intended. |
|
|
Sorry if some of this was not included before; it seems we missed some of your notes and questions that came through while we were adding ours, and we only addressed the most recent ones: Yes, the non-privileged user was added to the "Users Allowed" list, saved, and the settings page was refreshed to confirm that it had in fact been saved (see attached). Nextcloud is installed directly, served by Apache 2.4.62-1~deb12u2 with mysqld 10.11.6-MariaDB-0+deb12u1. We agree that a failed SQL query appears to be the root cause. The administration settings page works without issue, as does the rest of the app's functionality. This leads us to believe that the issue happens specifically when the non-admin user's settings are retrieved. When that fails, the Javascript for the settings page also fails to function, which leaves only some of the settings visible. Maybe there is (a) a table we can examine to see if the expected values/settings are present; or (b) a specific location or log we can check to find the SQL query that fails; or (c) a certain PHP file from which we can trigger some debug output? admin-settings.png (140,021 bytes) |
|
|
Is it possible that the issue lies in the format of the AJAX request, rather than the subsequent SQL query? Here are some additional images from the Firefox web developer console that are curious: 1. The failed attempt to load user settings via AJAX from a URL which contains a PHP snippet as its query parameter (see GET headers on right). 2. A null response from the failed request. 3. Javascript that contains the "p($userid);" command inside PHP tags. This PHP is not parsed and executed, but rather passed as a literal string in the request for user settings. How should the AJAX GET request be structured? Should it pass a user ID/display name to the "getsettings" URL, or should it pass a string that contains PHP code? 1-failed-url.png (227,307 bytes) 2-null-response.png (205,991 bytes) 3-ajax-url.png (220,632 bytes) |
|
|
It seems that due to your web server settings, the "var userid = "<?php p($userId); ?>";" part in the "js/settings.js" file is not processed as needed. This is why the AJAX call that gets the user's settings from the "oc_sms_relent_settings" table fails and all the other AJAX calls that get data from the same table fail, as evidenced in the Nextcloud log errors that you posted above. There are alternative ways to get the current user ID that should work in cases similar to yours. I'll test a different method and publish an updated version of SMS Relentless in the next few days, then I'll let you know here. |
|
|
This is what we suspected could be the cause. One way to consider addressing this: 1. Include an input type="hidden" field (e.g. named "userid") on the page's HTML, and set that field's value from within PHP, where it is already accessible. Essentially we're just printing something like value="[USER_ID]" when the field is defined in HTML. 2. Then, from the "settings.js" script, read the value stored in the hidden field on the HTML page to assign the user ID var. Then the correct value will be appended to construct the AJAX URL for the request to load the user's settings. Our server is not configured to execute Javascript files as PHP or otherwise parse them for PHP tags, and we have used this method in other projects to pull an otherwise dynamic value from PHP for use in client-side Javascript. (Obviously, the PHP script must confirm the logged in user matches the user ID that was passed before honoring the request.) Similar errors occur on the main SMS Relentless app page (not the settings page) for non-admin users. Failed AJAX requests are made to the following URLs: * /apps/sms_relentless/user/getsmsnumbers/%3C?php%20p($userId);%20?%3E * /apps/sms_relentless/user/cleantempdir/%3C?php%20p($userId);%20?%3E * /apps/sms_relentless/user/cleanmultrecdir/%3C?php%20p($userId);%20?%3E * /apps/sms_relentless/user/getappdirectory/%3C?php%20p($userId);%20?%3E * /apps/sms_relentless/user/getmsgsperpgnewmsgarchnb/%3C?php%20p($userId);%20?%3E * /apps/sms_relentless/user/getreceivedtable/%3C?php%20p($userId);%20?%3E * /apps/sms_relentless/user/getnewmsgindicator/%3C?php%20p($userId);%20?%3E * /apps/sms_relentless/user/getnewmsgindicator/%3C?php%20p($userId);%20?%3E Please let us know if we can assist -- we are glad to help any way we can! |
|
|
Good news! We were able to make all functions of the app work correctly for a non-admin user. Here are the steps: 1. Hardcoding `$this->userId = "[DISPLAYNAME]";` into `lib/Controller/SmsrelentlessController.php` at line 73 2. Running the SQL query INSERT INTO `oc_sms_relent_settings` (id,user_id) VALUES (2, '[DISPLAYNAME]'); 3. Reverting the change in step 1 These steps worked, but it's also possible that steps 1 and 3 weren't even necessary. If so, the only step would be to seed the table with a row that includes the new non-privileged user's ID ("id" integer) and display name ("user_id" string), so that their settings can be saved and retrieved. As soon as this was done, all settings fields were displayed properly; settings could be saved and retrieved; webhooks could be generated; and the main app's functionality mirrored that of the admin user, as expected. Since everything works despite the PHP code in the Javascript not being parsed as mentioned in note 85, maybe that isn't the issue at all (i.e. maybe that string isn't even used). To reiterate: the hard-coded `userId` in the controller is no longer in place, yet all the app's code remains unmodified and functions fine. It appears the missing row for the new non-admin user in `oc_sms_relent_settings`, or maybe the failure to create it automatically, is likely the root cause of this issue. |
|
|
Final note: In our case, we have multiple Telnyx numbers available, but only one is intended for use by the non-admin user. The field "available_numbers" in the table `oc_sms_relent_settings` was subsequently populated with the entire list for the non-admin user, irrespective of the restrictions imposed on the admin settings list (e.g. restricting all to "admin" except one). We had to manually modify the list of available numbers via SQL queries, since changing the admin settings did not impact the non-admin user's row in the `oc_sms_relent_settings` table. |
|
|
I see what you mean. Anyway, the 'oc_sms_relent_settings' must be populated automatically with the settings of the non-admin users. The current user can be obtained using 'userSession' from the 'OCP\IUserSession' class. So, I'll test tomorrow and try to publish a new version of the app. |
|
|
I've just published version 1.4.1. Please upgrade and confirm your results. |
|
|
If no response is received I'll mark this issue as solved. |
|
|
We have upgraded and everything appears to function as intended. Thank you for the follow up! |
- Anonymous
