What it sounds like is that you would have a plugin that gave you extended permissions on posts.
You would be able to "assign" a post to a user, and while it is assigned to them, only they, and any super admins, could access and make changes. Once they are done, the post could then be assigned to the next person in line, etc. There are already plugins that allow for this workflow of assigning post objects to people, with corresponding permissions tokens. Having revisions would allow you to revert a change that User A made while they had access, for instance. On Feb 2, 2013, at 11:51 AM, Philip Buckley <[email protected]> wrote: > As an end-user rather than a developer, I must admit I don’t really > understand the significance of “in core” versus “in a core plugin”. > > I find Owen’s comparison of Revisions with Taxonomy intriguing. Taxonomy, as > I understand it, is in the abstract about how you group things (in the case > of Habari those things are posts) and Revisions, one could say, in the > abstract are about how you deal with the history of something (in the case of > Habari a post) If the logic is that taxonomy (the abstract) is in core and > concrete things can be done with it in plugins, e.g. a menus plugin or a > categories plugin, then I can see the logic of Revisions in core that can be > used via plugins to do concrete things, e.g. build a wiki or an editorial > workflow. Is that the logic? > > One thing that has been mentioned in the course of the discussion is the > potential of building an editorial workflow on Habari with Revisions. This is > something I have thought about before, and I am very excited by the > potential. What I have thought about before is an editorial workflow in a > multi-user setup, and the one fundamental thing I would need is a way to > prevent 2 people editing the same post at the same time. If I understand > correctly how Owen has implemented revisions, the revisions made by 2 people > of a post would result in each of their revised versions being stored, so one > could always go back to one or other person’s version. However, for what I > have in mind I would really need a single post that was edited by person A, > then by person B (or vice versa, by person B, then by person A), but not by > the two simultaneously. Does anyone have any thoughts how theoretically this > could be implemented? And whether it would be a difficult or easy thing to > implement? > > Philip > > > On 1 Feb 2013, at 03:12, Owen Winkler wrote: > >> Hey guys, >> >> I added core code to implement revisions in API in 0.10. The basic idea is >> that revisions are always on within core, and plugins modify or disable that >> functionality and provide the otherwise non-existent UI for it. >> >> There's a discussion going on in the issue tracker about the feature right >> now. Your opinions (reply here?) are appreciated. >> >> https://github.com/habari/habari/issues/454 >> >> Thanks! >> Owen > > > -- > -- > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/habari-dev > --- > You received this message because you are subscribed to the Google Groups > "habari-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/groups/opt_out. > > -- -- To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/habari-dev --- You received this message because you are subscribed to the Google Groups "habari-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
