Состав модуля¶

Логгер действий пользователя в системе.

`datalogging`	Логгер действий пользователя в системе.
`datalogging.api`
`datalogging.app_meta`
`datalogging.dbrouters`
`datalogging.enums`
`datalogging.helpers`
`datalogging.management.commands.datalogging_compress`
`datalogging.middleware`
`datalogging.models`
`datalogging.signals`

api¶

datalogging.api.filter_events(**kw)¶

Фильтрация по записям лолга.

Примечание

Не предусмотрена работа с NoSQL.

Если необходимо произвести фильтрацию по данным находящимся в в полях context_data или object_snapshot. То необходимо использовать префиксы _context и _snapshot соответственно.

filter_events(
    object_type='enterprise.Enterprise',
    system_type=SystemsEnum.MAIN_APPLICATION,
    _context__diff__name='Учреждение №666',
    _context__ent='455',
)

datalogging.api.get_events_by_token(request_token)¶: Получение записей лога по их общему токену

datalogging.api.get_request()¶: Получение текущего запроса.

datalogging.api.get_request_token()¶: Получение токена текущего запроса.

datalogging.api.get_user_ip()¶

Получение IP текущего пользователя.

Return str or None:
	Если не удалось получить IP вернет None

app_meta¶

class datalogging.app_meta.InvaderLogPack¶

Инжектируемый пак

post_run(request, context, response)¶: Некоторые косвенные методы определения поведения пользователя. Если в ответе на запрос упоминается заголовок, то считается, что вернули окно. Если запомненный ранее пользователь был аутентифицирован, а после формирования ответа - нет, то считается, что произошел выход из системы. И наоборот.

pre_run(request, context)¶: Перед выполнением экшена у инжектируемого пака необходимо запоминить пользователя

datalogging.app_meta.invader_invoke(self, request, action, stack, *args, **kwargs)¶

Параметры:	request (request) – Экземпляр Action’a. action (Action) – Экземпляр Action’a. stack (list) – Экземпляр Action’a.

datalogging.app_meta.is_loggable(obj)¶

Данная функция использоуется для опредения нуждается ли данный объект в логировании. Проводится проверка объекта на вхождение имени его класса, либо имени класса его предка в список-исключение EXCLUDED_ACTIONS. Если переданный экземпляр найден в списке, то объект счтается подходящим для создания записи.

Параметры:	obj (Action) – Экземпляр Action’a.
Результат:	bool – результат проверки.

dbrouters¶

class datalogging.dbrouters.DataLoggerRouter¶

Роутер не позволяет создавать связи с моделью лога.

allow_relation(obj1, obj2, **hints)¶: Метод контролируюий факт создания связи между обектами. Отсекаются связи создаваемые с моделяи данного модуля.

allow_syncdb(db, model)¶: Метод регулирующий возможность инициализации моделей.

db_for_read(model, **hints)¶: Выбор БД для чтения. В данном методе происходит проверка на заданное имя модели и в случаем если модель принадлежит данному модулю, для нее используются отдельные настройки

db_for_write(model, **hints)¶: Выбор БД для записи. Применяются те же правила, что и при чтения из базы.

class datalogging.dbrouters.NotUseDataLoggerDBRouter¶

Роутер запрещает создание таблиц в базе для логгера.

allow_syncdb(db, model)¶: Запрет создания таблиц в базе логгера

enums¶

class datalogging.enums.ConfigurableEnum¶

Метакласс автозагрузки типов перечислений.

Автозагрузка типов осуществляется из settings.py проекта, причем данные должны являться словарем с кортежами в качестве значений. Наименование параметра должно начинаться с приставки “DATALOGGER”. Пример:

DATALOGGER_EVENT_TYPE = {
    'SYSTEM': ('se', u'Системное событие'),

}

После инициализации класса, можно вызывать как обычный аттрибут. И в целом класс используется как обычное перечисление. Пример:

