| # |
Feb 19th 2009, 15:05 |
ADmad |
we definately need to seperate permissions/roles from users so that specs needs to be updated anyways |
| # |
Feb 19th 2009, 15:04 |
alkemann |
i didnt know acl had a little brother. i just dont want to use a sledgehammer when a pencil is required |
| # |
Feb 19th 2009, 15:04 |
AD7six |
what about the future and extensibility for example |
| # |
Feb 19th 2009, 15:04 |
AD7six |
personally I'm very "if there's something in the core to use - use it" |
| # |
Feb 19th 2009, 15:03 |
jperras |
if the consensus is that we want to go with the one in the spec, I'm fine with that. I simply want to raise that flag. |
| # |
Feb 19th 2009, 15:02 |
jperras |
even so, I just don't get why we'd want to write something that already exists and works |
| # |
Feb 19th 2009, 15:02 |
ADmad |
but if its almost identical to ini based acl as you guys say (i have never used it) then maybe we can use that |
| # |
Feb 19th 2009, 15:01 |
ADmad |
jperras: this "whole permission system" is barely half a dozen lines of code ;) |
| # |
Feb 19th 2009, 15:01 |
alkemann |
jperras: pretty sure all the code is there in the specc. what writing do you mean? |
| # |
Feb 19th 2009, 14:59 |
jperras |
I'm just trying to prevent us from writing a whole permissions system + testing when one is available that does exactly what we want |
| # |
Feb 19th 2009, 14:59 |
markstory |
has some issues with Auth, but barring that its ninja fast. |
| # |
Feb 19th 2009, 14:58 |
markstory |
iniAcl is ninja fast. |
| # |
Feb 19th 2009, 14:58 |
jperras |
no one is saying it's bad |
| # |
Feb 19th 2009, 14:58 |
alkemann |
well gwoo ok'ed this approach so it cant be THAT bad :p |
| # |
Feb 19th 2009, 14:58 |
AD7six |
what's described on the group permissions page is basically ini based acl |
| # |
Feb 19th 2009, 14:57 |
AD7six |
ini based acl doesn't have any |
| # |
Feb 19th 2009, 14:57 |
alkemann |
yes, the queries to the acl table |
| # |
Feb 19th 2009, 14:57 |
jperras |
alkemann: price? |
| # |
Feb 19th 2009, 14:56 |
AD7six |
alkemann: as far as I understand |
| # |
Feb 19th 2009, 14:56 |
jperras |
e.g. record-based fine-grained permissions, or complex logic schemes |
| # |
Feb 19th 2009, 14:56 |
alkemann |
we dont require complex rules though, so I dont see what we gain for the price |
| # |
Feb 19th 2009, 14:56 |
AD7six |
alkemann: the intention is to use the users plugin from the book and enhance it as needed. |
| # |
Feb 19th 2009, 14:56 |
jperras |
those are usually questions because people are using acl for things it was never designed for |
| # |
Feb 19th 2009, 14:55 |
alkemann |
this is way 45% of support questions are about acl? :p |
| # |
Feb 19th 2009, 14:55 |
jperras |
I'm not pro acl at all. Often times I think it's the wrong tool for the job, and will not hesitate to say so |
| # |
Feb 19th 2009, 14:55 |
alkemann |
a user_profile that is bound to bakery sounds like an ok solution |
| # |
Feb 19th 2009, 14:55 |
AD7six |
acl isn't hard to use though, it's actually very easy |
| # |
Feb 19th 2009, 14:54 |
AD7six |
ADmad: or maybe role would be the same class as app_profile - where you'd also store "email me replies to my comments" and other settings like that. |
| # |
Feb 19th 2009, 14:54 |
alkemann |
jperras: sounds like you are very pro the ACL, so i dont know what to say other that this will be much more effective and easier to work with /shurg |
| # |
Feb 19th 2009, 14:53 |
AD7six |
ADmad: a role table in the bakery db. user_id, role (group, whatever it should be called) to be used as the lynchpin for acl or the group-finding-model otherwise |
| # |
Feb 19th 2009, 14:52 |
alkemann |
gwoo wants this app to built as a standalone and not especially made for cakephp.org though |
| # |
Feb 19th 2009, 14:52 |
jperras |
here's what I don't get alkemann: you and ADmad have spec'ed out a permissions system which is nearly identical to ACL in 'controller' authentication mode using a static config.ini file (instead of db), and you want the bakery to roll their own perms. system instead. |
| # |
Feb 19th 2009, 14:52 |
AD7six |
so user | app data needs to be seperated, and the user-group link would be on the app data side of the divide |
| # |
Feb 19th 2009, 14:52 |
ADmad |
AD7six: yes this was jotted up b4 we had that directive... what changes/alternative do you suggest |
| # |
Feb 19th 2009, 14:51 |
alkemann |
yes, i agree that this feature would be good. |
| # |
Feb 19th 2009, 14:51 |
AD7six |
whoo'ps. |
| # |
Feb 19th 2009, 14:51 |
AD7six |
and any other apps built going forwards |
| # |
Feb 19th 2009, 14:51 |
AD7six |
and any other apps that are built going forwards |
| # |
Feb 19th 2009, 14:50 |
AD7six |
the same user table is used in the book - the book's permissions are seperate and different |
| # |
Feb 19th 2009, 14:50 |
AD7six |
alkemann: you weren't here when I came in: something that I consider important is that the user data should be seperate from the apps data and logic |
| # |
Feb 19th 2009, 14:50 |
jperras |
AD7six: if Group hasMany User, where else would it be? |