Как да персонализирате проект в HP ALM (Център за качество)

⚡ Умно обобщение

Персонализирането на проект в HP ALM позволява на администратора на проекта да контролира кой има достъп до проекта и какво може да прави всеки човек в него. Тази статия разглежда потребителските свойства, потребителите на проекта, групите и разрешенията, достъпа до модули, обектите на проекта, списъците, автоматичната поща, правилата за предупреждения, работния процес и редактора на скриптове.

  • 🔐 Контрол на достъпа: Потребителите на проекта добавят или премахват акаунти, а „Групи и разрешения“ решават какво може да създава, актуализира или изтрива всяка група.
  • 👁️ Правило по подразбиране: Всеки новодобавен потребител започва в групата „Зрител“ с права само за четене, докато администратор не промени членството.
  • 🚫 Предварително дефинирани групи: Петте вградени групи не могат да бъдат преименувани, изтривани или редактирани, така че трябва да се създаде персонализирана група, за да се променят разрешенията.
  • 🧱 Персонализирани полета: „Проектни обекти“ добавя потребителски дефинирани полета, докато системните полета остават само за четене и не могат да бъдат премахнати.
  • 📋 Списъци с проекти: Списъците предоставят избираемите стойности зад полета, като например „Състояние на грешката“, а новите елементи се появяват веднага в модула „Дефекти“.
  • 📧 Уведомително писмо: Автоматичната поща изпраща имейли на потребителите, когато избраните полета за дефекти се променят, а правилата за предупреждения обхващат изискванията и свързаните с тях тестове.
  • 📝 Редактор на скриптове: SetFieldApp контролира видимостта на полетата, задължителния статус, номера на страницата и реда на показване за всяка потребителска група.

Персонализиране на проект в HP ALM

Какво е персонализиране на проекти в HP ALM?

  • Персонализирането на проекти позволява на администраторите на проекти да контролират достъпа до проекта, като дефинират потребителите, които имат достъп до проекта, а също така има възможности за персонализиране на типа задачи, които всеки потребител може да изпълнява.
  • Можете също така да персонализирате проект, за да отговаря на специфичните изисквания на вашата организация.
  • Също така помага при добавянето и редактирането на нови персонализирани потребителски полета, които могат да бъдат добавени към всеки един от модулите в ALM.

Персонализацията се постига от Инструменти> Персонализиране в рамките на проект и е отделно от „Администриране на сайта“. „Администриране на сайта“ създава домейни, проекти и потребители на ниво сайт, докато „Персонализиране на проекта“ решава какво могат да правят тези потребители, след като са в рамките на определен проект.

Прозорецът за персонализиране на проекта е разделен на областите, изброени по-долу. Нека ги разгледаме една по една.

Зона за персонализиране Какво контролира
Потребителски свойства Данните за профила и паролата на влезлия потребител
Потребители на проекта Кои акаунти принадлежат към този проект
Групи и разрешения Какво може да създава, актуализира или изтрива всяка група
Достъп до модула Кои модули може да вижда всяка група
Субекти на проекта Системни и потребителски дефинирани полета за всеки обект
Списъци с проекти Избираемите стойности зад списъчните полета
Автоматична поща Известие по имейл за промени в полетата за дефекти
Правила за предупреждение Сигнали за различни изисквания, тестове и дефекти
Редактор на работен процес и скриптове Оформление на диалоговия прозорец и разрешени действия за всяка група

💡 Съвет: Продуктът на тези екранни снимки е сменял собственика си повече от веднъж. Започна като HP Quality Center, стана HPE, а след това Micro Focus ALM, а сега се издава от OpenText като ALM / Център за качество. Екраните за персонализиране и моделът на скриптове за работен процес, описани тук, остават същите.

Потребителски свойства

Потребителят, който е влязъл в профила си, може да редактира данните на собствения си профил, а страницата му позволява и да промени паролата си.

ЗабележкаСамо паролата на текущо вписания потребител може да бъде променена тук, дори ако потребителят е от тип „Администратор на проект“.

Стъпка 1) Кликнете върху връзката „Инструменти“ и изберете „Персонализиране“, както е показано по-долу.

Потребителски свойства

Стъпка 2) Показва се диалоговият прозорец за персонализиране на проекта, както е показано по-долу.

Потребителски свойства

