Починаючи з релізу Ubilling 0.8.3 стала доступною механіка філій. Вона призначена для делегування деяких повноважень з адміністрування певної частини користувацької бази конкретним адміністраторам. Ця механіка передбачає контроль доступу до користувачів, зміну їхніх параметрів (номери телефонів, MAC-адреси, Тарифи тощо…) і розподіл статистичної інформації за групами цих користувачів - як-от “звіт з підключень” або “фінансовий звіт”. Практичним прикладом використання цієї механіки можна вважати, наприклад, ситуацію, коли ви віддаєте обслуговування частини своєї мережі на аутсорсинг, або коли ви побудували мережу для когось і не хочете починати закуповувати обладнання, встановлювати новий білінг, підписувати договори з платіжними системами тощо. Вам просто потрібно, щоб людина взяла і почала обслуговувати якихось “своїх” користувачів. Або ви дійсно є регіональним оператором з точками присутності в різних населених пунктах і ви хочете делегувати базовий менеджмент користувачів у цих населених пунктах персоналу на місцях. Загалом конкретні кейси застосування обмежуються вашою фантазією, а в загальних рисах механіка філій покликана просто спростити централізоване управління вашим франчайзом/філіями/дочірніми операторами.

Відповідаючи на запитання, які вам першими спадають на думку:

• Ні, користувачі прив'язуються не до міст. Це було б не гнучко і загалом нерозумно.
• Так, кожен користувач прикріплений до своєї філії безпосередньо.
• Ні, вплив цієї механіки на швидкодію всієї системи загалом - зведено до мінімуму.
• Так, користувачеві в будь-який момент часу можна змінити філію в кілька кліків.
• Так, користувача можна зробити таким, що не належить до жодної філії.
• Так, для іншої частини абонбази нічого не змінюється.
• Так, користувач “філії” фізіологічно нічим не відрізняється від “нормального”.
• Так, можна зробити для філії скільки завгодно адміністраторів, або передати адміністратору під управління скільки завгодно філій.
• Ні, адаптованими для використання адміністраторами філій є наразі тільки конкретні модулі.
• Так, для кожної філії передбачені свої тарифи, послуги (читаємо підмережі→NAS) і можливість заселення тільки в певних населених пунктах.
• Так, восьминіг, це перше що спало на думку.

Вмикається все це однією опцією alter.ini

BRANCHES_ENABLED=1

І дуже фігурним поділом прав за адміністраторами. Базовим правом для використання “Філій” є право BRANCHES. Слід зауважити, що наявність цього права автоматично переводить адміністратора у свою, особливу реальність, і повинно вами розглядатися як “тавро філіальності”, тобто адміністратор після цього має адмініструвати конкретні філії з максимально урізаними правами, і все. Водночас ви можете зберегти контроль за всіма користувачами, для своїх основних кадрів, таких як техпідтримка, адміністратори, хлопчики за викликом, бухгалтери, інженери. Для цього, ви не повірите, - у них просто не повинно бути цього самого “клейма філіальності”.

Після ввімкнення опції BRANCHES_ENABLED, слід створити початкового адміністратора. Якщо ви не розумієте глибоко, яке право для чого потрібне, ви можете покласти собі в директорію content/users/ цього семплового адміністратора branchmin і клонувати з нього права на потрібних вам адміністраторів. Далі слід налаштувати самі філії. Припустимо, у нас їх буде дві, з різними доступними населеними пунктами, різними доступними тарифами і послугами.

Сподіваємося, що зв'язки всіх цих речей цілком собі самоочевидні та зрозумілі

Далі можна пробувати це використовувати під уже філіальним адміністратором. Ось усе, що він бачить у базовому варіанті, і чого має вистачати для базової роботи з “його” абонентами.

Як бачимо, доступ він має тільки до користувачів, що належать до філій, які асоційовані з його логіном адміністратора.

За увімкненої механіки філій, у всіх користувачів у профілі з'являється відповідне поле, що вказує на філію, до якої належить користувач.

Під час реєстрації користувача адреса користувача формуватиметься за ланцюжком “місто→вулиця→будинок→квартира” з населених пунктів доступних конкретній філії та власне адміністратору. На заключному етапі реєстрації, будь-який адміністратор може вибрати філію, до якої належатиме новий користувач, зі списку доступних для адміністратора філій. Адміністратори без “клейма філіальності” тобто права BRANCHES, можуть реєструвати користувачів у будь-якій з доступних філій, або встановлювати чекбокс “Зареєструвати користувача без філії”.“.

Також ви можете в будь-який момент часу змінити філію користувача на яку завгодно з наявних і доступних адміністратору, або видалити її взагалі, зробивши користувача “нормальним”. Функція видалення користувача з філії доступна тільки користувачам з правами ROOT.

Також для філій існують свої звіти фінансовий і по підключеннях, інтегровані в основний модуль. Для них також є окремі права (ну раптом ви не хочете фінансову статистику філіальному адміністратору світити, і взагалі підпускати його близько до грошових операцій). Так, у нормальні звіти їм не можна.

Слід також зауважити, що право BRANCHESCONF є “типу рутовим” в рамках філій і не повинно бути встановлено філіальним адміністраторам в принципі.