Сделать пункт контекстного меню Release Def условно невидимым

ТФС 2018u1. Я создаю расширение с пользовательскими командами контекстного меню для определений выпуска. Я бы хотел, чтобы некоторые из них были условно невидимыми (на правах текущего пользователя). Есть ли способ скрыть их?

Умышленное отсутствие вызова VSS.register() не помогает; пользовательские команды все еще там, просто ничего не делайте.

Это не мера безопасности, это удобство использования (меню становится тесно).

РЕДАКТИРОВАТЬ: в Структура данных вклада есть свойство под названием constraints. Это не задокументировано, я понятия не имею, откуда это взялось. Вероятно, манифест. Единственное упоминание об ограничениях, которое я смог найти, находится в исходники инструмента TFX. По-видимому, constraints является допустимым значением в манифесте JSON (вероятно, в объекте вклада), и предполагается, что это массив. Предположим, один из ContributionConstraint объектов. Последнее как бы задокументировано.

Ограничение object имеет свойство name, которое, согласно документации, содержит ссылку на класс IContributionFilter. Я не смог найти никаких упоминаний об этом классе ни в документах, ни в источниках TypeScript. Однако в сборке Microsoft.VisualStudio.Services.ExtensionManagement.Sdk.Server.dll есть интерфейс Microsoft.VisualStudio.Services.ExtensionManagement.Sdk.Server.IContributionFilter, и у него есть свойство Name. В bin\Plugins\Microsoft.VisualStudio.Services.ExtensionManagement.Sdk.Plugins.dll есть производные классы:

  • ExtensionLicensedFilter
  • FeatureFlagFilter
  • LegacyFeatureEnabledFilter
  • ActiveExtensionFilter
  • FeatureFilter
  • SecurityFilter

Концентрация на последнем. Название "Безопасность". Похоже, он поддерживает следующие свойства:

  • namespaceId (GUID) — пространство имен безопасности AKA
  • namespaceToken (string) - токен защищаемого объекта
  • разрешение (int) - битовая маска, как в ACL
  • allowSystemContext (необязательное логическое значение) - ???
  • serviceInstanceType (необязательный GUID) — имеет значение только для VSTS.

Если вы укажете ограничение в манифесте JSON под объектом вклада, по крайней мере, оно распространяется через структуры данных TFS и отображается под VSS.getContribution() в сценарии расширения. Теперь о деталях проверки безопасности...


person Seva Alekseyev    schedule 17.05.2018    source источник
comment
Не удается найти способ ограничить поведение на основе прав пользователя. Похоже, мы можем только предоставить разрешения на управление расширения. constraints кажется, определено в vss.d.ts на основе этой статьи: Ограничение вклада   -  person Andy Li-MSFT    schedule 18.05.2018
comment
Ты не можешь, а я могу :)   -  person Seva Alekseyev    schedule 18.05.2018


Ответы (1)


Ограничения вклада — вот ответ. В частности, ограничение «Безопасность». Он выполняет проверку разрешений для защищаемого объекта в TFS и скрывает команду, если текущий пользователь не имеет требуемых разрешений.

В моем случае я бы использовал определенный пул агентов в качестве прокси для условия «этот пользователь является администратором». Внутренне назначения ролей в пулах и очередях обрабатываются как списки управления доступом. GUID пространства имен для действий пула — 101EAE8C-1709-47F9-B228-0E476C35B3BA («DistributedTask»), формат токена — «AgentPools/{PoolID}/». Маска доступа 27, соответствующая Use+Administer Permissions+Manage+View, соответствует роли администратора пула.

Ограничение указано в манифесте под объектом вклада:

{
    "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...
}

Недостатком этого подхода является то, что мне приходится жестко кодировать идентификатор пула в расширении. Расширение стало специфичным для нашего конкретного экземпляра TFS. Однако оно работает для меня, это внутреннее расширение, я не планирую публиковать или распространять его, и оно уже имеет массу зависимостей от специфики. нашей настройки TFS.

Естественно, все это совершенно недокументировано и может сломаться в любой момент. Но опять же, очень мало информации о поверхности API TFS документировано.


В манифесте также есть параметр restrictedTo, который является недавним дополнением и не упоминается в основном документе манифеста вклада. Кажется, это для ограничения доступа неавторизованных пользователей, что несколько отличается от моего случая.


РЕДАКТИРОВАТЬ: я написал сообщение в блоге с дополнительной информацией. Помимо Security есть еще 5 классов ограничений.

person Seva Alekseyev    schedule 18.05.2018