Стъпка 3) За да промените паролата на текущия потребител, щракнете върху „Промяна на паролата“ в раздела „Свойства на потребителя“.

Потребителски свойства

Стъпка 4) Отваря се диалоговият прозорец за промяна на паролата.

  1. Въведете стара парола
  2. Въведете нова парола
  3. Въведете Потвърждаване на паролата
  4. Щракнете върху „OK“

Потребителски свойства

Стъпка 5) На потребителя ще бъде показано съобщението за състоянието.

Потребителски свойства

Стъпка 6) Потребителят може също да редактира следните данни за профила.

  1. Имейл ID
  2. Пълно име
  3. Телефонен номер
  4. Кликнете върху „Запазване“

Забележка: Потребителите няма да могат да редактират потребителското си име, дори ако потребителят е от тип „Администратор на проект“.

Потребителски свойства

Стъпка 7) Статусът се показва на потребителя, както е показано по-долу.

Потребителски свойства

Потребители на проекта

Този модул позволява на потребителите да добавят и премахват потребители за текущия ALM проект. Можете също така да присвоявате потребители на потребителски групи, за да ограничите правата им за достъп.

Стъпка 1) Сега нека добавим потребители към областта „Проект“.

  1. Отидете до Потребители на проекта
  2. Щракнете върху падащото меню „Добавяне на потребител“.

Потребители на проекта

Стъпка 2) След като щракнете върху падащото меню „Добавяне на потребител“, на потребителя се показват следните методи, както е показано по-долу.

  1. Добавете потребител по име – Администраторът на проекта може да добави съществуващ ALM потребител към този проект, като предостави потребителското му име.
  2. Добавете нов потребител към сайта – Добавете нов потребител към сайта, като въведете всички данни, по същия начин, по който потребителите се добавят от „Администрация на сайта“.
  3. Добавете потребители от сайта – Добавете съществуващ потребител, като потърсите по неговото име или ID.

Нека разгледаме всеки един от тези методи.

Потребители на проекта

Стъпка 3) Нека добавим потребител въз основа на име. Уверете се, че този потребител вече съществува в базата данни за администратор на ALM, т.е. потребител, създаден с помощта на Модул за администриране на сайта.

  1. Изберете „Потребители на проекта“ от прозореца „Персонализиране на проекта“.
  2. Кликнете върху „Добавяне на потребител“
  3. Въведете потребителско име
  4. Щракнете върху „OK“

Потребители на проекта

Стъпка 4) Добавеният потребител се показва, както е показано по-долу.

Потребители на проекта

Стъпка 5) Сега нека добавим потребител, използвайки опцията „Добавяне на нов потребител към сайта“.

Потребители на проекта

Стъпка 6) След като щракнете върху „Добавяне на нов потребител към сайта“ от „Добавяне на потребител“, се показва следният диалогов прозорец.

  1. Въведете потребителско име
  2. Въведете Email
  3. Въведете пълно име
  4. Въведете телефонен номер
  5. Щракнете върху „OK“

Потребители на проекта

Стъпка 7) Потребителят вече е добавен към текущия проект. Той се показва в „Потребители на проекта“, както е показано по-долу.

Потребители на проекта

Стъпка 8) Сега нека добавим потребители на проекта, използвайки опцията „Добавяне на потребители от сайта“. Уверете се, че потребителят вече е в базата данни за администратор на ALM.

Потребители на проекта

Стъпка 9) Показва се следният диалогов прозорец.

  1. Въведете потребителското име и щракнете върху иконата за търсене
  2. Показва се потребителското име
  3. Щракнете върху „OK“

Потребители на проекта

Стъпка 10) Потребителят е добавен към проекта и се показва, както е показано по-долу.

Потребители на проекта

Стъпка 11) Администраторът на проекта може също да премахне потребител от модула „Потребители на проекта“.

  1. Изберете потребителя
  2. Кликнете върху „Премахване на потребител“

Потребители на проекта

Стъпка 12) Показва се диалогов прозорец за потвърждение. Кликнете върху „Да“.

Потребители на проекта

Стъпка 13) След щракване върху „Да“ потребителят се премахва от списъка с потребители на проекта.

Потребители на проекта

Стъпка 14) Всеки потребител в „Потребители на проекта“ има свързано с него членство.

