Log message #536904

# At Username Text
# Feb 19th 2009, 15:11 alkemann and each of these apps have a separate users_profile model instead?
# Feb 19th 2009, 15:11 AD7six yes, or designed to be so.
# Feb 19th 2009, 15:11 alkemann a plugin that is installed in all cakephp.org apps?
# Feb 19th 2009, 15:11 AD7six thats a lot slimmer than the current bakery's users table
# Feb 19th 2009, 15:10 AD7six alkemann: there must be a users table, it's just not on the app side of things.
# Feb 19th 2009, 15:10 alkemann we*
# Feb 19th 2009, 15:10 alkemann have have a users table then?
# Feb 19th 2009, 15:09 AD7six afais
# Feb 19th 2009, 15:09 AD7six and.. that's all that would be needed in the users table: http://bin.cakephp.org/view/50458369
# Feb 19th 2009, 15:07 AD7six since it's currently seemingly fluid I left as is
# Feb 19th 2009, 15:07 AD7six role would be the equivalent of group_id in the spec doc
# Feb 19th 2009, 15:06 alkemann ADmad: yes
# Feb 19th 2009, 15:06 AD7six ADmad: I added this as a start point http://thechaw.com/forks/AD7six/bakery/commits/view/7bc18220ca9167ebaf4428d9eefeea5e22852561#highlight
# Feb 19th 2009, 15:06 ADmad alkemann: you only started with cake 1.2 i guess ;)
# 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