You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If a user is a non-student but has been added to events via a secondary cohort group, they do not see a calendar of events for that learner view, since they have no student role in the user_x_user_role table. Similarly, if a new user is added via the admin console without any roles, evn if they are assigned to a secondary cohort they will not have access to the system, since there is not recordof them in the user_x_user_role table. While this will be obviated by the architecture of 3.0, in the meantime it is an issue.
Solution: create a stored procedure which will update the user_x_user_role table when a secondary cohort value is added to a user account.
When a secondary cohort gets selected and assigned,
test to see if any role exists for the user in the user_x_user_role table.
[1a. If there is one or more records, test for a record with a user_role_id of 4.]
If no role_id of 4 exists for the user, add a new row with a user_role_id of 4.
The text was updated successfully, but these errors were encountered:
in other words: //when adding a secondary cohort to a user from the admin panel
IF (SELECT COUNT(user_id) FROM user_x_user_role WHERE user_id = $userId AND user_role_id = 4) = 0 INSERT INTO user_x_user_role (user_id, user_role_id) VALUES ($userId, 4)
this will make a mess of the ability to identify students vs non-student learners though...
the way it is now:
If a user is a non-student but has been added to events via a secondary cohort group, they do not see a calendar of events for that learner view, since they have no student role in the user_x_user_role table. Similarly, if a new user is added via the admin console without any roles, evn if they are assigned to a secondary cohort they will not have access to the system, since there is not recordof them in the user_x_user_role table. While this will be obviated by the architecture of 3.0, in the meantime it is an issue.
Solution: create a stored procedure which will update the user_x_user_role table when a secondary cohort value is added to a user account.
When a secondary cohort gets selected and assigned,
[1a. If there is one or more records, test for a record with a user_role_id of 4.]
The text was updated successfully, but these errors were encountered: