Tfs 使release def上下文菜单项有条件地不可见

Tfs 使release def上下文菜单项有条件地不可见,tfs,azure-devops-extensions,Tfs,Azure Devops Extensions,TFS 2018u1。我正在为发布定义构建一个带有自定义上下文菜单命令的扩展。我希望其中一些是有条件不可见的(根据当前用户的权限)。有办法把它们藏起来吗 故意不调用VSS.register()没有帮助;自定义命令仍然存在,只是不执行任何操作 这不是安全措施,而是可用性问题(菜单越来越拥挤) 编辑:在中有一个名为constraints的属性。它没有记录,不知道它来自哪里。可能是舱单。我唯一能提到的约束是在。显然,constraints是manifest JSON中的一个有效值(可能在贡献对象下),

TFS 2018u1。我正在为发布定义构建一个带有自定义上下文菜单命令的扩展。我希望其中一些是有条件不可见的(根据当前用户的权限)。有办法把它们藏起来吗

故意不调用
VSS.register()
没有帮助;自定义命令仍然存在,只是不执行任何操作

这不是安全措施,而是可用性问题(菜单越来越拥挤)

编辑:在中有一个名为
constraints
的属性。它没有记录,不知道它来自哪里。可能是舱单。我唯一能提到的约束是在。显然,
constraints
是manifest JSON中的一个有效值(可能在贡献对象下),它应该是一个数组。我们假设,
ContributionConstraint
对象之一。后者是有记录的

具有
name
属性,根据文档,该属性包含对
IContributionFilter
类的引用。我在文档和TypeScript源代码中都找不到关于这个类的任何提及。但是,在汇编
Microsoft.VisualStudio.Services.ExtensionManagement.Sdk.Server.IContributionFilter
中有一个接口
Microsoft.VisualStudio.Services.Sdk.Server.dll
,它有一个
名称
属性。
bin\Plugins\Microsoft.VisualStudio.Services.ExtensionManagement.Sdk.Plugins.dll中有派生类

  • 扩展许可证过滤器
  • 特征标志过滤器
  • LegacyFeatureEnabledFilter
  • ActiveExtensionFilter
  • 特征滤波器
  • 安全过滤器
专注于后者。名字是“安全”。看起来它支持以下属性:

  • namespaceId(GUID)-又名安全命名空间
  • namespaceToken(字符串)-安全对象标记
  • 权限(int)-位掩码,类似于ACL中的掩码
  • allowSystemContext(可选bool)-
  • serviceInstanceType(可选GUID)-仅适用于VST

如果在贡献对象下的manifest JSON中指定约束,至少它会通过TFS数据结构传播,并显示在扩展脚本的
VSS.getContribution()
下。现在,关于安全检查的细节…

贡献约束就是答案。具体而言,“安全”约束。它对TFS中的安全对象执行权限检查,如果当前用户没有所需的权限,则隐藏该命令

在我的例子中,我将使用某个代理池作为“此用户是管理员”条件的代理。在内部,池和队列上的角色分配被视为ACL。池操作的命名空间GUID为101EAE8C-1709-47F9-B228-0E476C35B3BA(“分布式任务”),令牌格式为“AgentPools/{PoolID}/”。与
使用+管理权限+管理+查看
相对应的访问掩码27是与池管理员角色相对应的掩码

约束在清单中的贡献对象下指定:

{
    "contributions": [
    {
        "id": "mycommand",
        "type": "ms.vss-web.action",
        "constraints": [
        {
            "name": "Security",
            "properties": {
                "namespaceId":"101EAE8C-1709-47F9-B228-0E476C35B3BA",
                "namespaceToken":"AgentPools/17/",
                "permission": 27
            }
        }],
        // More contribution stuff...
    }],
    // More extension stuff...
}
这种方法的缺点是我必须在扩展中硬编码池的ID该扩展是针对我们特定的TFS实例的。它对我有效,但它是一个内部扩展,我不打算发布或分发它,而且它已经依赖于我们TFS设置的细节

当然,所有这些都是完全没有记录的,随时都可能中断。但话说回来,TFS的API表面很少有文档记录


清单中还有
restrictedTo
参数,这是最近添加的,在主要贡献清单文档中没有提到。这似乎是为了限制对未经授权用户的访问,与我的情况有所不同



编辑:。除了安全性之外,还有5个约束类。

无法找到基于用户权限限制行为的方法。看来我们只能<代码>约束似乎是在
vss.d.ts
中根据本文定义的:您不能,但我可以:)