Deposit List does not display in secondary admin user account after upgrade to 5.11.0 #7186
Comments
Browser console logs under secondary admin user accountfor
|
|
Just tried restoring the database from before the upgrade, once again using the built-in admin account. All seemed to go well. I then logged out and logged back in with the secondary admin account. No change. It still has the same problems. |
|
I just tried this in my local test environment starting with v5.8.0 and loaded the last db backup from the live site before upgrading it to 5.11.0. I did a manual update to 5.11.0 in the test environment and I'm able to duplicate the problems listed above. The built-in admin user is fine, but the secondary user with full admin privileges has the same issues as the live site above. I wonder... has something gone wrong with the db updating process going from 5.8.0 to 5.11.0? Everything about this secondary user worked as expected before the update. This makes no sense. I'll have to think on this some more... sleep on it... it's getting too late for my brain to function properly tonight. |
|
Ok... back in the local test env with v5.11.0, I created a new person, then used it to create a new system user with full admin privileges, just like the one that had problems after the upgrade. This new user works as it should with none of the problems listed above. So, it seems that something about our secondary admin system user was corrupted in some way during the upgrade from 5.8.0 to 5.11.0. I just can't imagine what... it doesn't look like the database upgrade sql would have done anything to that user that it wouldn't have also done to the original admin. I might have chalked this up to a freak glitch; but, it happened in both the live and test environments in exactly the same way. We do have two other full admin system user accounts, the passwords of which I changed in the test environment to see if either of them were affected in the same way. Nope... they both work as expected. It's only the one account that is the main one in use on a day-to-day basis! |
|
Ok, back in the 5.11.0 test environment, from the built-in admin account, I decided to delete the affected secondary admin system user account and re-create it using the same "person" from before. I would have thought that would clear any issue with a somehow corrupted system user account, but no! Upon logging in with the newly created account I experienced the exact same issues. Now, here's something interesting: the actual person that has been using the now borked system user admin account actually has two entries for herself in the Having discovered this, I decided to, once again, delete the affected system user account and re-create it, this time using the original "person" entry for her with the earlier I'm thinking this may be the best way to move forward; although, it bothers me that I have no explanation as to what went wrong during the upgrade. It seems like there's something about that particular Another thought: if we should delete that seemingly problematic person, how will everything that was edited by that person be affected? I know that there are many, many entries in the |
|
In my test environment, I just tried deleting the person entry that had previously been linked with the problematic system user account. After having done this, the person entries that had been added/edited by that particular I also see, directly in the database, that the So, I just ran this fix on the live site. The re-created system user linked to the original person entry seems to be working fine there now, just as it did in the test environment. While we have returned to an operational status with this workaround, there are still some nagging questions after our upgrade from v5.8.0 to v5.11.0 that remain unanswered:
|
Describe the issue
We recently upgraded from ChurchCRM v5.8.0 to v5.11.0 via the built-in upgrade process under the original admin account. That account seems to work fine; but, we seem to be having trouble with a secondary account with full admin privileges which is the primary user that interacts with CRM on a day-to-day basis. What brought this to notice was that, today, she was unable to view the list of deposits from within her account on the Deposit >> View All Deposits page.
I've not gone through the entire site; but, here are some things that I immediately took note of that are happening under her secondary admin account:
On the main dashboard at
/v2/dashboardOn the View All Deposits page at
/FindDepositSlip.php, in the "Deposits" section:Note that these problems don't seem to be happening under the built-in admin account, only the secondary account with full admin privileges is experiencing this. Before the upgrade everything had been working fine. No CRM app or slim logs were created today, only the usual auth logs. I did notice that there were errors in the browser console for the aforementioned pages under the secondary admin account that did not appear when logged into the built-in admin account. I can include those if you think that they would help. Of note in the Firefox console logs that did not appear in the Brave ones, there was an error that
window.CRM is undefined.The text was updated successfully, but these errors were encountered: