The ability to have certain content types sent to a queue when assigned to all affiliates would be beneficial, especially when dealing with Organic Groups.

The local staff admins for each subdomain could then decide which Organic Groups to enable/disable within their site.

Comments

agentrickard’s picture

Status: Active » Postponed

Interesting. I don't have time to work on this -- trying to get a stable release out.

So what the module would do is:

- On creation of certain node types:
-- Set status to unpublished
-- Allow local editors to view the unpublished nodes
-- Allow local editors to claim the unpublished nodes

This seems possible, but some workflow diagrams would be useful. I suspect that someone else may need to write this, however.

v1nce’s picture

I don't think setting the status (published or unpublished) for a node would work as this action would be set for all affiliates.

Perhaps focusing on the creation of Organic Groups may provide a better example:

A staff user creates an Organic Group from site A and sets it to be available to all affiliates. Currently, this Organic Group is automatically pushed out to all sites within the network and enabled on each site. If instead, staff users from site B and site C could navigate to an admin page that lists all the available 'global' Organic Groups, then they could select which OG's to enable or disable within their local site.

I am open to possible suggestions and will continue to look over the API for solutions. The tricky part is changing the gid from the domain_site realm and still having local staff users be able to view a listing of global groups so they can enable them within their site.

Thanks.

agentrickard’s picture

You would have to create a special page handler to account for that last bit. Some rules that say: Nodes of this type can always be seen and selected by editors with this permission.

op’s picture

I'd like to express my support this feature request. Our requirement seems identical or at least similar:

- main site editor creates page, sets it to unpublished, shares with all affiliates
- local site editor decides to publish page or not

Currently this seems handled by the decition to share a page with all or some, child sites. However this is set by the main site editor.
Local site administrators have the possibility to override this, but also to remove another child site from the list of beneficiairies of the content! So this is either too much control or too little.

One (theoretical) solution would be to udpate the DA Publishing Options section on a page for a sub-domain administrator to:
- remove the 'All affiliates' option
- display a single check box for the sub-domain

However, this would also give the local site editor the faculty to gain access to content that the main site editor had refused them, so this option may not be appropriate.

agentrickard’s picture

Local site administrators have the possibility to override this, but also to remove another child site from the list of beneficiairies of the content! So this is either too much control or too little.

Not necessarily true. Try giving your local editors the 'view domain publishing' privilege but not the 'set domain access' privilege. Then read up on how that permission is handled. This should be what you need.

----
4.2.2   Content Editing Forms

Defines how to present the forms for node creation and editing to users
who do not have permission to 'set domain access' but need some control
over where their content is published.

Users with the 'view domain publishing' permission will be subject to the
rules defined below.

  -- Pass the default form values as hidden fields
  The default option.  It will assign all content to the root domain and to
  the domain from which the form is entered.  
  
  -- Take user to the default domain
  Before being presented the editing form, users will be taken to the root
  domain.  If the node is not visible on the root domain, the user may not be 
  able to edit the node.  
  
  -- Take user to their assigned domain
  Before being presented the editing form, users will be taken to the 
  first domain assigned to their user account.  This function is most useful
  when you users are only allowed to enter content from a single domain.
  
  Note that for users who have more than one assigned domain, this option
  will take them to the first match and the user will not be allowed to 
  change the domain affiliation.
  
  -- Show user their publishing options 
  The node editing form is shown normally, and the user is presented a 
  list of checkboxes.  These options represent the affilaite domains that 
  the user is allowed to publish content to, according to the domains 
  assigned to their user account. 
  
  Note that if this option is selected, users with the 'view domain publshing'
  permission will also be shown a list of affilates to which the node is assigned.  
  This list shows only the affiliates that the user cannot edit.

Note also that the user is not given the ability to promote content to
'all affiliates'.  Users who need this ability should be given the 'set domain
access' permission instead.

----

You want Show user their publishing options . It will show them the options available to them and a list of other affiliates that they cannot edit.

agentrickard’s picture

I notice when reading that the README for permissions needs some editing, as 'set domain access' does not accureately reflact what 'vew domain publishing' does.

agentrickard’s picture

Under the scenario described in #5, you may have the problem that the local editor cannot edit the node until it is assigned to his or her domain. Two ways to fix that:

-- Give the local editor the 'edit TYPE nodes' permission according to the node types that you need to control. This would match the original feature request.

-- Assign all nodes to the primary domain and give all your local editors access to that domain plus their affiliates. Doing this would mean that a local editor could remove items from the primary domain, so be careful.

agentrickard’s picture

Status: Postponed » Closed (won't fix)

This is actually coming up again for 7.x, but we'll open a new issue.