Телеграмм чат группы nag_public страница 26097

смотрящий...

23:44пожаловаться #1

E in Nag.Ru

ну так не будет... как минимум на уровне секурити все и посыпется

23:44пожаловаться #2

это хорошо реализовано во фреймворке BillManager

23:44пожаловаться #3

тогда это не абонент а уже сотрудник

23:44пожаловаться #4

со всеми вытекающими

23:44пожаловаться #5

ПД абонента другому абоненту...

23:45пожаловаться #6

с чего оно должно сыпаться? у того же вымпелкома и.т.п. ставишь права какими договорами можно управлять и справа переключаеь

23:45пожаловаться #7

да там не обязательно ПД. представьте иначе. ну что у нас скажем термометры стоят

23:45пожаловаться #8

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

23:45пожаловаться #9

давайте не будем счас еще в правовую область углублятся

23:46пожаловаться #10

E in Nag.Ru

ЛК для абонента и для сотрудника это разные системы.. там даже для фронта общими могут только отдельные элементы управления

23:46пожаловаться #11

а зря... напридумывать можно много.. но многое и не прокатит

23:46пожаловаться #12

вы счас описываете идеал. А в неидеале для экономии ресурсов абонент может быть просто частным случаем сотрудника с ограниченными правами.

23:47пожаловаться #13

E in Nag.Ru

ну тогда тыкать в выпеловские системы вообще не стоит :)

23:47пожаловаться #14

То есть скажем есть таблица проданных услуг и платежей. Админ в ней видит все записи, менеджер записи своих клиентов, клиент только свои. Чем плохо?

23:47пожаловаться #15

да.. это так и работает обычно... база 1 но к выдаче разное

23:47пожаловаться #16

я намекаю на то что фронт тоже может быть один

23:48пожаловаться #17

сложнее

23:48пожаловаться #18

особенно если доверия к рядовым сотрудникам нету и ради снижения возможности попиздинга абонентской базы для них делаются параноидальные ограничения

23:48пожаловаться #19

сделай для сотрудников например только с серых ип и счастье сразу будет