Hello,
Problem: Any OPS user can currently unlock all release tasks due to lack of granular permissions.
Solution: Add a new "Locker/Unlocker Team" field to tasks to specify which team is authorized to unlock each task.
Benefits: Improved security, compliance, and clear ownership of unlock operations.
This enhacement is mandatory to onboard Cybersecurity teams on Release before Deploypment in production
Template as code :
Release User: DEV Team
Release Admin: OPS Team
Security: Sec Team
# Exported from: https://xlrelease.dev.echonet/
# Release version: 25.3.7-531.1600
# Date created: Tue Jun 30 15:43:18 CEST 2026
---
apiVersion: xl-release/v1
kind: Templates
metadata:
home: "~~test "
spec:
- template: Security Gate Template
scheduledStartDate: 2026-06-30T09:00:00+02:00
phases:
- phase: NON PROD
tasks:
- name: Build
type: gitlab.CreatePipeline
gitlab_server: gitlab
team: Release User
locked: true
- name: Deploy
type: ansibletower.launchAndWait
ansibletower: test
team: Release User
locked: true
- name: Go to prod by OPS
type: xlrelease.Task
team: Release Admin
locked: true
color: "#3d6c9e"
- phase: PROD
tasks:
- name: Create Change Request
type: servicenow.CreateChangeRequest
team: Security
locked: true
- name: Vulnerability SCAN
type: xlrelease.ScriptTask
locked: true
- name: Automatic GO/NO GO
type: advancedGating.Gate
team: Security
locked: true
- name: Security Decision if NO GO
type: xlrelease.Task
team: Security
locked: true
- name: Deploy
type: ansibletower.launchAndWait
ansibletower: test
team: Release User
locked: true
color: "#3d6c9e"
riskProfile: Default risk profile
author: d6
by: Mahdi S. | 26 days ago | Integrations
Comments
Thank you for the detailed example. We agree there is a gap here: folder-level lock and task transition permissions do not account for the team assigned to a specific task, so a task meant to be controlled exclusively by one team, like a security gate, can currently be unlocked or actioned by any team with folder permissions.
We are evaluating a few implementation approaches for scoping task actions to the assigned team, and want to make sure the solution also works well for related requests around restricting who can act on a specific task. We do not have a final design yet, so we are not able to commit to a version at this time. We will post an update here once we have a clearer direction, ahead of 27.1 scope planning.