Teacher/Student Site?

[PullJosh]

Is it possible, with UserFrosting, to create the following?: A site where people can sign up as a teacher or a student, and each teacher has a class code that students can input to become a part of the class. Students can only be in one class at a time, but they can switch classes by inputting a new code. This is a site with a learning game, so each student has their own high scores and similar types of data. Each student can see his or her own data, as well as the global high score boards. Teachers can see the same data the students can, but for all the students in his/her class.

Is this possible (preferably without getting my hands too dirty w/ php)? (Of course, I'm sure this would have something to do with groups, but I don't really have any specifics in mind beyond that.)

[alexweissman]

Yup, UF is designed exactly for this kind of thing. I'm guessing that the type of data for students will be somewhat different from the data for teachers. So, you could have all teachers and students be generic "users", and have separate groups for each. Then, you could add additional tables that store group-specific data, and link them to the main users table. Still another DB table would assign students to teachers based on their user id.

You can then use a combination of user- and group-specific authorization rules (see http://www.userfrosting.com/features.html#authorization) to define how teachers and students can interact with each other.

It will still take some PHP coding, but shouldn't be too hard to figure out. I'd start by pinning down the DB structure, then go from there.

Good luck and welcome to the UF community!

[PullJosh]

Thanks for the help! I'll try it out. :)

[nmgtn]

@alexweissman , was your suggestion here to have all the teachers and students as part of the 'users' group, and then additional groups for students in each class? So a student might be in the group 'user' and 'Class 3A', for example?

@PullJosh , how did you get on with this? Would be interested to hear about how you structured it, as I'm doing a similar thing myself.

[PullJosh]

@normington It was just a side project I was thinking about, but school ended up getting in the way and I've decided to move on to something else. I might come back to the idea some day, but for now, I'm on to something else.

[alexweissman]

@normington it is a good idea to have all of your users be members of a basic, low-permissions group. That way you have an easy way for when you just want to give blanket permissions for basic operations, say, like for a user to change their own password.

After that, you could probably solve @PullJosh's problem with just two groups - teachers and students. Then, I'd have additional tables mapping students to classes, and teachers to classes.

Let's call the students group 4. Let's say that we have an action function, viewClass:

/* Returns lectures, assignments, etc for a class */
function viewClass(class_id){
    ...

}

We could then have a permit function that checks whether or not the currently logged-in user is in a particular class:

function userInClass(class_id){
    // Check the database to see if the loggedInUser is assigned to the specified class
   ...
   // Return a boolean true or false
}

Then, if you wanted to grant permissions to students to viewClass only for the class they are in, you could add entries in your group_action_permits table like:

group_id	action	permits
4	viewClass	userInClass(class_id)

What this means is that, for any user who is a member of group 4, they will be able to viewClass for a given class_id only if they are in that class.

[nmgtn]

Thanks, @alexweissman, that sounds like a sensible way to do it. Just out of curiosity, what's the reason you suggest setting up tables to manage classes and map students/teachers to classes, which is kind of duplicating the functionality of groups already baked in to User Cake? (If you'll pardon the pun...)

Since the same user_ID can be mapped to several group_IDs in the user_group_matches table, which is already nicely set up to be managed from the frontend, I was thinking that I could add a group for each class, and student/teacher members of that class to that group (ie add an entry for each to user_group_matches. I could then add an entry to group_action_permits, similarly to your table above, but with the 'permits' using a function to check if the user is a member of that class's group, perhaps using the userInGroup function in db_functions.php?

Doing it that way wouldn't use separate tables to map teachers to classes and students to classes, which could conceivably be of some use, but in all other ways I figured it would deliver the same functionality without duplicating what is already set up for groups?

I don't mean to pick apart what you suggested, I'm just curious what the advantage of doing it the way you suggested is, or if the way I suggested is possible at all - I may have an oversimplified view and may have overlooked a flaw in my plan!

[alexweissman]

You could absolutely do it that way. However, what if you wanted to allow teachers to create new classes? Then you'd have to essentially give them permission to create/update new groups. And, you'd have to give them permission to set the permissions for those new groups.

But, I suppose you could have some code that just automatically assigns certain permissions for new "class" groups. Maybe you could have a createClass function that serves as a restricted version of createGroup.

Ultimately it's going to depend on the requirements for your system, and whether or not you will even need to allow teachers to create new classes. I generally like to think of creating/updating/deleting groups as a "site admin" function, rather than something that site users can do. Just whatever you do, be careful about granting blanket access to users, especially modifying/deleting groups.