| # |
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 |
| # |
Feb 19th 2009, 13:52 |
alkemann |
AD7six: 3 sets of data. revision table holds previews versions of the article. live table holds current live version, draft table holds users latest edit that has not yet been made live (and will become a revision when a new editition is pushed live) |