Просмотр Исходного

В данной статье приведены примеры технических отчётов, которые сотрудники поддержки делают при решении задач - часто это короткие отчеты для каких-то специфичных кейсов.
{info}Такие отчёты создаются при решении кейсов на уровне поддержки SLA4{info}

{toc}

h2. Примеры

h3. Просмотр текущих прав доступа к типам адресных единиц для задачи SUP-632439
Выводит настроенные права доступа к справочнику "Типы адресных единциц"
{code}
select
agp.id,
ag.name,
ap.codename
from
auth_permission ap
left join
AUTH_GROUP_PERMISSIONS as agp
on agp.PERMISSION_ID = ap.id
left join
AUTH_GROUP as ag
on ag.id = agp.group_id
where
ap.codename like 'modelperm_HomeTypeName%' order by agp.id
{code}

h3. Поясненине структуры хранения данных в справочнике адресов по задаче SUP-594716

# Основные данные (страна, улица, номер дома) хранятся в таблице HOMES
# Основная таблица связана с таблицей типы адресных единицы (это строение, дом, микрорайон, улица, облась или край и тд), название таблицы - HOME_TYPE_NAME
# Еще есть служебное поле с типом записи справочника дома - нужно для верного построения дерева домов, таблица называетсяHOME_TYPES

Ниже сам запрос и пример полученных данных

{code:title=Запрос}
select first 1
HOMES.ID "ID дома",
HOMES.ZIP_CODE "Индекс",
HOME_TYPE.NAME "Служебный тип",
HOMES.COUNTRY "Страна",
REGION_TYPE."FULL" "Тип региона",
HOMES.REGION "Регион",
CITY_TYPE."FULL" "Тип нас.пункта",
HOMES.CITY "Нас. пункт",
SETTLEMENT_TYPE."FULL" "Тип поселения",
HOMES.SETTLEMENT "Поселение",
STREET_TYPE."FULL" "Тип улицы",
HOMES.STREET "Улица",
S_NUMBER_TYPE."FULL" "Тип строения",
HOMES.S_NUMBER "Номер строения",
KLADR_ID "ID в ФИАС",
UNRESTRICTED_VALUE "Адрес строкой"
from HOMES
left join HOME_TYPES as HOME_TYPE on HOMES.HOME_TYPES_ID=HOME_TYPE.ID
left join HOME_TYPE_NAME as CITY_TYPE on HOMES.CITY_TYPE_ID=CITY_TYPE.ID
left join HOME_TYPE_NAME as DISTRICT_TYPE on HOMES.DISTRICT_TYPE_ID=DISTRICT_TYPE.ID
left join HOME_TYPE_NAME as REGION_TYPE on HOMES.REGION_TYPE_ID=REGION_TYPE.ID
left join HOME_TYPE_NAME as SETTLEMENT_TYPE on HOMES.SETTLEMENT_TYPE_ID=SETTLEMENT_TYPE.ID
left join HOME_TYPE_NAME as STREET_TYPE on HOMES.STREET_TYPE_ID=STREET_TYPE.ID
left join HOME_TYPE_NAME as S_NUMBER_TYPE on HOMES.S_NUMBER_TYPE_ID=S_NUMBER_TYPE.ID
left join HOME_TYPE_NAME as S_LITER_TYPE on HOMES.S_LITER_TYPE_ID=S_LITER_TYPE.ID
order by HOMES.ID desc
{code}

||Пример данных||
|ID дома|2409|
|Индекс|665831|
|Служебный тип|Строение|
|Страна|Россия|
|Тип региона|область|
|Регион|Иркутская|
|Тип нас.пункта|город|
|Нас. пункт|Ангарск|
|Тип поселения|микрорайон|
|Поселение|Байкальск|
|Тип улицы|улица|
|Улица|Торговая|
|Тип строения|дом|
|Номер строения|10|
|ID в ФИАС|3800000400010560005|
|Адрес строкой|665831, Иркутская обл, г Ангарск, мкр Байкальск, ул Торговая, д 10|

h3. Дубли реквизитов, задача SUP-645914

Отчёт находит абонентов с дублями [реквизитов|CarbonBilling:Реквизиты].

Абоненту можно добавить несколько экземпляров одного и того же реквизита (например, если нужно добавить несколько телефонов или файлов). Но в некоторых случаях это может создавать проблемы - например, при интеграции с СОРМ.

Отчёт покажет какие реквизиты у каких абонентов задублированы.

Последнее текстовое поле нужно поправить "под себя" - укажите там IP-адрес Вашего биллинга вместо 10.0.0.1

{code}
select
*
from
(select
count(*) cnt,
ua.name attr_name,
av.attribute_id attr_id,
av.abonent_id abon_id,
a.name abon_name,
'http://10.0.0.1:8082/admin/Abonents/' || av.abonent_id || '/?tab=tab1147' url_to_abon_attrs
from
ATTRIBUTE_VALUES av
join
USER_ATTRIBUTES ua
on av.attribute_id=ua.attribute_id
join
abonents a
on
av.abonent_id=a.id
group by
2,3,4,5,6)
where
cnt>1
order by
4,5,1 desc
{code}

h3. Учётные записи с логином равным номеру договора другого абонента, задача SUP-650800

При создании абонента, создаётся и учётная запись с логином соответствующим номеру договора, поэтому маловероятно что такой логин будет использоваться у како-то другого абоннента.

Тем неменее, такую ситуацию можно воспроизвести при интеграции IPTV, когда отдельная услуга создаёт учетную запись, в результате "второму" абоненту не будет добавлена новая учетная запись, а [система мониторинга|http://docs.carbonsoft.ru/51019784#Системамониторинга-checkerrorworker.sh] создаст автозаявку о проблеме.

Чтобы проблема не возникала, лучше не создавать ситуацию когда номер договора соответствует логину учетной записи другого абонента. Отчёт позволит найти таких абонентов.

{code:title=Отчёт покажет проблемных абонентов}select
u.abonent_id,
u.login,
a.id,
a.contract_number
from
users u
join
abonents a
on u.login=a.contract_number
and u.abonent_id<>a.id
where
a.is_folder=0{code}
{code:title=Отчёт покажет количество проблемных абонентов}
select
count(*)
from users u
join abonents a on u.login=a.contract_number and u.abonent_id<>a.id
where a.is_folder=0{code}