Забележка: По подразбиране всеки добавен потребител има само разрешения за „Преглед“.

  1. Изберете потребителско име
  2. Изберете раздела „Членство“
  3. Показва се членството за избрания потребител. Новодобавеният потребител „Кати“ има разрешение за „Преглеждане“.

Потребители на проекта

Групи и разрешения

Този модул позволява на администратора на проекта да присвоява привилегии на потребителски групи, като задава разрешения.

В ALM има 5 предварително дефинирани групи и всяка от тези потребителски групи има различно ниво на разрешения.

  1. Софтуерен Инженер
  2. Ръководител на проекта
  3. QA тестер
  4. TD Admin
  5. Viewer

Забележка: По подразбиране всеки потребител, добавен към областта на проекта, има само разрешение за „Преглед“.

Стъпка 1) Нека видим списъка с потребители в групата „TDAdmin“.

  1. Изберете „TDAdmin“
  2. В раздела „Членство“ ще видите потребители, които не са в групата
  3. В секцията „В групата“ ще видите списъка с потребителите в групата. В този случай се показва само „Администратор“.

Групи и разрешения

Стъпка 2) Предварително дефинираните групови разрешения не могат да бъдат редактирани.

  1. Изберете „TDAdmin“
  2. Отидете до раздела „Разрешения“
  3. Изберете произволен модул (в този случай Дефекти)
  4. Разрешенията не могат да бъдат редактирани, дори ако текущият потребител е администратор на проекта.

Групи и разрешения

Стъпка 3) Предварително дефинираните групи не могат да бъдат преименувани или изтривани.

Групи и разрешения

Стъпка 4) За да промени разрешението на група, администраторът на проекта трябва да добави нова група. Да кажем, че трябва да създадем нова потребителска група, чиито членове имат разрешение за „Редактиране“ за модула „Дефекти“ и разрешение за преглед за всичко останало. Това означава, че всички разрешения трябва да са същите като на потребител с право на „Преглед“, с изключение на това, че потребителят трябва да може да актуализира дефекти. За да направите това,

  1. Кликнете върху „Нова група“
  2. На потребителя се показва диалогов прозорец за потвърждение. Кликнете върху „Да“.

Групи и разрешения

Стъпка 5) След като щракнете върху „Да“, се показва диалоговият прозорец „Нова група“.

  1. Въведете името на групата
  2. Въведете профила, на който трябва да се базира

Групи и разрешения

Стъпка 6) Потребителската група е създадена, както е показано по-долу. Можете също да видите, че можем да преименуваме или изтрием тази група, тъй като тя е създадена от нас. Предварително дефинираните групи в ALM не могат да бъдат редактирани или изтривани.

Групи и разрешения

Стъпка 7) За да промените разрешението,

  1. Отидете до раздела „Разрешения“
  2. Кликнете върху раздела „Дефекти“
  3. Активиране на флага „Актуализация“ за дефекти
  4. Активиране на флага „Актуализиране“ за връзки

Групи и разрешения

Достъп до модула

Този модул позволява на администраторите на проекти да контролират модулите, до които всяка потребителска група има достъп. Това предотвратява достъпа на потребителите до ограничени модули.

Да кажем, че разработчиците нямат нищо общо с тестовите случаи. Следователно, те могат да бъдат лишени от достъп до План за тестване намлява Тестова лаборатория модули.

Стъпка 1) Достъпът до модулите по подразбиране е показан по-долу. Всички потребителски групи имат достъп до всички модули по подразбиране.

Достъп до модула

Стъпка 2) За демонстрационни цели, нека премахнем целия достъп до модули от потребител тип VIEW, с изключение на модула Defects. Махнете отметката от всички квадратчета за достъп до модули до потребителя View, с изключение на Defects, както е показано по-долу.

Достъп до модула

Стъпка 3) Сега нека влезем, използвайки един от потребителските идентификатори „View“, за да проверим дали промените са приложени правилно. От снимката по-долу е видно, че настройките са приложени по предназначение, защото за потребителя на изгледа „Jim“ се показва само модулът „Defects“.

Достъп до модула

⚠️ Предупреждение: Достъпът до модули и разрешенията за групи са два различни контрола. Премахването на достъпа до модули скрива модула от менюто, но само по себе си не отменя съответните разрешения. Задайте и двете, когато ограничавате група.

