Unfortunately you cannot avoid having to bury your head in the Authorization section of the book for a while :-)
The auth system can work at different levels. I guess most developers find a way of allocating permissions to groups. Then they put their users into those groups. The permissions work best when used as decorators for functions. For that reason you may for example decide to have separate functions for create and update, to keep your permissions (and code) clearer. You just have to think through which group can do what. It is a tricky process and depends totally on your own circumstances, so it's difficult for anyone on the list to give you specific advice. I admit I am not an expert in this, but I know enough to realise there are no shortcuts to understanding it and the book gives enough info to get things going. Best wishes, David On Feb 10, 8:39 pm, pbreit <[email protected]> wrote: > Probably true that I don't understand the auth stuff very well. Do I use > groups? Is that why each user has it's own unique group? Do I assign a write > permission for a group on a specific and thus only that logged-in-user can > edit the record? > > There's some documentation like that when using CRUD but I'm probably not > going to use CRUD since I'd like more flexibility. Would I still set it up > like that, though? > > This would seem to be the heart of any application but it's hard to figure > out how to implement (for me at least). Most of the examples I see seem to > provide any logged in user with access to everything.
