2014-09-11 10:35:26
Hi. I have 2.0 installed and I'm wondering where the "roles" are defined that are used in the AT_course_enrollment table.
I'm making a modification and I want to create a new role, but I don't want to break anything. Is there a file where these live? Or would it be ok to just manually type in a new role directly into the table?
Thanks!
2014-09-11 10:54:02
There are not custom roles per se, but rather permissions. In the enrollment manager you can select a member then click the Privileges button and assign access to specific tools in a course.
There's a similar tool for admin, under User>Administrators, you can assign specific privileges on a user by user basis for admin tools.
2014-09-11 12:10:37
Right. I know about permissions.... this would be something different though.
Do you think it would break something if I manually entered a new "role" directly in the database?
2014-09-11 12:28:43
I'm not certain how you'd go about creating a role without some significant changes. Potentially the status field in the members table could have another value added. I believe it would be a little more involved than just adding a new status in the database.
Perhaps if you describe what you're trying to accomplish, I could suggest something based on current functionality.
2014-09-11 14:18:21
Sure. I do live online sessions via webconferencing and I've created a system to track attendance. The live sessions are recorded, and some users have signed up to only view the recorded sessions instead of attending live.
So, I have a simple table that displays all enrolled students. In that table, I want to NOT show those users when I update attendance.
I'm thinking that a simple call to the database would be used here. So, something like...
[php]
if($row['role'] == 'Student'){
echo '<tr><td>display_name($row['role'])</td></tr>';
}
[/php]
and I would have recording only people's role be "recorded_only" in the database.
What do you think?
2014-09-11 16:00:59
Sorry for the follow up post, but to clarify, I would just manually type in "recorded_only" or something like that for a particular user in the database.
If that would break something or just isn't a good idea in general, I'll look at another route. I have some other ideas in mind.
Thanks!
2014-09-11 17:30:35
It doesn't seem like there would be any ill side effect of doing what you suggest. If its self-contained in its own table, and there aren't any variables used that are already used elsewhere, you should be fine.