print EventType.SYSTEM // 'se'

class datalogging.enums.EventCode¶

Перечисление кодов событий.

Пример возможных кодов: - (insert, Добавление) - (delete, Удаление)

class datalogging.enums.EventType¶

Перечисление типов событий.

Пример возможных типов: - (se, Системное событие) - (lse, Юридически важное событие)

class datalogging.enums.SystemsEnum¶

Перечисление сред логирования.

Пример возможных значений: - (‘scheduled_task’, u’Задача по расписанию’) - (‘ws’, u’Web-сервис’)

helpers¶

datalogging.helpers.get_snapshot(instance)¶: Получение снимка состояния экземпляра модели

datalogging.helpers.is_server_mode()¶: Определение режима работы сервера.

datalogging.helpers.memorize_user(user)¶: Запоминание пользователя в текущем треде.

datalogging.helpers.only_server_mode(func)¶: Предотвращение запуска логгера в шеле

datalogging.helpers.remember_user()¶: Вспоминаем пользователя

managers¶

middleware¶

class datalogging.middleware.CaptureRequestMiddleware¶

Middleware сохраняющее текущий request.

В последующем request используется для получения ряда параметров необходимых для логирования действий ( например ip пользователя ).

class datalogging.middleware.RequestTokenMiddleware¶

Middleware создающее токен для текущего запроса.

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

model¶

class datalogging.models.DataLog(*args, **kwargs)¶

Лог активности пользователей.

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

guid:: Уникальный ИД записи не является primary_key в случае с реляционными БД. Его необходимость возникает в момент выгрузки, когда несколько логов выгружаются в одну систему и применение primary_key из реляционной БД вызвало бы ряд неудобств связанных с коллизиями. Во избежание коллизий используется uuid с солью.
system_type:: В качестве подсистемы выступают сервисы(rest, soap), фоновые задачи, основное приложение и т.д. Т.е. это по существу среда возникновения события, которое следует перехватить.
request_token:: В рамках одного запроса сущетствует токен по которому можно отследить всю активность пользователя в течении запроса.

classmethod get_verbose_msg(log_record, model_instance, **kwargs)¶

Получение человекопонятного описания события.

Т.к. для каждого проекта формирование описания будет разным метод работает через сигнал msg_for_log_signal.

classmethod make_snapshot(instance, event_code)¶

Формирование записи лога о состоянии модели.

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

Параметры:	instance – Экземпляр модели event_code – Событие происшедшее с моделью

classmethod make_system_event(event_code, context_data=None, **kwargs)¶

Формирование записи о событии происшедшем в системе.

Все спецефичные данные о событии обрабатываются через сигнал post_system_event ровно так же, как в методе make_snapshot.

Параметры:	event_code – Событие в системе. context_data (dict) – Доп. данные описывающие событие.

save(instance, *args, **kwargs)¶

Saves the current instance. Override this in a subclass if you want to control the saving process.

The ‘force_insert’ and ‘force_update’ parameters can be used to insist that the “save” must be an SQL insert or update (or equivalent for non-SQL backends), respectively. Normally, they should not be set.

class datalogging.models.LogJSONEncoder(skipkeys=False, ensure_ascii=True, check_circular=True, allow_nan=True, sort_keys=False, indent=None, separators=None, encoding='utf-8', default=None)¶: Наследник JSONEncoder, который умеет работать с ugettext.

signals¶

datalogging.signals.add_datalogger_manager(sender, **kw)¶

Обработчик сигнала class_prepared.

Если модель указана в списке DATALOGGER_SUSPECTS_MODEL, то обработчик добавляет в класс модели DataLoggingManager.

datalogging_compress¶

class datalogging.management.commands.datalogging_compress.Command¶

Класс менежд-команды.

handle(*args, **options)¶: Метод обрабатыюващий команду. На входе ожидаются только именованые параметры переданные из командной строки, в частности options[‘reset’] и options[‘destination’].