I have to develop an application for helping students and teachers to sharing documents (homework, works, powerpoint... infact any files).
Students are divised into grade (C1, C2, C3). They can only view (on the UI) their own lesson module (ex: IT, Biology, Maths). So: each lesson module is affected to a grade. And each student belong to a grade.
Student --> Grade --> Lesson module
Teachers belong to a lesson modules. They can only add document to their own modules (mathematic's teacher can't not add docs in a biology module).
I don't know how to deal with ORMauth: I have all my tables, a test user, the loggin works well. But I don't know how to create roles / permissions.
1) How to programmatically create group? 2) How to programmatically create roles (+ association) 3) How to programmatically create permissions 4) I don't see the difference between roles / permissions 5) What is concretely an area?
As to Groups vs Roles: a group is something you belong to, a Role is a task/job you perform. You are member of the group "Project X", you have the role of "System Administrator". Some use only one, some mis-use groups for roles, and some use both. Your choice, the system provides both.
A permission is a combination of - area - permission - actions
The idea behind this is that you have distinct functional area's in your application, say "invoicing", which could contain 15 controllers with 120 actions. Within this area you could have different business functions, like "debtors", "invoices", "payment", etc. And within those you could have actions like "add", "edit", "print", "regenerate", "transfer", or whatever.
This is a functional view on permissions, not directly related or connected to code. For some, this is to abstract, or to difficult. They simply use area=controller, permission=method. And either no actions at all, or simple CRUD actions. Again, you're free to pick your own system based on your personal needs.
So your first step is to make a security design for your application, as flexible as possible. For example, I would have different permissions for "view own grade" and "view all grades", and "view own module" and "view all modules". Although you might not need these now, you don't want to recode your application later. For example, you get a teacher that teaches Bio half-time, and Science the other half? Maybe not the case now, but very likely possible in the future.
You don't, You should start with permissions, and then work your way up.
Say you have a permission "lesson.biology", with actions "view", "edit", "delete" (and maybe others). You could then create the roles "Biology Students" and "Biology Teachers", both with this permission, but with different actions (for example students have view only, while teachers may edit and delete too?).
Once this is done, you can start assigning users to roles, and when that's is done, all you need to do in your controller is to check for Auth::has_access('lesson.biology[view]'). If that returns true, give access, if it returns false give an error message (or redirect somewhere).
You can use the group to differentiate between the different grades, or to check whether the current user is a student, a teacher or an administrator.
Note that if you will have a single controller that deals with all lessons and all subjects (as I see it, this is more of a document management system?), I'm not sure that permissions are the way to go.
I'd say the subjects a student follows, and the grade the student is in, or the subject and grade a teacher is teaching, are properties of the user.
Personally I would use the role (or the group if you prefer to use is_member()) to differentiate between admin, teacher and student. And store the rest in either the user metadata or in a separate table structure (I see a many-to-many relation between subject and user, and grade and user. This will also give you the benefit to easily see which students do Maths in C3, or which teacher teaches biology in C1.
You can then use this information in your controller as a filter on the document data.
Donate
