ничего не добавлял для вывода пользовательских полей, сами отображались, буде созданы
спасибо на лайк не намажешь
10.07.2013 01:08:04
а что касается b_bp_tracking - это лог бизнес-процессов, он и будет большой, если они активно юзаются и большой период очистки в настройках модуля стоит. это нормально (хотя он избыточен, на самом деле, можно было сделать и полегче и проще в обработке, но это на совести разрабов).
большой b_im_message - тоже нормально, там вся история сообщений и уведомлений на портале
спасибо на лайк не намажешь
|
|
|
10.07.2013 01:04:30
да, b_event великоват, так что скорее всего эта же проблема. желательно иметь PMA, так как для поиска левака надо записи просматривать, через запросы геморно. надо найти спам - должна быть куча повторяющихся записей с SUCCESS_EXEC=N на уволенных сотрудников, посмотреть айдишник мессаги в них, найти соответствующую запись в таблице мессенжера (b_im_message) и поставить признак notify_read=y, чтобы прекратило спамить. после этого можно зачистить этот спам в таблице b_event.
проблема давнишняя, я как-то сообщал о ней, думал, пофиксили давно, видимо нет. вообще это баг ну или обратиться в тп, пусть смотрят и предлагают решение, может баг заодно пофиксят
спасибо на лайк не намажешь
|
|
|
09.07.2013 14:43:29
спасибо на лайк не намажешь
|
|||
|
19.06.2013 10:45:16
Полезную информацию по расширенным правам приводил тут:
возможно, что-то появилось в документации с тех пор, не смотрел
спасибо на лайк не намажешь
|
|
|
14.06.2013 14:26:54
Я его планировал использовать следующим образом: основной поток запускать в одной ветке, а в другой ставить ожидание команды пользователя, это, например, позволило бы по команде пользователя в любой момент прервать основной поток или отозвать документ с согласования или ещё что, так как других возможностей для этого БП не имеют и это их очень ограничивает.
спасибо на лайк не намажешь
|
|
|