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
Parents

  • 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. :-)

Comment

  • 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. :-)

Children
No Data