Idea Delivered

The idea has been delivered into Tridion Sites 10 release. We have introduced new "Lock Management" right on publication. User/group with this right can check in/ undo check out on items checked out by other users.

Ability for Non-Admins to Manage Checked-out Items

When working with decentralized content producer teams, having the ability to create groups, scope on those groups, and nest permissions and rights has worked well for us. However, there seems to be some limitations around the checked-out items list and the actual unlock of the component - and who is able to perform that action.

Since only admins are able to unlock any component that is locked, and in my decentralized team scenario - if a person is Out of Office or unreachable when a content action needs to be performed in an instant where they cannot wait for their peer to return and unlock themselves - the process has been to contact the dev sustainment team to do this for them.

This creates unnecessary overhead since a ticket of some sorts will ultimately need to be generated for this to be fulfilled. So you can see the where the turnaround time and workflow of this can get into the way of the businesses editorial process and in turn time to market.

User Story:

I am a lead content producer for the platform and one of my peers is unreachable for part, half or the entire day. A component they were working on for a marketing offer that needs to be live today, is left in a locked state will now need to be unlocked by an admin.

So instead of another peer producer sitting across or easily accessible to me, I will now need to raise a high priority level ticket to have this unlock performed (same-day) and the by nature ticket is seen because of its severity to senior leadership on both the Marketing and Technology towers.

I need an easier way to unlock content without having to be an admin or contact an admin to do so.

 

Acceptance Criteria: 

I am a lead content producer that is in a group of other lead content producers, and have the ability to checked-in any item(s) checked-out by a peer lead and or subsequent producers groups. 

Andrew Ross

  • There is an interesting distinction between the ability to check in any item versus the ability to check in visible items as well as in the the scope of the right or privilege. I believe we had a similar challenge with the "scope" for Group Management Privilege (what Publications should they see).

    I think the ability to undo check out, check in, and maybe force finish workflow any items that are visible to a user with a "Unlock Privilege" would be a balanced approach for this use case.

    The ability to read any item in the system would be a useful privilege, but it's probably too powerful to combine with this idea. Otherwise regular users might be able to undo the work for items they normally wouldn't have access to such as "system" components or content from other teams.

    I'm of course not active on projects, but most of the implementations I've seen had at least a few content leads (chief editors) per team of editors for at least the internal content management group. Teams varied in size from a few dedicated authors to a few dozen distributed across an organization. I have heard of outsourced or external content editors and assume they would also have a lead of sorts that may be internal or external.

    Given a choice, I'd prefer new system Privileges over new Publication-specific Rights. In practice I'd always recommend the same Rights across all Publications in essence making them de facto privileges even before we introduced the concept. :-)

  • Thank you for your detailed feedback, Andrew. I see your point. Publication Administration right is still too coarse-grained. Configuring publication properties and checking-in items should be done by different users.

    However, just allowing checking-in items locked by other users is not enough either. At the very least, such right should include right to manage workflows: force-finish workflow process (analog of check-in action in the workflow); ability to re-assign item in workflow also seems very relevant. Users with this right should also be quite powerful and capable of reading items locked by other users (so that they know what items they change).

    Are there many lead content producers usually working on the content in a particular publication? Are they internal employees? What other rights and permissions, except check-in right, they might need to perform their work or to push the project forward?

  • I do not believe so. If I am understanding the "Administrator-level rights within a Publication (but not the right to create or delete it) | Publication Administration rights" correctly, this allows us to give admin-type privileges per publication (but what about modify or write access to the publication itself?

    I do not think, we would want a user having ability to modify publication level items. For example, change publication language codes, the ability to add/remove blueprinting to modify inheritance, or see hidden developer folders within the publication itself either.

    I could see how the user will most likely not be able to open and modify a schema from a higher publication scope then the one they are in, but they could still localized and then modify.. simply, not looking to make a subset of our users to be admins, only giving a subset of users the ability to checkin a checkout item of their peers.

    What about just a checkin group? That group can check in over top any other producer group. Maybe it is one of the ootb default groups or it could be a right like "Check-in Management" that is set per publication.

  • Andrew Ross, please confirm if the solution with Publication Administration Right fully covers your request.