Логирование всех действий в системе?

[GoogleCodeExporter]

После удачной имплементации в пиццерии 
Opentpv и столкнувшись с простейшей 
нерасторопностью официантов перео мной 
встали два вопроса:

1. Блокирование знака минус (чтобы нельзя 
было простому официанту удалить или 
уменьшить внесенную позицию без участия 
администратора)
2. Отсутствие системы логирования всех 
действий в системе, которая по своей сути 
предназначена для работы с деньгами мягко 
говоря немного шокировала.

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

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

В общем постановка задачи видится мной так:
1. Логируются в БД или в файл (UTF8) следующие 
действия:
1.1. Вход в систему
1.2. Выход из системы
1.3. Открытие чека
1.4. Печать чека на любом этапе
1.5. Добавление/изменение/удаление позиции в 
чеке
1.6. Открытие денежного ящика
1.7. Операции по складу 
добавление/изменение/списание/перемещение/
удаление в процессе приходования на склад.
2. Логируются следующие данные:
2.1. Время операции
2.2. Имя пользователя
2.3. Вид операции
2.4. Детали операции
2.4.1. Номер чека
2.4.2. Столик
2.4.3. Номер и название позиции (товара)
2.4.4. Количество
2.4.5. Сумма
2.4.6. Название Склада (для операций по складу)

Это минимум, который должен бы закрыть 
многие административные вопросы.

Каково Ваше мнение?

Original issue reported on code.google.com by uamillio...@gmail.com on 13 Mar 2011 at 8:21

[GoogleCodeExporter]

Если блокировка знака минуса(или любой 
другой кнопки) на панели кассира 
принципиальна посмотрю может что-то 
получится сделать это не сложно главное 
лишнего не наделать, что потом может мешать 
работе.

Интересно, я тоже недавно столкнулся с 
необходимостью вести логи, в моём случае 
необходимо стало вести лог информации 
посылаемой/получаемой с фискального 
регистратора. И тоже заметил что Openbravo POS 
выдаёт минимум информации для контроля за 
работой системы, хотя кое-что в системе уже 
есть и его надо только правильно 
использовать.

С начало по разделу 2, практически вся 
указанная информация хранится в базе 
данных и её можно получить с помощью 
отчётов, просто те отчёты что есть в 
программе могут не содержать эту 
информацию (к тому же у Вас OpenTPV, а она 
несколько устарела). 

Ещё механизмы работы с СУБД (я предпочитаю 
MySQL), в дополнении к инструментам самой 
Openbravo POS, дают достаточно мощный 
инструментарий для контроля за работой 
пользователей. Так я уже публиковал статью 
OpenbravoPOSMonitoring, где наметил несколько 
направлений для удалённого мониторинга за 
работой пользователей с Openbravo POS (например 
можно отслеживать количество выбиваемых 
чеков). Так же на уровне прав доступа к СУБД 
можно запретить удаление (например 
номенклатурных позиций) или изменения 
(например добавления изображений) данных.

Original comment by svinin...@gmail.com on 19 Mar 2011 at 3:00

• Changed state: Work
• Added labels: Type-Enhancement, Component-Logic

[GoogleCodeExporter]

Теперь по разделу 1:

1, 2, 3 и 5 нет вообще и если делать то в базе 
данных, где будет вестись своего рода 
дневник по работе пользователей с системой.

4 и 6 этого тоже нет и как я уже писал, если 
делать, то делать в виде файла где будет 
накапливаться информация по работе 
системы с подключёнными устройствами, при 
этом информацию будет содержать только 
служебные данные(например начало печати, 
окончание, данные о состоянии принтера и 
ошибках) никаких сумм по финансовым 
операциям.

7 подпункт больше касается именно Вашего 
внедрения, так как в стандартном варианте 
по сладу достаточно сделать расширенный 
отчёт. У Вас же OpenTPV и там более продвинутый 
механизм ведения складского учёта и по 
нему нужно делать более сложные отчёты, как 
у меня будет время постараюсь посмотреть, 
что там и как работает, с целю добавления 
этого функционала в данный проект.

Original comment by svinin...@gmail.com on 19 Mar 2011 at 3:16

[GoogleCodeExporter]

В Comment 1 должна быть ссылка на 
http://code.google.com/p/openbravoposru/wiki/OpenbravoPOSMonitoring