Субекти на проекта

  • Проектните обекти позволяват на администраторите на проекти да променят поведението на полетата на ALM системата или да дефинират потребителски дефинирани полета.
  • Например, ако изпълняваме тестове на различни компилации и бихме искали да добавим поле „Версия на компилация“ в модула „Добавяне на дефект“, можем да го направим, използвайки модула „Проектни обекти“.

Стъпка 1) Потребителски дефинирани полета не могат да се добавят към системните полета, които са само за четене.

  1. Изберете „Проектни обекти“
  2. Изберете „Дефект“ и след това подпапката „Системни полета“.
  3. Обърнете внимание, че няма да можем да добавяме „Ново поле“ или да изтриваме такова, защото системните полета са само за четене.

Субекти на проекта

Стъпка 2) За да добавите дефинирано от потребителя поле,

  1. Изберете подпапката „Потребителски полета“ в модула „Дефекти“.
  2. Кликнете върху „Ново поле“
  3. Детайлите на полето се показват, както е показано по-долу, и могат да бъдат редактирани.

Субекти на проекта

Стъпка 3) Подробностите за полето също могат да се редактират, както е показано по-долу.

  1. Преименувайте етикета на „Номер на сборка“.
  2. Отбележете „Задължително“, което означава, че това поле става задължително при публикуване на нов дефект.
  3. Кликнете върху Запазване

Субекти на проекта

Стъпка 4) Сега можем да видим промяната в модула „Дефекти“. Отидете до модула „Дефекти“ и потребителят ще види новосъздаденото поле „Номер на сборка“ като част от диалоговия прозорец „Нов дефект“.

Субекти на проекта

Списъци с проекти

  • Списъците с проекти позволяват на администраторите на проекти да добавят персонализирани списъци към проект. Списъкът съдържа стойности, които потребителят може да въведе в системни или потребителски дефинирани полета.
  • Например, списъкът със статуси на грешки има шест предварително дефинирани статуса, а именно Нов, Отворен, Поправен, Повторно отворен, Затворен и Отхвърлен. Ако искаме да добавим още един статус, например Дубликат, можем да го направим с помощта на този модул.

Стъпка 1) За да добавите елемент от предварително дефиниран списък,

  1. Кликнете върху „Списъци с проекти“
  2. Изберете „Състояние на грешка“
  3. Щракнете върху „Нов елемент“. Отваря се диалоговият прозорец „Нов елемент“.
  4. Въведете името на елемента.
  5. Щракнете върху „OK“

Списъци с проекти

Стъпка 2) След като щракнете върху OK, новият елемент се създава, както е показано по-долу.

Списъци с проекти

Стъпка 3) Сега трябва да запазим промените.

  1. Кликнете върху бутона „Запазване“.
  2. Показва се изскачащ прозорец. Кликнете върху „OK“.

Списъци с проекти

Стъпка 4) Сега отидете до модула „Дефекти“ и проверете дали полето за статус съдържа новодобавения елемент. Добавянето на статус също влияе на жизнен цикъл на дефекта, така че съгласувайте новата стойност с екипа, преди да я въведете.

Списъци с проекти

Автоматична поща

Този модул позволява на администраторите на проекти да настройват правила за автоматично уведомяване по имейл, за да уведомяват потребителите по имейл за промени, направени по определени дефекти. Функцията за автоматично изпращане по имейл е достъпна само за модула „Дефекти“.

Стъпка 1) За да активирате автоматичните известия по имейл, изпълнете следните стъпки.

  1. Отидете до връзката „Автоматична поща“.
  2. Потребителят може да задейства имейл, като избере произволен брой налични полета в списъка.
  3. Тази таблица показва списъка с полета, за които потребителят е избрал да му изпраща имейл.
  4. Администраторът на проекта може също да избере настройките за имейл за всеки наличен потребител.
  5. Щракнете върху „Запазване“.

Автоматична поща

Стъпка 2) Показва се изскачащ прозорец. Щракнете върху OK.

Автоматична поща

Правила за предупреждение

Този модул позволява на администраторите на проекти да активират правила за предупреждения за текущия проект. Тази функция създава предупреждения и изпраща имейли, когато настъпят промени в проекта. Тя се отнася за изисквания, свързани тестове и дефекти.

