Документація – вступна сторінка
AyMINE – Technical doc. (in English)
abra
crm
- Модуль Контакти та адресної книги
- Системні права та налаштування CRM-модуля
- Огляд замовлень клієнтів
- Довідник
- Список і управління каталогами
- Політика конфіденційності та ділової інформації
- Надсилайте масові повідомлення відповідно до GDPR
- Патік масової електронної пошти
- Вихід і встановлення преференцій
для масової - Як коректно забути дані про людину
- Масові повідомлення електронної пошти
- Контракти, договори
- Партнер за контрактом
- Групи клієнтів
- Каталог або люди і компанії
- Контакти
- Швидко доступні контакти
sabre
hr
- Модуль персоналізації
- Цифровий кадровий архів
- Персоналізація – права користувача
- Облік кандидатів на роботу
- Посада
- Член команди – Працівник
- Огляд працівника
- Огляд власного персоналу
- Відповідальний персоналіст
- Синхронізація працівників та користувачів системи
- Трудовий договір
- modulesafety
- personalfolder
sys
- Системний модуль фреймворку AyMINE
- Клієнт
- Настроювання шлюзів для зовнішніх повідомлень
- Повідомлення із зовнішнім світом
- Правила для зовнішніх повідомлень
- Документи
- Додаткові функції з файлами
- Копіювання та переміщення файлів між об'єктами
- Презентація зображення
- Публічне посилання на документ
- Останні файли
- Дошка
- Розташування об'єкта на дошці оголошень
- Елементи клієнта
- Огляд і коментарі
- Безпека повідомлень і внутрішніх дискусій
- Переклади
- Зв'язки між об'єктами
- Типи сесій (відносин)
- Ролі та команди груп
- Користувач системи
- Адміністрація користувача
- GDPR та користувачі системи
- Безпечний вхід
- Адміністрація користувача
- Криптогаманець
- moduleclientoptions
frm
- introhelp
- introhelp_objectdetail
- AyMINE Framework
- Політика зберігання паролів
- Права користувача framework
- Модулі AyMINE
- Замки користувача
- Системні дозволи
- introhelp_deleting
- introhelp_settings
- introhelp_objectlist
- introhelp_dashboard
- introhelp_generalinfo
- introhelp_icons_dnadrhal9000_mar-22-220246-2023_caseconflict
- introhelp_icons
- Записи AyMINE
tsk
- 8D report
- Основним елементом FMEA
- FMEA
- FMEA - ймовірність виявлення
- Процес аналізу FMEA
- FMEA - ймовірність виникнення
- FMEA - оцінка тяжкості
- Модуль керування завданнями та інформаці
- Адміністрація модуля Управління завданнями
- Системні права модуля керування завданнями
- Події
- Акції, події та наради
- Персональний календар
- Журнал активності
- Згода керівника
- Чому не можна видалити деякі дані
- Область
- Область / проект / методологія
- Огляд областей
- Шаблони міток
- Управління тегами
- Мої області
- Подія
- Архівний пакет
- Кваліфікація, здібності / вміння
- Рівні компетентності та кваліфікації
- Необхідні здібності
- GDPR та облік кваліфікацій
- Право на управління кваліфікацією користувачів
- Кваліфікація користувача або контакту
- Команда проекту
- Рішення
- Об'єкти, які приймаються рішення
- Варіант прийняття рішень
- Шаблон плану / стратегії
- Визначення проекту
- Зразок запису
- Зразок ризику
- Визначення пакета
- шаблон завдання
- Активація події із завдання
- Управління відповідальністю – RACI matice
- Повідомлення про події
- Об'єкти, що відносяться до шаблонного завдання
- Події, що починаються
- Призначення нового завдання
- Обговорення
- Бізнес-подія
- Кнопки для активації події
- Події подій
- Покращення та запобіжні заходи
- Інформація
- Ключове слово
- Проведення наради
- Методики та правила
- Обов'язок
- Поняття
- Директиви та політики
- Управління змінами в проекті
- Проблеми, тікети та їх управління
- Центр обслуговування клієнтів
- Внутрішня довідка
- Об'єкти, яких стосується проблема
- Управління інцидентами, невідповідність якості
- Проект
- Графік проекту
- Команда проекту або команда до робочого процесу
- RACI-матриця для project
- Повернути план проекту за baseline
- Записи та журнали
- Записані дії
- Вимоги
- Вимоги до вступників
- Ризик
- Завдання
- Терміни викликів
- Огляд завдань
- Вплив завдання на право змінювати підключений obje
- Особисте завдання
- Член команди
- Об'єкти, які обробляються в задачі або вирішуються
- Завдання працівника
- Тест
- Типи тестів
- Попередження
- Попередження – приклад використання
- Попередження для себе
- tsktask_kanban
- moduleclientoptions
am
- amasset
- Модуль управління активами
- Процедура відбору та закупівлі
- Аналітична модель
- Постачальник продукту
- Категорія продуктів
- Властивість продукту або продукту
- Мета проекту
- Комерційна пропозиція
- Перерахувати пропозицію та замовлення
- Права доступу до пропозицій і цін
- Системний запит про стан замовлення
- Продукти та товари
- Стан продукту та його зміна
- Одиниці продуктів
- Критерії якості
- Про критерії якості продукції
- HARA продукту
Системні дозволи
Системні дозволи роблять функціональність системи доступною
Сторінка призначена для системних адміністраторів.
- Для чого потрібні системні дозволи?
- Значення системних дозволів обмежене
- Хто і як встановлює системні дозволи
- Детальне встановлення дозволів
Для чого потрібні системні дозволи?
Системні дозволи, а також системні права і технічно urights дозволяють визначити, які функції системи користувач може або не може використовувати.
Приклади системних дозволів:
- Право на створення та управління користувачами
- Право на участь в обговореннях
- Право працювати з майном
- Право дозволяти публікацію новин на сайті
- Право відображення всіх бізнес-областей в системі
Значення системних дозволів обмежене
Хоча система визначає понад 100 різних системних дозволів, переважна більшість прав у системі не регулюються ними. Вище вказано кілька спеціальних прав - наприклад, право змінювати права іншим - для яких необхідний системний контроль. Однак, за винятком кількох адміністраторів, абсолютна більшість членів колективу або працівників мають абсолютно однакові системні права. Однак система жорстко контролює права. Але по-іншому.
Основна вага контролю стосується не функціоналу, а даних. Наприклад.
- Право бачити завдання в проекті P
- Право на завдання людей з команди C
- Право на видалення інформації, створеної колегою K
Всі ці права регулюються встановленням дозволів для певної області даних – бізнес-область, проект, методологія тощо. Системні права є повністю другорядними в цій сфері:
- Системне право дозволяє мені працювати з інформацією (це може, напевно, кожен)
- Дозвіл на область, де розміщена інформація, визначає, чи можна видалити дану конкретну інформацію.
- Пряма інформація може мати замок, який дозволяє видаляти її тільки автору.
Тому управління системними правами є досить маргінальним питанням управління всією системою. Як правило, це робиться тільки при запуску нової фірми.
Хто і як встановлює системні дозволи
Стандарти є системними дозволами з моменту встановлення системи об'єднані в логічні групи, які роблять функціональність системи доступною. Йдеться про так звані «системні ролі», наприклад:
- Всі користувачі модулів завдань – tsk everybody
- Звичайні користувачі модуля активів – am everybody
Ці системні права адміністратор надає людям. Але оскільки незручні і непотрібні системні дозволи виділяти кожному окремо, то зручніше.
- Створити одну групу користувачів для всіх користувачів – наприклад, Усі працівники
- Групі надавати системні ролі для всіх — цим виділяються необхідні системні дозволи.
- Групу виділяти всім
Детальне встановлення дозволів
Попередження: Далі описані налаштування можуть робити тільки системні адміністратори. Також не дозволено адміністраторам облікових записів користувачів.
Система також дозволяє встановлювати системні дозволи таким чином, що
- Адміністратор тимчасово отримує системні дозволи frmAdmin
- У просторі компанії/клієнта створюються первинні групи системних прав
- Первинним групам виділені необхідні системні дозволи. Він просто робить це, копіюючи права на системні ролі, а потім індивідуально коригує список.
*Роль frmAdmin згодом віднімається від нього.
Попередження:
- Поправки вимагають, щоб потім всі користувачі вийшли і увійшли в систему. Не безпечно робити зміни в системі в експлуатації
- frmAdmin - це привілеї, які може зробити тільки системний адміністратор (суперадміністратор). Але при цьому він повинен надати йому рахунок, що належить клієнту, настройки якого змінюються.