Definitly a good feature! Let's put this on the (non-existing yet) ToDo-list for 3.1.
What do the others say ? Should roles be integer or something else ? How do other tools (CMSs etc) handle this ?

I personally created some entries in the config-array with the id's of each role, so I can check it like this:

if (Session::get("user_account_type") == Config::get("ADMIN_GROUP")) {
    // access
}

But this is only good if you only got a few roles of course.

That's fine for small stuff i guess, however it doesn't really allow you to add/change or delete any roles without going in to the code, i feel like doing it this way would be a mistake.

Yes you're right, but the last part of your answer is the same with your code i guess.
If you change or delete the sales-role you need to change it everywhere in your code, too.

That's true, regardless of how you do it it's going to require editing the code unless you sort of, hmm i guess if you had a record of each controller / view in the database with the roles that are allowed to use/view then the only time you would need to manually change the roles would be when inserting it in to the database, not sure i have made this very clear, this solution would prehaps be to bloated anyhow

@ALL: I think it's a good idea to completely rebuild the AccountTypeModel stuff to RoleModel, exchanging accountType to role (as roles is the most common word in user auth systems).

maybe user groups can take an integer value from less is more privileges have, for example, the admin has a "GID" 0. Only a fuzzy idea. :D

The way I am currently implementing it in my application is rather simple. I have the Admin Users as the AccountType 1, Then I have Moderators at 2, Members at 3, etc. Then in the authcheck I added another function called groupCheck(); and how it works is I put the Lowest rank I want to be able to access that resource into the function so groupCheck(3); would be members-admin but not guest and banned users. Because the DB already has the AccountType Column it works very well and didn't require any changes to the DB.

Maybe push it into UserModel. User roles sounds like related to user so maybe that good place.

I feel like putting roles in to the UserModel is not the right thing to do, You could say that about almost everything, "sounds related to user" however putting everything in the UserModel would make it a mess. i think it should 100% be in a separate model

I've just pushed little changes to develop branch: The AccountType has now been renamed to UserRole. A super-basic role system incl. role-check will come up (feel free to do this and commit to develop branch if you like).

Do you want me to do this? have we decided on the best way to implement it?

@oisian1 Yeah! Feel free to do this, would be very cool! Please do this on develop branch and it would be awesome if you could keep it as simple and as clean as possible. Just a super-simple role system, nothing more. :)

Big thanks

Hi, I'm not a professional programer, but assumed highest user_account_type = highest rights, a very basic way to implement this could be done with the following changes:
In core/auth.php on line 12 change

public static function checkAuthentication()

to

public static function checkAuthentication($type=false)

and after the first "if" statement add:

        // if user has no permission ...
        if ($type && Session::get('user_account_type') < $type) {
            // ... add feedback
            Session::add('feedback_negative', 'You have no permission.');
            Redirect::home();
            // to prevent fetching views via cURL (which "ignores" the header-redirect above) we leave the application
            // the hard way, via exit(). @see https://github.com/panique/php-login/issues/453
            // this is not optimal and will be fixed in future releases
            exit();
        }

Now you can easily control the user permission in your controlers by writing:

Auth::checkAuthentication(2);

All users with a lower account type (role/permission) will be redirect to home, or whereever you want them to go to. What do you think?

Last time I was also looking in something like Admin and two user roles. I stumbled over this discussion: http://stackoverflow.com/questions/3213610/how-to-manage-user-roles-in-a-database
So more ore less what oisian1 was suggesting.
That would reduce the custom code. Stuff like isAdmin or IsEditor would be obsolete and it would be much easier to maintain. For each restriction you "only" would need to change the database.

@Dominic28 Hi, what you used is exactly what i am looking for. I am a bit of a noob with php, but am learning as I go along. Please could you explain to me how you implemented your code. I only use three different groups, and each one needs to see different content.

The code i am referring to is:

if (Session::get("user_account_type") == Config::get("ADMIN_GROUP")) {
// access
}

I have looked everywhere I can possibly think of but have no idea how or where you created the extra entries in the config-array. I would really appreciate some help on this.

@stealth027 Just create entries in the config-array with the id of the groups like this:
"ADMIN_GROUP" => 1, "MOD_GROUP" => 2, ...
Then you need to give user's those id's as the user_account_type and it will work.

@Dominic28 So simple... Awesome! thanks a mill. I really appreciate it.

There's now an "admin feature" in the develop branch, made in an extremly simple way. This is an external commit, so it's only partly "my" code. Basically it works like this:

Beside Auth::checkAuthentication(); we now also have Auth::checkAdminAuthentication();, checking if the user has admin rights. Currently user_account_type 1 and 2 are normal users, type 7 is an admin user. Normal controllers / methods use Auth::checkAuthentication(), controllers / methods that are only accessible by admins use Auth::checkAdminAuthentication().

I know, it's VERY simply and not very modular, but I think it's okay for simple use cases.

He guys, I'll close this ticket as this feature is partly done, and link this issue from the the new "future feature ideas" section inside the readme.

I think it's okay as this is not a real bug or so.