Стъпка 1) За да активирате правилата за предупреждения,

  1. Отидете до „Правила за предупреждения“.
  2. Поставете отметка в квадратчето „Предупреждение, свързано с“
  3. Активирайте „Изпращане на имейл до“ и добавете съответния тестер или дизайнер.
  4. Кликнете върху „Запазване“

Правила за предупреждение

  • Първо предупреждение: дизайнерът на тестове бива предупреждаван, когато изискване е модифициран, така че свързаните тестове да могат да бъдат актуализирани.
  • Второ предупреждение: тестерът бива предупреден, когато дефект променя статуса си на „Поправен“, така че отговорният тестер да може да го вземе отново за повторно тестване.

Workflow

  • Този модул позволява на администраторите на проекти да генерират скриптове, които помагат за персонализирането на модула „Дефекти“, т.е. диалоговия прозорец „Добавяне на дефект“ или диалоговия прозорец „Преглед на дефект“.
  • С помощта на този модул, администраторите на проекти могат също да пишат скриптове за персонализиране на диалогови прозорци в други модули и да контролират действията, които потребителите могат да извършват.

Сега нека персонализираме диалоговия прозорец „Добавяне на дефект“ за потребителския тип група „TDAdmin“.

Стъпка 1) Под „Персонализиране на проекта“,

  1. Кликнете върху „Работен процес“.
  2. Изберете „Скрипт“ Generator – Добавяне на връзка „Персонализиране на полето за дефекти“

Workflow

Стъпка 2) Отваря се диалоговият прозорец за персонализиране на полето „Добавяне на дефект“.

  1. Изберете потребителската група.
  2. Изберете полетата, които не искате да се показват в диалоговия прозорец „Добавяне на дефект“.
  3. Щракнете върху връзката „<“, за да изместите полетата от списъка с видими полета.

Забележка: Задължителните полета не могат да бъдат преместени извън списъка с видими полета.

Workflow

Стъпка 3) След като премахнете всички неподходящи полета от списъка с видими полета, диалоговият прозорец за персонализиране се показва, както е показано по-долу.

  1. Полетата, които са изместени от списъка с видими полета.
  2. Полетата, които ще бъдат част от диалоговия прозорец „Добавяне на дефект“.
  3. Приложете промените в скрипта.

Workflow

Забележка: Въпреки че персонализирахме това чрез потребителския интерфейс, промените се прилагат чрез генериране на скриптове във фонов режим. Ще разгледаме и редактирането на скриптове чрез пример в следващия раздел.

Стъпка 4) Сега влезте като потребител от тип „TDAdmin“ и щракнете върху „Нов дефект“ от модула „Дефекти“. Полетата, избрани като видими, се показват в прозореца „Нов дефект“.

Workflow

Редактор на скриптове

Редакторът на скриптове помага на потребителите да пишат скриптове за персонализиране на диалогови прозорци в различните модули и за контрол на действията, които потребителите могат да извършват във всеки модул.

Нека променим начина, по който диалоговият прозорец „Преглед на дефекта“ се показва на потребителя с помощта на редактора на скриптове.

Стъпка 1) За да получите достъп до редактора на скриптове,

  1. Отидете до раздела „Работен процес“
  2. Кликнете върху „Редактор на скриптове“.

Редактор на скриптове

Стъпка 2) Редакторът на скриптове се показва на потребителя, както е показано по-долу.

  1. Изберете „Скрипт на модул за дефекти“
  2. Коментарът показва областта, където трябва да направим промени, защото изрично е посочено „персонализиране на полето за подробности за дефекта“.
  3. Скриптира се отделно за всяка потребителска група. Блокът, който разглеждаме, съответства на потребителската група „Разработчик“. Трябва да направим промени в потребителската група „TDAdmin“.

Редактор на скриптове

Стъпка 3) Сега превъртете надолу до потребителската група „TDAdmin“, където трябва да направим промени. Текущите настройки за „TDAdmin“ са показани, както е показано по-долу.

Редактор на скриптове

Стъпка 4) Нека разберем скрипта. Разгледайте следния ред код:

SetFieldApp "BG_ACTUAL_FIX_TIME", True, False, 0, 0

Ето и подробностите:

