Page 7 of 134, showing 100 records out of 13,394 total, starting on record 601, ending on 700
| # | Username | Text | |
|---|---|---|---|
| # | Feb 19th 2009, 13:42 | AD7six | jperras: to be able to remove without deleting a rating. |
| # | Feb 19th 2009, 13:43 | AD7six | maybe not needed, it the bakery got spammed it'd be handy to not delete the info you can use to investigate with |
| # | Feb 19th 2009, 13:43 | alkemann | we may decide against using revision, but we agreed that it was better to create a drafted behavior, than use revision for something it was not intended |
| # | Feb 19th 2009, 13:43 | jperras | AD7six: I don't think we will have much use for deleting ratings |
| # | Feb 19th 2009, 13:44 | alkemann | AD7six: how does the book do drafts (ie keep old version online) |
| # | Feb 19th 2009, 13:44 | AD7six | the book revision logic is user submits a pending revision (draft), admin marks it as current or rejected. |
| # | Feb 19th 2009, 13:44 | AD7six | the act of making as current marks the 'current' revision as previous |
| # | Feb 19th 2009, 13:44 | AD7six | so there's only ever 1 |
| # | Feb 19th 2009, 13:45 | AD7six | are we missing any tables though, I would expectc for fields to me missed atm. |
| # | Feb 19th 2009, 13:46 | AD7six | what about featured - is that not going to be used anymore? |
| # | Feb 19th 2009, 13:48 | AD7six | alkemann: hence I ask about the two behaviors because the book's logic covers both. |
| # | Feb 19th 2009, 13:48 | alkemann | hasnt been a topic yet. but jperras pointed out that it has been very little used. maybe we can just give hottest stuff more realestate now that jperras is making the system better :) |
| # | Feb 19th 2009, 13:49 | alkemann | AD7six: because you are basically "hacking" a revision behavior to fulfill another function. and the publishing of a version gets in the way of having actual revisions |
| # | Feb 19th 2009, 13:49 | AD7six | naturally, I disagree |
| # | Feb 19th 2009, 13:49 | AD7six | what's the difference between a draft and a revision |
| # | Feb 19th 2009, 13:49 | AD7six | a draft is a revision |
| # | Feb 19th 2009, 13:50 | gwoo | AD7six: no |
| # | Feb 19th 2009, 13:50 | AD7six | is featured superceeded by the vote up/down logic? |
| # | Feb 19th 2009, 13:50 | gwoo | it does not become a revision until its out of draft status |
| # | Feb 19th 2009, 13:50 | alkemann | AD7six: yes. maybe the name is wrong. we are not making drafts. author is publishing it, but we are moderating that publishing |
| # | Feb 19th 2009, 13:50 | AD7six | gwoo: I don't understand what you mean |
| # | Feb 19th 2009, 13:51 | gwoo | if we are to have true drafts |
| # | Feb 19th 2009, 13:51 | gwoo | otherwise its just on hold for moderation |
| # | Feb 19th 2009, 13:51 | gwoo | and that would be a revision |
| # | Feb 19th 2009, 13:51 | AD7six | gwoo: when you say revision - are you attaching additioanl meaning such as "revisions are visible to others"? |
| # | Feb 19th 2009, 13:51 | gwoo | yes |
| # | Feb 19th 2009, 13:51 | AD7six | I'm only talking about the data in the db |
| # | Feb 19th 2009, 13:52 | AD7six | articles have a status flag for draft, pending, published, rejected |
| # | Feb 19th 2009, 13:52 | gwoo | so pages |
| # | 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) |
| # | Feb 19th 2009, 13:53 | AD7six | alkemann: I don't follow why that necessitates 3 tables |
| # | 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:54 | alkemann | this way you only access the other versions when you need to |
| # | 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: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:55 | AD7six | anything else wrong/missing? |
| # | 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: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: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, 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, 14:03 | AD7six | gwoo: being one of them :D |
| # | Feb 19th 2009, 14:09 | gwoo | ACTION thinks we can find some consenses |
| # | 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:15 | alkemann | i agree |
| # | Feb 19th 2009, 14:16 | alkemann | making friendly urls should only go so far |
| # | Feb 19th 2009, 14:16 | gwoo | id/slug |
| # | Feb 19th 2009, 14:16 | gwoo | wfm |
| # | Feb 19th 2009, 14:17 | AD7six | excellenty |
| # | Feb 19th 2009, 14:17 | markstory | id/slug only works if you have numeric keys though. |
| # | Feb 19th 2009, 14:18 | AD7six | id or a numeric sequence then. |
| # | Feb 19th 2009, 14:18 | alkemann | dont see a problem using autoincrement for article id |
| # | 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: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:34 | jperras | it's not about being able to guess |
| # | Feb 19th 2009, 14:35 | jperras | it's about mixing char(36) with int in cake's acl system |
| # | Feb 19th 2009, 14:36 | jperras | so if we're going all AI, great |
| # | Feb 19th 2009, 14:39 | alkemann | we arent useing acl though |
| # | Feb 19th 2009, 14:40 | alkemann | jperras: http://thechaw.com/bakery/wiki/spec/users/Group_permissions |
| # | Feb 19th 2009, 14:41 | jperras | alkemann: that first paragraph sounds exactly like what acl does |
| # | 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:42 | alkemann | yes. permission implementations are bound to share descriptions :p |
| # | 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:43 | alkemann | so acl is the only valid implementation of permissions? |
| # | 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: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 | alkemann | "point to a random" |
| # | Feb 19th 2009, 14:45 | jperras | I don't see a reason to not use acl here |
| # | Feb 19th 2009, 14:45 | alkemann | we dont need it. |
| # | Feb 19th 2009, 14:46 | jperras | you're basically implementing a flat tree acl in that description |
| # | Feb 19th 2009, 14:46 | jperras | with a static config file |
| # | Feb 19th 2009, 14:46 | jperras | which the acl behavior supports (ini configuration instead of db config) |
| # | Feb 19th 2009, 14:46 | AD7six | alkemann: what solution would you suggest |
| # | Feb 19th 2009, 14:47 | alkemann | AD7six: the we have specced already |
| # | Feb 19th 2009, 14:47 | alkemann | the one* |
| # | Feb 19th 2009, 14:47 | AD7six | I don't see where it says how you're going to store and query permissions? |
| # | Feb 19th 2009, 14:48 | AD7six | I see a description of permissions |
| # | Feb 19th 2009, 14:48 | alkemann | http://thechaw.com/bakery/wiki/spec/users/Group_permissions |
| # | Feb 19th 2009, 14:48 | jperras | bottom of the wiki page, AD7six |
| # | Feb 19th 2009, 14:49 | AD7six | oo don't like that so much ;) |
| # | Feb 19th 2009, 14:49 | AD7six | for one the group_id field is in the users table |
| # | Feb 19th 2009, 14:49 | alkemann | yes. important part of the solution |
| # | Feb 19th 2009, 14:50 | jperras | AD7six: if Group hasMany User, where else would it be? |
| # | 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 | AD7six | the same user table is used in the book - the book's permissions are seperate and different |
| # | Feb 19th 2009, 14:51 | AD7six | and any other apps that are built going forwards |
| # | Feb 19th 2009, 14:51 | AD7six | and any other apps built going forwards |
| # | Feb 19th 2009, 14:51 | AD7six | whoo'ps. |
| # | Feb 19th 2009, 14:51 | alkemann | yes, i agree that this feature would be good. |
| # | 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: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 | 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 | alkemann | gwoo wants this app to built as a standalone and not especially made for cakephp.org though |
| # | 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: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: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:55 | AD7six | acl isn't hard to use though, it's actually very easy |
| # | Feb 19th 2009, 14:55 | alkemann | a user_profile that is bound to bakery sounds like an ok solution |
| # | 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 | this is way 45% of support questions are about acl? :p |
| # | Feb 19th 2009, 14:56 | jperras | those are usually questions because people are using acl for things it was never designed for |