Inheritance on structural workflows is an open feature request. I advise you to lodge a support ticket requesting this. The more requests, the higher the likelihood there is of it moving up the list.
Cheers, Gavin On 20 September 2012 10:22, mzjones <[email protected]> wrote: > We are having trouble setting up a structural workflow that permits a > specific group (of users) to release structural changes--andwould > appreciate any insights from the user community! > > Here's our story: > > For our overall site, we have a structural global workflow where an "A > Publishers" group is able to release structural changes throughout the > site. As a basic rule-of-thumb, there is one release level/gate for most > structural changes. > > We want to give a specific "B Publishers" group the ability to release > structural changes for a limited/single section of our site. Furthermore, > this "B Publishers" should be able to release structural changes without > further interference from the "A Publishers" group. However, we don't want > the "B Publishers" to be able to release structural workflow outside of > their designated tree section. > > Note that the "B Publishers" group is able to use (add/modify) a suite of > content classes, which can be used anywhere on the site and that include > structural elements. > We are able to make the *content* workflows align with this business > problem; but are having trouble figuring out a way to enable the structural > workflow to meet these requirements. > > Some things we've explored: > + First, there is no way to inherit a specific structural workflow. Thus, > if we manually add a "B Publishers Structural WF" to the tree element, the > workflow does not carry through when the "B Publishers" introduce a new > instance of a content class to this section of the site. And therefore, the > "A Publishers" group is required to release the new instance, as it's > governed by the gloabl structural workflow. > + Second, since the content classes are used globally, pre-assigning a > workflow would effectively provide release rights for the entire site (in > violation of our requirements). > > I supect this is a common scenario, and would sincerely appreciate any > direction re: best practice for solving this business problem! > > -- > You received this message because you are subscribed to the Google Groups > "RedDot CMS Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/reddot-cms-users/-/WgfQB99pha4J. > 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/reddot-cms-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. 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/reddot-cms-users?hl=en.