Параметър Значение
SetFieldApp Извикването на функция, направено с 5 параметъра
Име на полето BG_ACTUAL_FIX_TIME – името на полето, чиито настройки ще променим
Видим флаг Ако е True, полето ще бъде видимо.
Задължителен флаг Проверява дали полето е задължително. Ако е True, полето е задължително.
Флаг № на страница Започва с 0. Ако има много полета, те могат да бъдат конфигурирани да се показват страница по страница.
ViewOrder Задава реда на полето. Започва с 0 и се увеличава с 1.

Стъпка 5) Нека направим промени в първото поле, „BG_ACTUAL_FIX_TIME“. Скриптът за това поле в редактора на скриптове е показан по-долу.

SetFieldApp "BG_ACTUAL_FIX_TIME", True, False, 0, 0

С горния скрипт, диалоговият прозорец „Подробности за дефекта“ се показва на потребителя, както е показано по-долу.

Редактор на скриптове

Редактирайте този ред от код, както е показано по-долу.

SetFieldApp "BG_ACTUAL_FIX_TIME", False, False, 0, 16

Задаването на флага „visible“ на „False“ скрива полето. Изходът от скрипта се отразява в диалоговия прозорец „Defect Details“, както е показано по-долу.

Редактор на скриптове

Стъпка 6) Нека направим промени във всички налични полета.

  1. Променете параметрите на извикванията на функции, както е обяснено в предишната стъпка за всяко поле, както е показано по-долу.
  2. Щракнете върху „Запазване“.

Редактор на скриптове

Стъпка 7) Сега влезте като потребител от тип „TDAdmin“ и отворете един от дефектите, така че да се отвори диалоговият прозорец „Преглед на подробности за дефекта“. Диалоговият прозорец сега се показва, както е показано по-долу.

Редактор на скриптове

Най-добри практики за персонализиране на HP ALM проекти

Персонализирането е лесно за започване и трудно за отмяна, така че няколко навика спестяват значителна преработка по-късно.

  1. Никога не редактирайте първо активен проект. Приложете промените в копие на проекта, потвърдете ги и едва след това повторете промяната в продукцията.
  2. Създавайте персонализирани групи, вместо да се борите с предварително зададените. Създайте нова група на базата на най-близкия предварително дефиниран профил и коригирайте само разрешенията, които трябва да се различават.
  3. Сведете до минимум дефинираните от потребителя полета. Всяко допълнително задължително поле забавя регистрирането на дефекти и често се оставя с безсмислена стойност по подразбиране.
  4. Коментирайте всяка промяна в скрипта на работния процес. Редакторът на скриптове съдържа по един дълъг файл на модул и е трудно да се направи некоментирана редакция. tracе месеца по-късно.
  5. Архивирайте скрипта на работния процес, преди да го редактирате. Копирайте съществуващия скрипт в текстов файл, защото в редактора няма история на версиите.
  6. Тествайте с реален акаунт от всяка група. Разрешенията често се държат различно от това, което предлага мрежата с квадратчета за отметка.

За да продължите с администрирането на HP ALM, прочетете как да създадете домейн, проект и потребител в Администрацията на сайта, Въведение в HP ALMи пълното Урок за HP ALMЗа модулите, засегнати от тези настройки, вижте изисквания, план за изпитване, и филтри, флагове и история.

Въпроси и Отговори

Администрацията на сайта създава домейни, проекти и потребители на ниво сайт в цялата инсталация. Персонализирането на проекта решава какво могат да виждат и правят тези потребители в рамките на един конкретен проект.

Петте вградени групи са заключени по дизайн, така че винаги да съществува базова линия. Създайте нова група въз основа на най-близкия профил, след което коригирайте разрешенията за това копие.

Да, но съхранените стойности се губят с него. Първо изчистете полето на съществуващите записи или експортирайте данните, защото изтриването не може да бъде отменено от екрана за персонализиране.

Проверете дали пощенският сървър е конфигуриран в „Администрация на сайта“, дали всеки потребител има валиден имейл адрес и дали поне едно поле е избрано в мрежата за автоматична поща.

Те могат да изготвят VBScript логика и да обяснят съществуващите блокове, но не знаят имената на полетата ви. Проверете името на всяко име спрямо Project Entities, преди да запазите скрипта.

Да. Скриптовете за работен процес и персонализираните полета трябва да се тестват отново след всяко надграждане. Поддържайте персонализирането документирано и минимално, така че усилията за проверка да останат управляеми.

Обобщете тази публикация с: