Уважаемые специалисты, подскажите правильный путь, как лучше в самописке на УФ вывести разовое предупреждение для всех открытых сеансов? Само сообщение предупреждения будет храниться в регистре сведений, но как сделать так, чтобы после появления записи в регистре, клиентская программа разово вывела окно предупреждения и повторно его не выводила?

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

(17) "если он увидел и нажал ОК, то записи в регистре потрутся" // Это только в предлагаемом тобою - замечу, говняном - варианте они потрутся

может проще какай внешний месенджер заюзать?

(18) и чем же он говняный, а твой такой хороший

(20) Ну, не мой, а другого товарища. Он хорош тем, что мы не добавляем записи в регистр с целью их последующего удаления.

(21) Я так понимаю ты его поддержал.
Вы добавляете записи что бы их хранить?

(22) Есть некоторые виды сообщений, которые имеет смысл хранить

(22) Конечно. Какой иначе смысл в таком базо-данно-онанизме?

(21) Вы решаете задачи по хранению данных о том, что кто то когда то нажал какую то кнопку? хер знает, чем люди занимаются, не буду спорить.

22

та епт, 25 к 24

(25) Неважно, что именно достигается через запись в регистр.
Важно то, что нельзя такую запись потом удалять, чтобы зафиксировать какое-то событие (в нашем случае совершение действия пользователем), т.к. по отсутствующей в регистре записи эту информацию никак не извлечешь (записи там ведь могло и не быть никогда).
Посмотри, например, в типовых - эти всякие всплывающие новости-напоминания с флажком "Прочитано" так и реализованы.

воу. отошел на полчаса называется. вы еще подеритесь)

(17) почему потрутся то. ставь галку и дату ознакомления пиши. в принципе и галка не нужна. достаточно даты

(28) да уж, ты просто гений автоматизации учета

(10) + мне тоже такой вариант больше нравится.
Случай с автором - отправка сообщений - это разовая акция. Автор не указывал необходимости фиксации.

Додумка по поводу поломки, горения компа со стороны Cyberhawk - это лишь для отстаивания своей позиции, не более. Кроме автора никто не знает, для чего это всё делается, какого рода сообщения будут, что будет если пользователь не прочтет или наоборот - если прочтет.

(32) Симпотяги т.е. -)

(32) "Автор не указывал необходимости фиксации" // С таким подходом программист может вообще ничего не делать (не писать в регистр и не читать), а на любой вопрос отвечать, что все сообщения были отправлены, пользователи ознакомлены, вот видите - в регистре записей нет ))

Хотя вот раз такое "Но боязно напороться на блокировку (записи в регистр), если у людей окно выведется одновременно" значит нечто серьезное -)
(34) С таким подходом программист покажет журнал регистрации до первого инцидента -)

(35) Я ж говорю - онанизм какой-то, чтоб о наступлении события лезть в ЖР

Если что-то можно залогировать, то это нужно логировать. Без всяких там ЖР.
В ситуации с собщением в регистре все для этого уже имеется - остается только поле для соотв. пометки замутить и вуаля - дело в шляпе )

(37) Я не люблю избыточность информации

(37) ох ё, что ты за товарищ
Внизу страницы на этом форуме выводятся цитаты форумчан, я бы добавил с пометкой "как делать не надо" вот это
"Если что-то можно залогировать, то это нужно логировать"
я что то все больше от тебя в ужосе ;)

не, это все таки тянет на МУУУУ-ХА-ХА-ХА-ХА бгггг ппц какой то

(38) Так нет избыточности. По событию удаления в ЖР ты не узнаешь, какая именно запись (с каком ключом) была удалена.
Подумай над сценарием, в котором нужно массово разослать сообщения, но без возможности быть уверенным, что они не то что прочитаны, но даже и отправлены? Удаление записи лишает такой возможности.

(39) Тебе почти тот же самый вопрос: подумай над сценарием, в котором нужно массово разослать сообщения, но без возможности быть уверенным, что они получены (прочитаны)?

товарищ, я даже думать над такой лажей не хочу, это задачи, которые делают студенты и то только для того чтобы технический навык обращения с платформой набить. городить из этого кучу таблиц с данными - удел увлеченных чудесами, которые в наш век можно сделать в программе 1С: рассылки, посылки, сообщения на почту и остальная херня. За такую реализацию сначала придет админ и даст п**дюлей, за то что у него начало место на винте кончатся, скл постоянно тухнет и остальные прелести, а потом старшие товарищи добавят. Товарищи были бы первыми, если бы следили за каждым шагом такого "разработчика", ну и тогда админ не пришел бы. Но совсем избежать не получится.

(43) Я вроде задал довольно простой вопрос - замечу - вызванный предложенным тобою вариантом реализации. Т.е. ты предлагаешь сделать рассылку без возможности быть уверенным, что сообщение получено (прочитано). Я спрашиваю, зачем оно надо?
В ответ ты что-то про размер БД говоришь, что вряд ли может являться вообще каким-то аргументом (стоимость диска - копейки).
Пока выглядит так, что ты сливаешься.

Модно стильно молодежно: сервер взаимодействия. Реламентное которое будет в него слать.
А вот всякие экономисты байт - это зло.
Тут на прошлой ИС конференции ребята добавили 2 таблицы весом в 5+гб только для того что бы снизить нагрузку на сервер и это нормально.
Размер одной ссылки 16 байт в ИБ и много вы потеряете при гипотетических 2х сотнях записей в регистре с 3мя полями?

(43) Если у Вас админ лезет в разработку - он профан.
Если он не умеет следить за свободным местом и заранее делать апгрейд - он профан.
Если админ не в состоянии обосновать покупку копеечного по сравнению со стоимостью времени разработчика HDD - он профан, и ИТ директор тоже.
Ситуации когда место на диске ВНЕЗАПНО кончается при текущей разработке говорит о низком качестве ответственных лиц, которым лень настроить мониторинг с оповещениями хотя бы.
Сколько работал ни на одном месте работы ни разу ВНЕЗАПНО место не кончалось, а базы их количество на одном месте работы с 3х в итоге выросло до 150+

ну давай сценарий
вот я, как заботливый отец бедных и обиженных пользователей, положил в регистр запись с информацией, без знания которой пользователи умрут.
вот я, как тот самый пользователь, по обработкеожидания иду в этот регистр и достаю сообщение из этой записи, срабатывает(грубо говоря!) Предупреждение(Информация) (может модальная форма или другие варианты реализации), после нажатия кнопки ОК которой запись удаляется. Если нет записи - была нажата кнопка ОК, в добавок он ничего не сможет делать, пока ок не нажмет.

(47) А вы не пробовали покурить типовой функционал и воспользоватся тем, что есть в БСП, а именно информация об обновлении.

(48) да пох мне на типовой функционал, т к 90% его непригодны, если это не регламетированный учет

Но лично я для конкретно этой задачи, если для клиентов и сервера есть выход в интернет воспользовался бы сервером взаимодействия от 1с, который доступен бесплатно в рамках подписки ИТС.
Обработчики ожидания - зло

(47) "Если нет записи - была нажата кнопка ОК"
Вы неправы дорогой товарисчЪ. Если нет записи - то ее там и не было. И Ok никто не нажимал. Именно эту мысль вам пытался донести Cyberhawk

(49) С вами все понятно.

(51)да ну, вы не уверены, что ваш код работает?

(51) или вы скажете, что Предупреждение() может не отработать и пользователь не увидит окна?

(53) Йес. Не всегда уверен. На сложных системах оттестировать все невозможно.

(54) Всегда ставлю тайм-аут. Тем более для предупреждения. Так чта.... может и не увидеть.

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

(56) ну по необходимости, а вы ВСЕГДА ставите, да?

(45) "Размер одной ссылки 16 байт в ИБ и много вы потеряете при гипотетических 2х сотнях записей в регистре с 3мя полями?"
через полгода будет две сотни тысяч

(46) надо думать вы не профан и все всегда чЁтко

(59) 1) Использовать регламентированное время хранения прочитанных сообщений и раз в какой то период прочитанное чистить.
2) Так же чистить сообщения которые никогда не найдут адресата (уволен и тд)
И безмерного разрастания базы не будет

(47) Это не сценарий. Ты просто более обширно повторил свой способ реализации (с удалением). Я же спрашивал, зачем такой онанизм с отправкой сообщения, если через какое-то время по состоянию данных в базе нельзя определить, было ли это сообщение получено или вообще никогда и не было отправлено?

(60) Я могу на вскидку сразу накидать как минимум 3 варианта реализации данной задачи, выбор конкретной - будет зависеть от конкретного ТЗ.
И да я этим занимаюсь профессионально с соответствующей записью в трудовой и наличием портфолио

(61) 1. здорово, только кибехавку не говорите, а то он их собирает
2. хрена се, вести у себя в блокнотике небольшой учетик персонала?

(61) во во в (62)

(64) Условия на конфигурацию не оговаривались, ведется учет или нет не оговорено. Время хранения тоже не оговорено. Это одна из реализаций