Original comment by svinin...@gmail.com on 19 Mar 2011 at 3:17

[GoogleCodeExporter]

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

Про логирование. Поскольку я тоже являюсь 
приверженцем MySQL и предполагаю, что сколь 
скоро используется именно POS система, то MySQL 
используется именно для нее, а не для каких 
либо co-location и т.п. А отсюда вывод, что с 
вероятнотстью 99% пользователи системы 
OpenTPV/OpenBravoPOS будут иметь root пароль MySQL и 
смогут писать тригеры и процедуры MySQL. 

Сумурно получилось.

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

Вообще мне кажется, что в будущем стоит 
посмотреть в сторону переноса на сторону 
БД многих действий в системе. Так она и 
работать будет шустрее. Просто я в Java = 0 а БД 
- это моя стихия. Пока я в Java разберусь уйдет 
много времени.

Вопрос: В каком классе определяется "минус" 
- где его перехватывать и отправлять на 
проверку наличия роли?

Original comment by uamillio...@gmail.com on 19 Mar 2011 at 5:37

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Вот еще по поводу "логгирования". Это работа 
конкретно в Openbravo POS довольно тяжелая, но 
мысль пишу.

Вообще в "больших" системах кнопка удаления 
чека, а также удаление позиции реальную 
запись не удаляет, а помечает как 
удаленную. Изменение позиции в сторону 
уменьшения количества не меняет запись, а 
помечает как удаленную текущую запись, 
создает новую с меньшим количеством. 

Это сделать все просто. Ну и тяжелые работы 
это: 

1. Перелопачивать отчеты и другой 
функционал, чтобы учитывали удаленные 
записи.
2. Разрабатывать процедуру очищения базы. 
Это может быть как внутренняя задача, так и 
внешний периодически запускаемый скрипт.

Что касается протоколирования важных 
действий, мне кажется, что тут два уровня: 
1. Протоколирование в файл, logrotate.
2. Протоколирование на человеческом языке в 
базу данных. Это надо для того, чтобы 
старший кассир имел возможность получить 
нужную информацию прямо в онлайне, через 
отчеты, не прибегая к помощи технического 
специалиста. А смотреть ему интересно две 
штуки: что происходило с POS терминалом (как 
раз упомянутые открытия смены, денежного 
ящика и т.д.) и судьбу конкретных чеков. 
Отчет по закрытым.

Так что получается совсем по хорошему надо 
делать
1) Логгинг действий в БД, таких как вход в 
систему, выход из нее, открытие ящика, 
снятие Z-отчетов, обнаруженные потери связи 
с ФР и т.д.

2) Пометку чеков, вместо реального удаления. 
Отчеты по удаленным и измененным чекам.

Original comment by gennady....@gmail.com on 31 Mar 2011 at 1:27

[GoogleCodeExporter]

Так как тема по логированию намечается 
большой, то все вопросы/ответы по кнопке 
"минус" убрал в Issue 107 

В будущем прошу все вопросы максимально 
дробить, это всё-таки не форум, а баг-трекер 
:)

Original comment by svinin...@gmail.com on 31 Mar 2011 at 6:02

[GoogleCodeExporter]

Original comment by svinin...@gmail.com on 18 Apr 2011 at 5:06

• Added labels: Security, Priority-Medium
• Removed labels: OpenTPV

[GoogleCodeExporter]

Так как в системе используется библиотека 
java.util.logging, я так понимаю нам нужно все 
события расставить по шкале уровней 
сообщений:

SEVERE (highest value)
WARNING
INFO
CONFIG
FINE
FINER
FINEST (lowest value)

Original comment by svinin...@gmail.com on 25 Apr 2011 at 6:33

[GoogleCodeExporter]

Ну мне кажется тикет не только про то, что 
надо логгировать с помощью java.util.logging. Как я 
уже писал, некоторую информацию 
руководство должно получать в онлайне, 
через отчеты. А это требует переделки 
логики.

Мне лично это интересно и я займусь этим 
чуть попозже.

Original comment by gennady....@gmail.com on 25 Apr 2011 at 7:16

• Added labels: Milestone-0.4.0

[GoogleCodeExporter]

Original comment by gennady....@gmail.com on 25 Apr 2011 at 7:51

[GoogleCodeExporter]

