| # |
Feb 19th 2009, 14:46 |
jperras |
which the acl behavior supports (ini configuration instead of db config) |
| # |
Feb 19th 2009, 14:46 |
jperras |
with a static config file |
| # |
Feb 19th 2009, 14:46 |
jperras |
you're basically implementing a flat tree acl in that description |
| # |
Feb 19th 2009, 14:45 |
alkemann |
we dont need it. |
| # |
Feb 19th 2009, 14:45 |
jperras |
I don't see a reason to not use acl here |
| # |
Feb 19th 2009, 14:44 |
alkemann |
"point to a random" |
| # |
Feb 19th 2009, 14:44 |
alkemann |
as far as i am concerned, if you can find a reason to not use acl, take it. and the since we dont need to be able to point to give a random user a random right to a random asset, acl is overkill |
| # |
Feb 19th 2009, 14:44 |
jperras |
of course not. but it's already written, heavily tested, and included in the cake core |
| # |
Feb 19th 2009, 14:43 |
alkemann |
so acl is the only valid implementation of permissions? |
| # |
Feb 19th 2009, 14:43 |
jperras |
well, if it sounds like a duck, quacks like a duck, why not use a duck? |
| # |
Feb 19th 2009, 14:42 |
alkemann |
yes. permission implementations are bound to share descriptions :p |
| # |
Feb 19th 2009, 14:41 |
jperras |
control user permissions based on their group, and the controller action that they are attempting to use |
| # |
Feb 19th 2009, 14:41 |
jperras |
alkemann: that first paragraph sounds exactly like what acl does |
| # |
Feb 19th 2009, 14:40 |
alkemann |
jperras: http://thechaw.com/bakery/wiki/spec/users/Group_permissions |
| # |
Feb 19th 2009, 14:39 |
alkemann |
we arent useing acl though |
| # |
Feb 19th 2009, 14:36 |
jperras |
so if we're going all AI, great |
| # |
Feb 19th 2009, 14:35 |
jperras |
it's about mixing char(36) with int in cake's acl system |
| # |
Feb 19th 2009, 14:34 |
jperras |
it's not about being able to guess |
| # |
Feb 19th 2009, 14:34 |
alkemann |
jperras: given how we will implement permissions and that things are either public or not, i dont see any problem with "guessable" urls. ie we can just use AI for all ids |
| # |
Feb 19th 2009, 14:20 |
jperras |
as long as we're not mixing uuid and auto increments, I'm happy with that |
| # |
Feb 19th 2009, 14:18 |
alkemann |
dont see a problem using autoincrement for article id |
| # |
Feb 19th 2009, 14:18 |
AD7six |
id or a numeric sequence then. |
| # |
Feb 19th 2009, 14:17 |
markstory |
id/slug only works if you have numeric keys though. |
| # |
Feb 19th 2009, 14:17 |
AD7six |
excellenty |
| # |
Feb 19th 2009, 14:16 |
gwoo |
wfm |
| # |
Feb 19th 2009, 14:16 |
gwoo |
id/slug |
| # |
Feb 19th 2009, 14:16 |
alkemann |
making friendly urls should only go so far |
| # |
Feb 19th 2009, 14:15 |
alkemann |
i agree |
| # |
Feb 19th 2009, 14:13 |
AD7six |
one thing I'd like to ask about before I go today is how url navigation should work - I think it would be v beneficial to move from slug lookups to the same as the book (id lookups, using the slug as seo fodder) |
| # |
Feb 19th 2009, 14:09 |
gwoo |
ACTION thinks we can find some consenses |
| # |
Feb 19th 2009, 14:03 |
AD7six |
gwoo: being one of them :D |
| # |
Feb 19th 2009, 14:03 |
AD7six |
I'm not going to demand that people giving their time for free do things my way or not at all for a number of reasons :) |
| # |
Feb 19th 2009, 13:58 |
alkemann |
seeing as i already wrote both behaviors and think this is the way to go, i dont plan on implementing it another way no. but im not adamant about it. if a consensus to do it some other way can be reached |
| # |
Feb 19th 2009, 13:56 |
AD7six |
alkemann: shadow tables are usfule with massive amounts of data - I don't see the bakery fitting that need. but since you're likely to be implementing that, I can guess what's going to happen. |
| # |
Feb 19th 2009, 13:55 |
alkemann |
any changes a user does to an article page is saved in the draft table. when a moderator accept. the draft version is moved to live and the live to revision |
| # |
Feb 19th 2009, 13:55 |
AD7six |
anything else wrong/missing? |
| # |
Feb 19th 2009, 13:55 |
AD7six |
but in many regards it doesn't matter how it's implemented so long as the effect is the same |
| # |
Feb 19th 2009, 13:54 |
AD7six |
I thought the bakery logic (for edits, because that's the only time revisions are important) was user edits (submits a draft ?) moderator approves, previous version either marked as previous or deleted |
| # |
Feb 19th 2009, 13:54 |
alkemann |
this way you only access the other versions when you need to |
| # |
Feb 19th 2009, 13:53 |
alkemann |
AD7six: u could off course have it all in one table. that would just create a big one.. |
| # |
Feb 19th 2009, 13:53 |
AD7six |
alkemann: I don't follow why that necessitates 3 tables |