(63) админите?

+(67) и пишите одновременно?

Нигеде не говорится что отметка прочтения должна храниться вечно

(67) ни то ни то

(66) эххх.. как же ты будешь понимать уволился он или нет

По этому была предложена наиболее распространенная схема, обычно эти важные сообщения имеют срок жизни, где то месяц, где то пол года.
Можно и "вечное" хранение реализовать.
(71) На конфигурациях с БСП если учет ведут не лунатики, то люди которые больше никогда не войдут помечаются галкой - недействителен. Если нетленка - другой вопрос

(65) А чего в (62)? :) Ты-то предлагаешь _сразу_ после прочтения удалять. Однако эта информация (понимать, прочитано или нет) скорее всего понадобится еще спустя какое-то время (допустим, неделю). Понятно, что спустя несколько месяцев и лет скорее всего оно уже нигде не нужно.
Я тебя и спрашиваю - приведи пример такой рассылки, где регистр под содержание сообщения и список получателей уже сделан, но и при этом не важно уже потом, получено оно или нет.

(73) ну как бы ты не автор задачи, тут уже начинается GIGO

(0)
Всё не читал.
Систему взаимодействия уже предлагали?

В новых версиях платформы реализовано оповещение клиента с сервера.

(75) Предлагал, но тут староверы

(73) Например уведомлении об акции в рознице, срок жизни которой 3 дня

Через 4 дня она уже мертва и сообщение не актуально

(62) тоже есть сомнения, что твой код пишет в базу? ((

(76)
ясно
перекрестился тремя перстнями и иду дальше

(73) да я задолбался тебе писать, ты какой то стремный, тебе говоришь говоришь, а ты одно заладил, это ж не первый раз уже "Опиши да напиши"

(59) "через полгода будет две сотни тысяч"
Вот не поленился. Посчитал.
Рабочее время в месяц = 168 часов
Количество часов за 6 месяцев = 1008
Сообщений в час = 198
При количестве пользователей = 50, каждый пользователь получает примерно 4-е сообщения в час.
Вы там что - чат в 1С замутили?

При этом объем занимаемый отметками будет грубо = 3,2 гигабайта. Вам жалко 6 гиг в год?

+ 81 тебе что готовое решение надо дать? могу продать

(77) (78) Так это со сроком актуальности. Я это в (11) предлагал, но это не особо относится к заданному ранее вопросу.
Про "уведомление об акции в рознице" - неужели тебе может понравиться такое решение, при котором записанные в регистр сообщения через несколько минут удаляются и в регистре по итогу остается пара еще не вошедших в базу пользователей?

(82) не далее как сегодня отключал полнотекстовый поиск на серверных копиях рабочих баз, т к один пришел развернул копию, другой и так далее

(79) Конечно. И не только что он "пишет в базу", но и для кого пишет (как список получателей сформирован)

(52) ну вот тебе типовой функционал в (84)

Мну интересно. А задллянафига писать в регистр, что бы тут же удалить? Просто регистр использован как хранилище на время доставки? Так может транспорт поменять? Например слать на мыло? Ну или с помощью сервера взаимодействия?
Ну раз пофиг прочитали или нет?

(81) Так ты по сути говори и тогда все будет тип-топ. Пока ты так и не описал ситуацию, запрошенную мною как минимум дважды. Не сливайся, поделись кейсом-то.

(84) Да и это было ТЗ.
Я этих систем оповещений штук 10 в свое время абсолютно разных реализовал.
и с "вечным" хранением, и после прочтения сжечь. Везде это были реально обоснованные требования.

+ (85) винт - это же не все далеко

(88) ННе было в тот момент сервера взаимодействий в природе.

(88) да почему же его должны не прочитать, мне интересно

(85) "один пришел развернул копию, другой и так далее"
Ну так наколхозить и мы умеем. Но это же не должно быть образцом?

(89) да хрен тебе

(95) Слив засчитан (с) :)

(90) После слива товарища lEvGl может ты поделишься кейсом "после прочтения сжечь"? :)

(94) ну а где он "образец"
так гиги незаметно и сливаются, а потом на выходных Оп и сервер болт прописал, все встало, никого из обслуживающих нет

(91) Скажи это базе в 25+ ТБ с которой я работал и которая вполне себе шустро шуршала, да серваки там были неплохие, но база вся целликом в памяти СКЛ не болталась.
Все зависит от задачи. Ставьте корректно задачу вам подберут приемлимое решение.
А абстрактные задачи я и на совещаниях наслушаюсь.

