re: after our upgrade to 2.8.4, seeing this glitch: an Applicant after approval by the Admin, results in the new user having NO roles. Not even Member.
The result is that they cannot log in, they get the popup in the lower left corner: "The session could not be started"
The manual fix is to assign them to Member role after approving their application on the Applicants page.
----
Would anyone have a clue or hint about what must be broken, to not give the approved Applicant, the Member role?
Our upgrade this summer from 2.1.8 to 2.8.4 is working fine in every other respect, existing users log in and post just fine. All the Dashboard features work, etc. Only thing I could think of is that there was some other database table upgrade that I'm missing? We did update successfully the GDN tables: Role, Permission, UserRole. All that is working fine. Update and Structure ran fine.
Problems with user roles have been quite common when doing bigger upgrading steps. I remember a few discussions about that here in this forum.
Look at the roles in the dashboard and make sure you have configured a "DEFAULT TYPE" for every(!) role. That should fix the Applicants problem.
Just because you had that role issues, I would suggest to double check the role informations sanity in the database. Find out the role IDs of your current roles. They are in the table GDN_Role. Afterwards, try to find out if there are users with role IDs that are not configured. That should be relatively simple with a SQL (everything is simple if you only know how to do it, I know):
SELECT *
FROM GDN_UserRole ur
WHERE ur.RoleID NOT IN (
SELECT RoleID
FROM GDN_Role
)
If that query yields no results, everything is okay. If it shows some rows, you should delete them.
Whatever you do with the database: make a backup before you begin and nothing bad can happen.
Your next step should really be the update to version 3.1!
Thanks @R_J , the Default Type was indeed the issue. For the Member role, somehow after finishing the 2.8.4 installation, the default type for Member was set to Guest instead of Member. After changing it to Member -- then approving an Applicant, automatically promoted them to Member.
Another question on upgrading my now 2.8.4 to 3.1, related to the mandatory change in link format.
Our technical forum is over 5 years in existence, and contains many cross links on solving various issues. These cross links are mostly pointing to related discussion threads. But some of the cross links point to specific comments in other threads.
When I upgrade to 3.1, does that break all my old "...?p=..." links to other discussion threads? Example of one of the current thread links:
This particular thread is probably linked from over a dozen different subsequent threads, when users had related questions about the large millivolt values they were seeing. I'm hoping that the new link format will not break this capability. Or if it does break, there is some "re-writing" scheme that can fix things. Any tips?
Comments
Thanks so much, @R_J !!
Didn't realize the SQL would be so easy. Yes, my database is fully backed up, and these tests are happening on a staging server.
re: after our upgrade to 2.8.4, seeing this glitch: an Applicant after approval by the Admin, results in the new user having NO roles. Not even Member.
The result is that they cannot log in, they get the popup in the lower left corner: "The session could not be started"
The manual fix is to assign them to Member role after approving their application on the Applicants page.
----
Would anyone have a clue or hint about what must be broken, to not give the approved Applicant, the Member role?
Our upgrade this summer from 2.1.8 to 2.8.4 is working fine in every other respect, existing users log in and post just fine. All the Dashboard features work, etc. Only thing I could think of is that there was some other database table upgrade that I'm missing? We did update successfully the GDN tables: Role, Permission, UserRole. All that is working fine. Update and Structure ran fine.
Mentioning @R_J @charrondev .
Regards, William Croft, OpenBCI Forum
Problems with user roles have been quite common when doing bigger upgrading steps. I remember a few discussions about that here in this forum.
Look at the roles in the dashboard and make sure you have configured a "DEFAULT TYPE" for every(!) role. That should fix the Applicants problem.
Just because you had that role issues, I would suggest to double check the role informations sanity in the database. Find out the role IDs of your current roles. They are in the table GDN_Role. Afterwards, try to find out if there are users with role IDs that are not configured. That should be relatively simple with a SQL (everything is simple if you only know how to do it, I know):
If that query yields no results, everything is okay. If it shows some rows, you should delete them.
Whatever you do with the database: make a backup before you begin and nothing bad can happen.
Your next step should really be the update to version 3.1!
Thanks @R_J , the Default Type was indeed the issue. For the Member role, somehow after finishing the 2.8.4 installation, the default type for Member was set to Guest instead of Member. After changing it to Member -- then approving an Applicant, automatically promoted them to Member.
Another question on upgrading my now 2.8.4 to 3.1, related to the mandatory change in link format.
Our technical forum is over 5 years in existence, and contains many cross links on solving various issues. These cross links are mostly pointing to related discussion threads. But some of the cross links point to specific comments in other threads.
When I upgrade to 3.1, does that break all my old "...?p=..." links to other discussion threads? Example of one of the current thread links:
"https://openbci.com/forum/index.php?p=/discussion/201/large-millivolt-data-values-fbeeg-full-band-eeg"
This particular thread is probably linked from over a dozen different subsequent threads, when users had related questions about the large millivolt values they were seeing. I'm hoping that the new link format will not break this capability. Or if it does break, there is some "re-writing" scheme that can fix things. Any tips?
Regards, William Croft, OpenBCI
That will not hurt those links, all good