Попробовал сделать лог для весов с печатью 
этикетки. Сделал по аналоги с существующем 
уже сейчас логом отправки SQL-запросов 
(класс StaticSentence). Пример того, что у меня 
получилось:

26.04.2011 15:18:10 com.openbravo.pos.massakvpm.DeviceScaleVPMComm writeLine
INFO: Device: massakvpm Send line: f8 55 ce 01 00 00 00 00
26.04.2011 15:18:11 com.openbravo.pos.massakvpm.DeviceScaleVPMComm readCommand
INFO: Device: massakvpm Read line: f8 55 ce 1b 00 01 01 00 01 13 12 00 01 02 03 
04 05 06 07 08 09 0a 0b 0c 0d 0e 0f 10 00 00 00 00 f8 a6
26.04.2011 15:18:11 com.openbravo.pos.massakvpm.DeviceScaleVPMComm writeLine
INFO: Device: massakvpm Send line: f8 55 ce 4f 00 82 01 08 00 01 00 47 00 0c 00 
00 00 41 00 00 00 01 01 16 bc 02 00 00 00 00 00 00 0c 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 20 20 20 20 00 00 00 00 00 12 c1 f3 f2 e5 f0 e1 f0 ee e4 
fb 20 f1 20 e8 ea f0 ee e9 0d 00 00 0d 00 00 0d cb 57 a9
26.04.2011 15:18:11 com.openbravo.pos.massakvpm.DeviceScaleVPMComm readCommand
INFO: Device: massakvpm Read line: f8 55 ce 06 00 42 01 08 00 01 00 6d 3c

Для отслеживания работы драйвера штука 
отличная, думаю попробовать добавить во 
все драйвера работающие по RS232, а это 100% 
подключаемого к Openbravo POS. Ещё можно добавить 
в строку размер сообщения.

В коде выглядит так:

logger.info("Device: " + m_sDevice + " Send line:" + 
ByteArrayUtils.getHexString(aline));

Но возник вопрос, насколько лог в таком 
виде необходим пользователям и 
администраторам системы? 

Сейчас информация остающаяся в логе, это 
инструмент программиста, для проверки 
работы с базой данных и с оборудованием 
подключённым к POS. Пользователям она 
абсолютно не нужна, а администраторы в 
основном предпочитают информацию в более 
адаптированном для понимания виде. Так же 
есть проблема конфиденциальности, так как 
преобразовать её в читабельный вид не 
составит труда и из файла можно будет 
узнать о всех проводках и суммах прошедших 
через POS.

Предложение на подумать, выстроить 
иерархию логов по уровням 
программист-администратор-пользователь.

Original comment by svinin...@gmail.com on 26 Apr 2011 at 9:54

[GoogleCodeExporter]

Расширенный вариант сообщения в лог:

logger.info("Device: " + m_sDevice + " Message size: " + aline.length + " Send 
line:" + ByteArrayUtils.getHexString(aline));

Результат:

26.04.2011 15:58:03 com.openbravo.pos.massakvpm.DeviceScaleVPMComm writeLine
INFO: Device: massakvpm Message size: 83 Send line: f8 55 ce 4c 00 82 01 08 00 
08 00 44 00 09 00 00 00 3e 00 00 00 01 01 16 f4 01 00 00 00 00 00 00 09 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 20 20 20 20 00 00 00 00 00 0f c1 e8 f2 
ee f7 ea e8 20 f1 20 f1 fb f0 ee ec 0d 00 00 0d 00 00 0d 4c f7 60

Original comment by svinin...@gmail.com on 26 Apr 2011 at 10:01

[GoogleCodeExporter]

Относительно конфиденциальности я думаю 
особенно беспокоится не стоит. Если 
результат помещать в БД то тот кто будет 
иметь к ней доступ и так все узнать может, а 
если отгружать в файл, то опять же нужно 
просто правильно настроить систему прав 
доступа к файловой системе.

Original comment by uamillio...@gmail.com on 26 Apr 2011 at 10:34

[GoogleCodeExporter]

Я начал собственный форк OpenBravo POS, где 
добавил функции логгинга.
Можно просмотреть код тут:
https://github.com/stas/pos/commit/eebba5ee3b114a4af55233497ab135164f88ef5b

Original comment by susc...@gmail.com on 13 Jul 2011 at 8:47