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

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

Comment

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

Children
No Data