HEDG_SS
NoDeny
Пользователь
Карма: 0
Offline
Сообщений: 48
|
|
« : 30 Апреля 2011, 15:27:52 » |
|
Добрый день. Подскажите пожалуйста, назначение некоторых полей в БД Nodeny v50 Таблица users - paket3, next_paket3
|
|
|
Записан
|
|
|
|
0xbad0c0d3
гуру nodeny )
NoDeny
Спец
Карма: 116
Offline
Сообщений: 1059
|
|
« Ответ #1 : 30 Апреля 2011, 16:45:23 » |
|
Дополнительный пакет
|
|
|
Записан
|
|
|
|
HEDG_SS
NoDeny
Пользователь
Карма: 0
Offline
Сообщений: 48
|
|
« Ответ #2 : 04 Мая 2011, 09:55:20 » |
|
Можете подробнее расказать про таблицу dopvalues Я так понимаю: line_id - просто id записи parent_id - id user к которому относятся эти записи. dopfield_id - соответствует id в таблице dopfields field_value - значение для дополнительного поля admin_id - Поле, кто добавлял time - timestamp revision - ?
Что такое revision? Для чего это поле?
Также есть таблица rev_users. Для чего она? Что будет если добавить пользователя скриптом и не добавлять никаких данных в rev_users?
|
|
|
Записан
|
|
|
|
VitalVas
NoDeny
Спец
Карма: 60
Offline
Сообщений: 991
|
|
« Ответ #3 : 04 Мая 2011, 10:11:20 » |
|
dopfields - содержит описания дополнительных полей:
id - идентификатор поля template_num - номер шаблона parent_type - с каким объектом ассоциируется поле. 0 - с клиентом field_type - тип поля: целое, строковое, да/нет и т.д. field_name - имя поля field_alias - алиас имени field_flags - строка флагов: убирать ли лидирующие/завершающие проблелы, включить транслитерацию, привести к нижнему регистру и т.д. field_template - регулярное выражение для проверки корректности заполнения поля comment - комментарий
dopvalues - содержит данные дополнительных полей:
parent_id - хозяин данного параметра, например id абонента dopfield_id - ссылка на описание параметра в таблице dopfields (по полю id) field_value - значение параметра admin_id - id администратора, внесшего/изменившего данные time - timestamp создания/изменения данных revision - номер ревизии, чем больше тем актуальнее Для разных parent_id ревизия всегда разная.
|
|
« Последнее редактирование: 04 Мая 2011, 10:13:40 от VitalVas »
|
Записан
|
|
|
|
HEDG_SS
NoDeny
Пользователь
Карма: 0
Offline
Сообщений: 48
|
|
« Ответ #4 : 04 Мая 2011, 10:44:28 » |
|
Cпасибо! Если идет добавление пользователя через скрипт (перенос абонов из другого биллинга), то какую ревизию нужно выставлять для этих дополнительных полей? Можно ли просто выставить всем версию ревизиюи 1, или она каким то образом вычисляется?
Нужно ли заполнять таблицу rev_users при добавлении нового пользователя? Я так понимаю она служит для указания какая версия дополнительных полей актуальна для для пользователя с user.id = rev_users.id ?
Еще вопрос по поводу оплат... Если переносится абонент, у которого оплачено несколько месяцев, то достаточно ли просто указать соответствующую сумму в users.balance или нужно еще что-то добавлять по таблицам?
|
|
|
Записан
|
|
|
|
Efendy
|
|
« Ответ #5 : 04 Мая 2011, 12:41:46 » |
|
Ревизия должна быть уникальна не только в пределах одного юзера, а для всех клиентов. В самом NoDeny номер ревизии формируется таким образом: в dopvalues вставляется пустая запись (parent_id=0). Mysql после вставки возвращает last_insert_id, который берется из поля line_id - это и есть номер ревизии. С этим номером вставляются все данные для текущего клиента, удаляется пустая запись. Такая схема используется для того, чтобы гарантировать уникальность ревизии т.к. если сделать select max(revision)+1, а потом делать Insert, то если параллельно какой-либо админ сделает ту же самую операцию, то с некоторой вероятностью мог бы возникнуть конфликт ревизий.
Если же переносить данные из другого биллинга, то можно завести переменную "номер ревизии" и инкрементить ее после вставки блока данных для каждого юзера.
Важно. Схема с ревизиями замедляет работу, поэтому в 49.33 и 50.33 ревизий нет в dopvalues, т.е в этой таблице всегда актуальные значения. А ревизии хранятся в другой таблице, которая нужна чисто для history. 50.32 и 50.33 практически только этим и отличаются
|
|
|
Записан
|
|
|
|
Efendy
|
|
« Ответ #6 : 04 Мая 2011, 12:44:28 » |
|
Если переносится абонент, у которого оплачено несколько месяцев, то достаточно ли просто указать соответствующую сумму в users.balance или нужно еще что-то добавлять по таблицам?
Да. В таблице pays создать бонусный платеж с комментом "перенос баланса с другого биллинга" на сумму баланса. Причем отрицательные таким же образом
|
|
|
Записан
|
|
|
|
HEDG_SS
NoDeny
Пользователь
Карма: 0
Offline
Сообщений: 48
|
|
« Ответ #7 : 04 Мая 2011, 14:18:11 » |
|
Спасибо! Вопрос по таблице paysПри добавлении платежа по конкретному пользователю. Непонятны значения некоторых полей. id id записи в таблице. mid соответствует user.id cash Сумма на счет (она же падает в баланс абона) time timestamp admin_id соответствует admin.id admin_ip Вычисляется по группам цифр ip. $1*16777216 + $2*65536 + $3*256 + $4 office bonus reason Просто вставить текст "перенос баланса с другого биллинга" coment Коментарий который видит абонент type category
|
|
|
Записан
|
|
|
|
Efendy
|
|
« Ответ #8 : 04 Мая 2011, 14:29:16 » |
|
из tables.html: id - уникальный id записи; mid - id клиента (см. таблицу users); cash - денежная сумма, для всех нефинансовых записей = 0; time - время формирования записи, timestamp; admin_id - id администратора (см. табл. admin), который сформировал запись, если запись сформировал клиент или система (например, ядро) = 0; admin_ip - ip администратора/клиента с которого было произведено формирование данного события. Для ядра = 0, что соответствует 0.0.0.0, ip упаковывается в 4 байта; office - номер отдела, в котором работает админ сформировавший запись. Для ядра и клиентов = 0; bonus - для финансовых платежей указывает безналичный ли платеж; reason - многофункциональное поле. В зависимости от типа платежа (type) и категории (category) может являться: - комментарием для администратора, если запись является сообщением; - информацией о каком-то событии, например, какие поля в учетной записи были изменены; - закодированным событием, например, данные о работе. coment - многофункциональное поле. Обычно хранит сообщение для клиента. type - тип записи: платеж, событие, сообщение, передача наличных; category - категория платежа, более детально сообщает о внутреннем устройстве текущей записи.
Поле type может принимать строго такие значения:
10 - платеж клиента; 20 - временный платеж; 30 - сообщение/комментарий клиенту; 40 - передача наличных; 50 - событие.
Типы 10 и 20 являются финансовыми платежами, т.е влияют на состояние счета клиента. Сумма всех платежей с типами 10 и 20 строго соотвествует значению поля balance в таблице users. При добавлении/удалении платежей с типом 10 и 20, система модифицирует поле balance.
Для записей с кодом 30 и 50, поле cash должно быть всегда равным 0.
Тип 40 является внутренней проводкой, указывающей на перемещение наличности от одного администратора к другому. В поле reason должен быть указан id администратора передающего наличные, а в поле coment - принимающего наличные.
Поле bonus, установленное в значение 'y' указывает на то, что платеж безналичный. Для типа 20 всегда bonus='y'.
Тип 30 указывает на то, что запись является либо сообщением либо комментарием. Чем именно скажет поле category.
Тип 50 наиболее обширный в описании. Как обычно, поле category регламентирует действие записи с типом 50.
В файле paystype.pl прописаны действия, которые необходимо применить для расшифровки поля reason для определенных категорий событий.
|
|
|
Записан
|
|
|
|
HEDG_SS
NoDeny
Пользователь
Карма: 0
Offline
Сообщений: 48
|
|
« Ответ #9 : 04 Мая 2011, 14:45:42 » |
|
Коротко и понятно. Спасибо!
|
|
|
Записан
|
|
|
|
HEDG_SS
NoDeny
Пользователь
Карма: 0
Offline
Сообщений: 48
|
|
« Ответ #10 : 12 Мая 2011, 09:34:24 » |
|
Переношу пользователей из старого биллинга. Не пойму в чем проблема... Нужно перенести текущее состояние абонента (т.е. если у него текущий месяц оплачен, то просто пренести с нулевым балансом; Если оплачено несколько месяцев, то положить соответствующую сумму на баланс. Если пользователь отключен, то так и переносим отключенным. Отрицательных балансов нет.) Все нормально, за исключением первого варианта. Выполняется следующий запрос: INSERT INTO users SET ip='172.xx.xx.xx', name='139/3', passwd=AES_ENCRYPT( '3ba0d4ce','hardpass3$'), grp='1', mid='0', contract='1024', contract_date= '0', state= 'on', auth= 'no', balance= 0, money='0', limit_balance='0', block_if_limit='1', sortip= '321321', modify_time=unix_timestamp(), fio= 'Пупкин В.В.', srvs='0', paket= '25', next_paket= '0', paket3='0', next_paket3='0', start_day='0', discount='0', hops='0', cstate='0', cstate_time=unix_timestamp(), comment='', lstate='1', detail_traf='0'
Но почему-то у абона потом появлятся отрицательный баланс и соответственно его отключает.. В таблице pays система автоматом проводит снятие с cash=0.00, type=50 и category=423. При этом если добавляется другой абон с ненулевым балансом и соответственно платеж в pays, то ничего больше не снимается и абон продолжает работать... Подскажите пожалуйста с чем может быть связана проблема... Что делается не так?
|
|
|
Записан
|
|
|
|
Efendy
|
|
« Ответ #11 : 12 Мая 2011, 10:43:27 » |
|
Поле баланс - баланс клиента без стоимости услуг текущего месяца. Если день последнего платежа меньше текущего числа, то биллинг работает по предлоплате, следовательно сначала деньги потом стулья. Это все означает, что нулевой баланс - это состояние "денег нет для оплаты текущего месяца"
|
|
|
Записан
|
|
|
|
HEDG_SS
NoDeny
Пользователь
Карма: 0
Offline
Сообщений: 48
|
|
« Ответ #12 : 12 Мая 2011, 12:21:10 » |
|
Понял, спасибо за пояснения
|
|
|
Записан
|
|
|
|
Elisium
NoDeny
Старожил
Карма: 19
Offline
Сообщений: 360
На форумах "спасибом" называется плюс к карме.
|
|
« Ответ #13 : 06 Июля 2011, 10:49:59 » |
|
Апну тему. Есть таблица users, в ней есть поле sortip. В доке написано sortip - используеся при сортировки записей по ip; Стоит задача переноса юзеров из одного билля в другой. Как формируются данные в этом поле ? Можно ли его поставить в "0" ?
|
|
|
Записан
|
|
|
|
versus
|
|
« Ответ #14 : 06 Июля 2011, 11:34:00 » |
|
Код нодени нам говорит так: if ($test_ip!~/^(\d+)\.(\d+)\.(\d+)\.(\d+)$/ || $1>255 || $2>255 || $3>255 || $4>255) $sortip=$2*65536 + $3*256 + $4;
|
|
|
Записан
|
|
|
|
|