Just as the title says: How can one use the RX API to modify content type to workflow visibility? I can modify the content type to community visibility without a problem, but have reached a wall trying to figure out content type to workflow visibility (and content type to template visibility…both of which apparently don’t deal with IPSAcl as content type to community visibility does).
It appears that com.percussion.services.contentmgr.IPSContentTypeMgr has part of what I might need (method: findContentTypeWorkflowAssociations) but the object that is returned com.percussion.services.contentmgr.data.PSContentTypeWorkflow is not part of the API.
An alternate solution would be to use SQL to change the visibility but then I need some way to restart the content type, which I haven’t been able to find via the API (I haven’t looked too hard though)
Any help would be appreciated,
The content type workflow assignments are part of the content type definition. There is no public api to change them. I’m curious as to why you would want to do this programmatically.
Therefore, you can’t use SQL to change them either as the data is stored in the content type xml.
We, the IT arm of our project, resisted community-specific workflows due to the maintenance issues involved with MSM and verification procedures after an archive deployment. We maintained one workflow and three basic roles: Author, Editor, and Web_Admin. The problem with this setup is that an individual in multiple communities may get privileges on one community’s content via an unintended privilege escalation. A person who was an author in one community and an editor in another community was essentially an author AND editor in both communities’ workflows.
With 6.7, we did consider one workflow with community-specific workflow roles. However, that led to complications with workflow notifications. Eventually, we caved… and on the 1003rd day of our enterprise CMS, there were 129 workflows…
There are 54 content types. Our business rules restrict 16 content types to 2 communities with 4 workflows. 3 content types (for navigation purposes) are shared between these 2 communities and the remaining 125 workflows (and communities). 25 content types are available to these same 125 workflows (and communities). Then there are 9 content types that have very specific community/workflow assignments.
Typically, when we create a new site, that site root folder has its own community visibility. The community has its own workflow. When we use MSM to promote the site, community, and workflow, we don’t want to promote all content types and templates.
I suppose we can parse the content type XML; that’s easy enough. At least then we can quickly (and programatically) identify those content types that need to be fixed (based on our business rules) via Workbench. Manually clicking through 54 content types (Workbench > Content Design > Content Types) or 129 workflows (Workbench > System Desigh > Workflows) after every MSM deployment leaves too much room for human error.
A public API would be nice.