(97) а что я тебе должен рассказать как я это делаю? повториться с хреном? либо продать могу, говорил уже

(100) Вроде выше довольно понятно описано, что от тебя просилось. Могу только рекомендовать перечитать мои сообщения.

(86) "Конечно. И не только что он "пишет в базу", но и для кого пишет (как список получателей сформирован)"
Вот прям подходит

(92) При чем сервер взаимодействия? Чаты в 1С еще в клюшках писали. На справочниках писали. Все так. С реквизитом "ознакомлен". И никто от нехватки места именно по причине системы обмена сообщениями не похудел.

(97) Ну смотри, крупнейший розничный вендор с файловыми на местах. Как поннимаешь - особо много в файловой не похранишь. Постоянно проходят акции, в день может и несколько десятков быть. Сеть продала товаров на какую ту сумму за период - всем бонусы, не продавала нет бонусов.
Акциии рассылались скриптом на машины. записывались в определенный специально для этого регистр. После показа запись удалялась, отметка о прочтении работником уходила в специальное место.
Файловая не растет бесконтрольно - все счастливы.
И систем оповещения было около 10. Были "Вечные", были периодические, были разовые. Всякие. Только делалось это с прицелом на то, что на рабочих местах машины очень слабые, базы файловые. Приходилось очень скурпулезно разрабатывать структуру данных. И это работало, работает и будет работать. И да на сеть в 2к+ точек было 5 разработчиков.
(100) Слито, не позорься.
(103) Есть такие люди - экономисты байт. Очень им трудно что то доказать, пока не наедятся - бесполезно.

(104) Спс за кейс. Но и в нем запись не удалялась безследно :)

(105) Из именно файловой базы 1с - бесследно. Но на систему, куда это уходило - сторонняя разработка - бизнес требование. Всегда можно было отключить передачу в сторонню систему, причем на всех точках в течение 10 минут

(105) И сделано было так просто и хитро, что просто гениально на самом деле.
Но это будет уже слив по NDA, извини.

(104) да, очень развернуто описал, все сразу стало понятно

+ что значит наедятся, мне голову выносят из за нехватки железа с формулировкой "изобрети велосипед - так чтобы приемлемо работало на том что есть"
а апгрейд стоит немало

(109) Вот это уже предметный разговор, соответственно систему надо оптимизировать под минимальные затраты пространства.
Смотри, если сообщения дожны показываться всем один раз. Лучше это сделать при входе, не рекомендую плодить лишние обработчики оповещения.
Структура - Справочник - Оповещения.
Реквизиты - всякий текст.
ТЧ Ознакомленные Состав ТЧ - одна колонка - справочник ссылка Пользователи.
Делаешь или индекс или критерий отбора по этой колонке(это и есть соль)!!!
При входе и нажатии кнопки Ознакомлен или ставишь в очередь задание на добавление этого пользователя в ТЧ (рекомендуемый способ состав одно рег задание и один регистр сведений который стремится быть пустым) или сразу добавляешь его в ТЧ (не рекомендуемый, в период массового захода возможны ожидания на блокировках если ТЧ будет большая)
Запрос написать, сверстать форму, решить вопрос что делать ели оповещений должно быть несколько - не буду - это уже рутина

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

Так же очень сильно зависит от количества пользователей системы

(110) да, спасибо

индексирование вобще  - не только соль, но и сахар

(113) Приправить всякими реквизитами по требованию. Но 10к записей за год это простите 30 сообщений в календарный год, рекомендую продумать регламент по очищению справочника, ибо через 5 лет, как Вы понимаете 99% будет не актуально.

30 сообщений каждый календарный день

ну у меня за день 200 наверно будет (в почти реалтайме задержка в 5 минут, рег. задание), не считал

ну плюс отчеты формируются и на почту летят с вложениями из экселя, хтмла и прочими радостями по расписанию 3 раза кажется днем, несколько каждые 5, 6, 8 часов и тд и т д...

мля, о чем мы говорим?

спасибо за доброжелательность конечно, но это давно пройденный и решенный вопрос, я же говорю - это удел студентов, которым надо научиться с программой обращаться. Возможно где то это и нужно (как говорили реклама от 1С - тут я понимаю, они делают рекламу, получают за это деньги, а хранятся все эти настройки с ПРОЧИТАННЫМИ и не очень оповещениями у клиента - в файле, на сервер да где угодно, а они слили и забыли), но в учетных системах на эту рекламу только плюются и ищут скорее где галочка "не показывать" (которая, с*ка, где то лежит в базе и занимает место:))