[quills-dev] [Quills Issue Tracker] New issue: #127 - does not play nicely with Intranet/Extranet Workflow
Sasha Vincic sasha.vincic at valentinewebsystems.comMon Jan 7 18:56:07 UTC 2008
- Previous message: [quills-dev] [Quills Issue Tracker] New issue: #127 - does not play nicely with Intranet/Extranet Workflow
- Next message: [quills-dev] [Quills Issue Tracker] New issue: #127 - does not play nicely with Intranet/Extranet Workflow
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 7 jan 2008, at 19.35, Derek Richardson wrote: > > Why code Quills to workflow states? Why not just have Quills obey the > visibility attributes on the underlying content items according to > standard permissions? Thus viewing a blog post, like viewing content > in other ways, could be managed by workflows written by admins. > > This opens up having blogs that display user-specific entries based on > security. That sounds nice, to me. This won't work since what you imply is the same as to remove the review_state from the query. This would return all entries that the current user is allowed to view but you probably do not want to have public drafts there? > BTW, this problem is why blogs are borken on my site, but, since all > my workflows are custom, none of the variations on 'hardcode a > workflow name' will work for me. As Kim mentioned a way to configure which states to use would probably a better way. I have vague memory that I have seen that kind of configuration somewhere in Plone or a add-on product but I can't remember where. The configuration was something about use-these-states- as-publish-states. /Sasha
- Previous message: [quills-dev] [Quills Issue Tracker] New issue: #127 - does not play nicely with Intranet/Extranet Workflow
- Next message: [quills-dev] [Quills Issue Tracker] New issue: #127 - does not play nicely with Intranet/Extranet Workflow
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the quills-dev mailing list