BiTel

Привет. Документация вводит в некий конфуз.
Вот тут https://docs.bitel.ru/pages/viewpage.ac ... d=73597961 написано:
"Этот параметр можно указать для типа сервиса, в конфигурации типа сервиса: serv.radius.connection.checkDuplicate."
Речь идет про параметр radius.connection.checkDuplicate. Тоже самое написано про serv.radius.connection.checkDuplicate.type

Вопрос: Я всегда думал, что параметры в конфигурации модуля, устройства, типа устройства, и типа сервиса, можно использовать одни и те же, просто нужно учитывать приоритеты. В документации это четко нигде не написано, но косвенно это следовало.
Получается что это не так? Разве нельзя использовать параметр radius.connection.checkDuplicate в типе сервиса? Он не будет работать или что? Зачем нужен его "дублер" с именем serv.radius.connection.checkDuplicate специально для конфигурации типа сервиса?

Тогда, если не трудно, подскажите пожалуйста, каков точный приоритет параметров в конфигурациях модуля, устройства, типа устройства, типом сервиса (я ничего не забыл?) и разрешается ли все доступные параметры использовать в конфигурациях любых этих сущностей в зависимости от "логики" и приоритета? Или есть определенный набор параметров, которые будут работать будучи объявленными только в конфигурации определенной сущности? Например как в этом примере только в типе сервиса?
Спасибо.

В документации написано какие параметры и где можно указывать. Данный можно указать в типе сервиса.
Для устройств/типов устройств есть вот такое:
https://docs.bitel.ru/pages/viewpage.ac ... d=73598065

Но на самом деле там уже поменялось, в документации не описано. Сейчас наследование такое : Конфигурация модуля->Тип устройства->устройство. Тип сервиса пока не участвует в этом.

Немного поправил это место в документации.

Там нигде толком ниче не написано. Написано про некоторые и то не везде. И тут же в примерах идут взаимоисключающие вещи когда один и тот же параметр тыкают куда угодно включая то место которое не описано. Я могу привести много параметров которые ВООБЩЕ не упомянуты, как-будто они не существуют. Описаны они..

Ну так на вопросы то ответьте пожалуйста.
1) Будут ли все параметры работать в любой конфигурации любой сущности, том числе и в типе сервиса? Чисто технически, я могу их указывать где угодно, или типы сервиса стоят обособленно?
Если да, то зачем эта свистопляска с отделенными именами для (serv).radius.connection.checkDuplicate. Если нет, то почему например serv.password.char судя по документации можно размещать и в конфигурации модуля и в конфигурации типов сервиса и вообще где угодно потому что все остальное кроме типа сервиса наследуется. Почему для некоторых параметров которые можно указывать конфигурации устройства (или типа устройства), так и в конфигурации типа сервиса есть аналоги для типа сервиса с префиксом serv. а для некоторых нет. Назовите мне хоть одну причину для такого именования параметров, даже самую идиотскую. Ну кроме конечно той, которая предназначена для запутывания пользователя.
С параметрами, господа, у Вас творится полная вакханалия, скажу я Вам. Вот вроде заново с нуля спроектировали новый модуль Inet, а все равно такое впечатление что ничего продумано не было, одни костыли вокруг.

2) Как мне, глядя на параметр определить где его можно указывать, а где нет? Ну почему, почему у вас нет мазафака четкого описания всех параметров с их подробным описанием и указанием где, в каких конфигурациях их можно употреБЛЯТЬ. Это бесит просто капитально, выглядит просто как издевательство над людьми. Как человек предполагается должен разбираться в вашем продукте без нормального руководства?? Ну как? может я не понимаю чего-то...
И почему в вас сервер с документацией лежит постоянно? То 502 Bad Gateway то еще какая-нибудь хрень. В результате даже та скудная дока и та сука часто недоступна. И кстати личный кабинет billing.bitel.ru на том же серваке и тоже недоступен.
Ну так же нельзя...

подтверждаю HTTP Status 500

тех. проблемы с сервером, попробуйте сейчас

Эти проблемы с сервером у вас слишком часто последнее время

а есть нормативы какие-то?

_________________
I'm clever. I've got a computer.

Есть
Называется "Отток клиентов на основании субъективных оценок частоты перебоев сервера".
Как Вам такой норматив?

А, это всё же субъективное оценочное суждение, ок.

_________________
I'm clever. I've got a computer.

Вы наверняка отличный бизнесмен! Так и представляю:
-Шеф, клиенты недовольны, клиенты уходят! Говорят что у нас #$&^aя документация и та на сайте, который слишком часто лежит.
-Так, спокойно, нормативы есть? Так это на основании субъективных оценочных суждений! Всё ок))

_________________
Цитаты великих людей
Напишите в helpdesk © stark
повторяю: => хелпдеск => доработка => профит © dimOn
свершилось... © skn
Мой код изящен, лёгок, оригинален, краток. Как прохладный весенний ветерок, как звонкий ручей! © dimOn
Вежливый разработчик © Artur
Эти баги тоже исправлены, как и те, которые еще не написаны © Artur
ну т.е. существует воркэраунд, ок © dimOn

Никаких "Увы", «Ни любви, ни тоски, ни жалости»))))
На "ok" же!) Он же сказал)

Благодаря недюжей активности в этой ветке господина mhollow - я за неделю узнал о модуле INET больше . чем за последние 5 лет.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

Это все фигня, я сейчас добрался до модуля VoiceIP.
Запасайтесь попкорном ))

Хотя этот модуль у нас работает лет 9, но всёж уже побежал. А вдруг сможете срестить эккаунтинг евойного радиус-сервера с астериском путём радиус-апдейт пакетов, а не только по старт-стоп.

_________________
"Все правые - в резерве!" (c) (translate.google.ru/#en/ru/all%20rigths%20reserved)

У них и Start не обрабатывается, какой еще Update.
Вы много хочете... Тут такая пичалька что даже текущих звонков не видно

Нет. Я же написал иерархия такая - конфигурация модуля -> Тип устройства -> устройство.

Этот параметр особенный. Там иерархия такая Модуль -> тип сервиса. Нет устройств. Его нельзя задать на устройстве. Т.е его можно указать либо в конфигурации модуля либо в типе сервиса.

serv.password.char - был глобальный изначально, он был только в конфигурации модуля. Потом кому-то понадобилось делить.

Изначально у нас конфигурация модуля не наследовалась в устройствах. Потом сделали наследование. Т.е это все менялось динамично по мере развития модуля inet. Изначально вообще никак не связаны были эти конфигурации, а к тому, что их нужно связать, пришли уже потом. Тип сервиса пока отделельно, потому как изначально у него были только параметры, которые нужны только на нем. У нас в биллинге вообще много конфигураций, очень многие сущности имеют свои конфигурации(например опции) - они не наследуются. Если их все сделать наследуемыми, то все будет еще более запутанно.

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



Возле каждого параметра обычно написано где его можно использовать. И serv.password.char этот описан в 2-х местах.