[eluser]Ben Edmunds[/eluser]
Thanks w1ntermut3, I received the Github issues and will get to them as soon as I can.
Here are my replies to your post:
ion_auth->groups() - the documentation says it returns array of objects: it actually returns the query object, same as the other listing functions. Usage note should probably reflect this:
ion_auth->groups()->result();
Yep, the docs definitely need to be updated for this, if you could send a pull request on github for things like this that you find it would be very helpful.
ion_auth->is_admin() and ion_auth->in_group() only work for the logged-in user. Surely these should take an optional user object or ID? It’d be useful if they did, in any case.
This already existed for in_group but is not documented I add this to is_admin() and documented for both methods. Thanks!
User editing - The update() function is there, via the model* - but there’s no edit view/controller. I appreciate this is primarily an auth library, but it’s got views for everything except editing your account details. Seems an odd ommision.
Very true and something we need to add. Send a pull request if you can or I'll add it when I get a chance.
Views - the supplied views contain contain unnecessary markup. What’s the point of leaving that “mainInfo” and “pageTitleBorder” stuff in there?
The views are very basic code I pulled out of another project. I just pushed a commit to clean them up a bit.
User fields - I appreciate that they’re common fields, but I don’t think the library by default should manage any more user data than that which it requires to function. Stuff like concatenating phone numbers, storing a company name - those are application-specific considerations that should be outside the scope of the default library implementation.
I get what your saying but I have them in there because they are very common and they are a good example of how to add fields. You'd be surprised how many times a week I have to help someone add fields and this gives them a very quick reference.
* Controller/Model functions: If the function isn’t defined in the controller, pass it off to the model? This seems a very odd thing to do. Is it a common pattern? What’s the rationale? Makes it harder to know where to find the function you’re looking for.
The controller methods aren't passed to the model, just the library methods. It's not all that common in CI code but it gives you a very clean way to keep the data specific methods separated in the model and gives you the ability to extend the model methods using the library.
