ДП - индикатор отправки сообщения

[Vintik]

Здравствуйте.

Хотелось бы в ДП увидеть нечто индикатора отправки. Если на получения это не важно т.к. пока оно полностью не пришло, его клиент не видит, но вот на отправку надо т.к. не раз говорят были случаи, когда клиенты отправляют письмо и как только оно "пропало" - думают что всё ушло и бывает могут выходить из ДП и т.п.. И только по МФТП видно что там ещё оно идёт и идёт.... НО это видят те кто понимает (кого чуть чуть обучили). 

Потому очень удобно было бы вывести на передний план статус отправки и это видели клиенты.

На статусы тоже бывает на смотрят и им они не о чём не говорят, ну есть там "У" и что? Оно же в отправленых (или сейчас в вер.4 там картинки). Не кто не будет смотреть, что там очередь в МФТП и .п. - это надо всё вывести в ДП и это собственно не так и сложно, отдельно "статус доставки" в % выводить на пример и если там 0% то это и есть "У" т.е не куда не ушло, если где то 25%, 50% и т.п. значит ушло не всё а когда 100% вот тогда уже и и должен появляться значёк "О"

Если где то вставить "лампочку" которая будет говорить что что то принимается, то тоже было бы не лишним, потому что были и такие случая, звонят (особенно те кто запускают випнет раз в 3-6 месяцев) и говорят "Нам что то отправили, а мы запустили и нет не чего, не могли бы проверить.." и пока начинаешь выяснять что и как они "Ой, всё пришло пока к вам позвонила и говорила...", а дело понятное, что не запускают долго, а если письмо большое то они может долго загружаться, что и происходило. (потом клиента научил смотреть на индикатор в машинке и уже они перестали часто звонить, т.к. запускают и смотрят как там полосочка заполняется).

[MORO]

Здравствуйте.

Не согласен. Само собой, сугубо IMHO.

В ДП есть атрибуты писем, их более чем достаточно (к слову, в 4 версии есть как картинки, так и старые "буковки" - просто их нужно включить).

Я из всего Вами описанного прихожу к выводу, что "проблема" не в функционале ДП, а в том, что за ДП сидят обезь.... пардон - недостаточно квалифицированные пользователи. Ибо, без "чуть-чуть обучили" оператора вообще подпускать к ДП нельзя. Это СКЗИ всё-таки.

[Vintik]

Понятно что нельзя, но у вас ЗП 3-5 т.р. ? На вас куча бумажной и прочей работы, которую требует и не хочет не кто делать (или некому т.к. вы точно за 4,5 т.р. даже плювать не станете) потому часто могут работать пенсионного или близко... в 80% СКЗИ это всё фикция и отмывка средств...

Так что интуитивно понятный интерфейс надо и это не сложно сделать, а то что есть (вы отписали) это хорошо и тоже в ЭДО часто выручает, но отправляйте сканы на 50-300 МБ хотя бы из области, где 1 МБ это фантастика, часто хорошо если 256 КБ держится...

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

[MORO]

Так Вы всю эту "горячечную лирику" изложите в убедительной форме и направьте в ФСБ России. Глядишь, регулятор проникнется Вашими доводами, "прослезится" и выпустит новые редакции РД, в которых снизит требования к эксплуатации СКЗИ, разрешив допускать к самостоятельной работе с ними кого попало, без изучения элементарных правил эксплуатации (именно элементарных, т.к. прочесть юзер-мануал и запомнить как пользоваться атрибутами писем в ДП - ума нужно даже меньше, чем для просмотра "Дом-2").

А если серьёзно, то, мягко говоря, не совсем понятно какое отношение столь красочно описанные Вами суровые условия имеют к тому факту (опять же, следующему из Вашего описания), что пользователь тупо не знает (или не хочет знать - лень прочесть десяток страниц с картинками, что скорее всего), что:

а). факт отправки письма прекрасно индицируется соответствующим атрибутом этого письма в "Исходящих",

б). для того, чтобы входящие письма ДП поступали своевременно, программа "Деловая почта" (или "Монитор", или "Cryptoservice") должна быть запущена постоянно - чтобы MFTP работал, в течение всего времени сеанса пользователя ОС, а не запускаться ручками время от времени и тут же, этими же ручками, закрываться (для особо "талантливых" юзеров, ДП - в "Автозагрузку")?

Каким образом низкая пропускная способность канала и прочие "суровости" Сибирской тайги влияют на то, что юзеры банально пользоваться вверенным им софтом не умеют, имея при этом на руках шикарный комплект инструкций?

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

[Vintik]

Не прекрасно - вы почтовиками пользовались нормальными? Там я отправляю и вижу 0-100%.. раз и точно значит всё ушло!

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

[MORO]

Ваше субъективное понятие о "нормальности" ПО - всего лишь частное мнение, не более. Каждому нравится своё. На всех не угодишь. Это не упрёк, ни в коем случае. Это просто констатация, без эмоций. То же самое относится и к мнению моему, само собой.

Аргументы нужны. Веские. Обоснованные. А их пока не прозвучало.

Да и понял я Вас прекрасно. Ваше предложение не бином Ньютона, отнюдь. Но понять вовсе не означает соглашаться.

Резюмируя. По моему личному мнению (которое я здесь и излагаю, хочется Вам этого или нет) запрошенный Вами функционал избыточен, и не стоит затрат ресурсов (даже небольших) для его реализации. Решать, безусловно, ИнфоТеКС`у. Но я на 99% убеждён, что Ваши предложения не пойдут в продакшн, и даже в разработку. И это будет тот редкий случай, когда я буду согласен с ИнфоТеКС`ом по части функционала клиентского ПО ViPNet. 

P.S. Вот кем-кем, а программистом никогда в жизни не работал, и не планирую.

[basid]

1 час назад, Vintik сказал:

Не прекрасно - вы почтовиками пользовались нормальными? Там я отправляю и вижу 0-100%.. раз и точно значит всё ушло!

У "нормальных почтовиков" отправка не гарантирует доставки.
Никогда не получали "сообщение невозможно доставить" через трое суток после отправки?

[Vintik]

Если делаю 2 пункта , прислать отчёт и увидомление, то всё приходит. Но тут я не о том говорю, а о том что в нормальных я вижу в реальном времени как уходит на сервер - вот что надо. А ДП это не панацея, и тут всё теряется, то ключи не обновили, то ошибка и не смогли расшифровать, проблем хватает повсюду, это понятно.

4 часа назад, MORO сказал:

Резюмируя. По моему личному мнению (которое я здесь и излагаю, хочется Вам этого или нет) запрошенный Вами функционал избыточен, и не стоит затрат ресурсов (даже небольших) для его реализации. Решать, безусловно, ИнфоТеКС`у. Но я на 99% убеждён, что Ваши предложения не пойдут в продакшн, и даже в разработку. И это будет тот редкий случай, когда я буду согласен с ИнфоТеКС`ом по части функционала клиентского ПО ViPNet

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

Это я уже давно заметил и не только я, потому тех.п. инфотекса всегда стоит где то ниже... вот взять производителей Даласа - что не напишешь, всё рассмотрят и если есть возможность тут же реализуют!!! Даже вот сказал что шнурок бы надо на сброс двойной, а то одинарный вы туда и всё - а как сбрасывать при сбое? - и тут же в след редакции вижу такой шнур, все поправки в документации учитывают и редактируют - ну просто сказка, по АУРА так же отписал что в 1,2,4 очень не удобно и надо исправлять в 1,2,6 всё учли и исправили (жалко что пока она ещё не прошла сертификацию)... по Аккорду не мало было замечаний - всё стараются поправить и исправляли.

А тут 2-3 года писал чтоб как то поправили слёт динамики в сер. 3,2 последней и то что не работает там приоритет выбора.. - ааа всем пофиг (вернее другие сборки то поправили, но сертификация то дорога...) а то что это реальные глюки и как же так же безопасность для чего типа это... 

Да и вы сами же понимаете СКЗИ это CSP - ВОТ что ФСБшникам важно, а ДП и КЛИЕНТ это просто шкурки использующие его механизмы. Ед. что выболняет Клиент сам по чебе это как МЭ если используется, но в 50% его всегда переводили в режим 4 т.к. как МЭ он не нужен был не кому, только как СКЗИ.

Потому на ваше резюме моё такое: Наше дело предложить ваше отказаться. :-) Т.е. соме народное и показывающее отношение. Была бы ещё где то ДП и связи с ПФР и прочими, то давно бы могли выбрать другое люди, а так альтернатив нет, монополисты практически.

Сам продукт не плохой и в целом работает и работает, очень даже не плохо если его настроят. Вот сколько лет уже все просят ДП на линуксе, координатор то не плохо там работает, ну сделайте ДП и всё забудут про винду, но не кто и не чешется, потому что конкуренции нет.

[basid]

Основная проблем заключается в том, что транспортный модуль (жизненно важный элемент сети) работает в сессии пользователя.
Решением, по логике, должно стать превращение транспортного модуля в службу и изменение политики регистрации в сети ViPNet.
А именно - узел сети ViPNet обязан принимать минимальную информацию о сети ещё до регистрации. Просто по факту установки узла А сети Б на данном устройстве.

[Vintik]

24 минуты назад, basid сказал:

Просто по факту установки узла А сети Б на данном устройстве.

Любите вы всё усложнять. Да там всё уже сделано у них и прекрасно работает! Вы же в том же МФТП откройте при отправке и увидите статус загрузки и отправки.

Вот и всё!!! В Клиент надо всего лишь добавить полоску "прогресс бар" и они будет данные с МФТП дублировать - вот и всё, делов то на пару минут. (Конечно образно, но те кто программировал поймут). Тут не надо не чего изобретать - всё уже сделано давно.

[MORO]

3 часа назад, basid сказал:

Основная проблем заключается в том, что транспортный модуль (жизненно важный элемент сети) работает в сессии пользователя.
Решением, по логике, должно стать превращение транспортного модуля в службу и изменение политики регистрации в сети ViPNet.
А именно - узел сети ViPNet обязан принимать минимальную информацию о сети ещё до регистрации. Просто по факту установки узла А сети Б на данном устройстве.

А вот тут согласен. Теоретически. Было бы удобно конечно, если бы mftp работал самостоятельно как системная служба.

[MORO]

2 часа назад, Vintik сказал:

Любите вы всё усложнять. Да там всё уже сделано у них и прекрасно работает! Вы же в том же МФТП откройте при отправке и увидите статус загрузки и отправки.

Вот и всё!!! В Клиент надо всего лишь добавить полоску "прогресс бар" и они будет данные с МФТП дублировать - вот и всё, делов то на пару минут. (Конечно образно, но те кто программировал поймут). Тут не надо не чего изобретать - всё уже сделано давно.

Человек про работу mftp системным сервисом пишет, Вы про прогресс-бары. В огороде бузина, а в Киеве дядька... Каждый о своём. )))

[Vintik]

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

[MORO]

32 минуты назад, Vintik сказал:

Не знаю кто про службу пишет

Попробуйте читать сообщение, на которое отвечаете - будете знать:

4 часа назад, basid сказал:

Основная проблем заключается в том, что транспортный модуль (жизненно важный элемент сети) работает в сессии пользователя.
Решением, по логике, должно стать превращение транспортного модуля в службу и изменение политики регистрации в сети ViPNet.
А именно - узел сети ViPNet обязан принимать минимальную информацию о сети ещё до регистрации. Просто по факту установки узла А сети Б на данном устройстве.

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

За сим откланиваюсь. Всего наилучшего.

[basid]

14 часов назад, Vintik сказал:

Вы же в том же МФТП откройте при отправке и увидите статус загрузки и отправки.

Чтобы открыть окно MFTP, пользователь должен зарегистрироваться в системе.
А я хочу, чтобы и сервера и даже рабочие станции нормально принимали служебную информацию (списки отзыва, связи и т.д. и т.п.) вне зависимости от самого ненадёжного звена (человека).

P.S. Нет, автоматический вход в систему это не решение, это костыль.
На сервере Novell Netware (<=4.x) такой вариант был очень гармоничен, а для многопользовательской системы это отвратительный костыль.

[Vintik]

basid я вас понял, но для этого надо отдельную тему наверно создать "пожелание" - чтоб MFTP можно было работать отдельно как служба, в не зависимости от компонентов Випнет Клиента. Кстате вы правы ещё в том, что не работает он так как теоретически должен, т.е. в теории можно отдельно ставить ДП и "радоваться" - но не тут то было, и пока не запускаешь Випнет Клиента не чего он не принимает сам, как вы вернно заметили ни справочники, ни даже письма которые должен, это я заметил с 3-й версии и не только в ДП, но и в РегПоинте - там точно так же, должен но не обязан и работал криво без ВипнетКлиента.

Ед. что мне пока сложно при таком решении (когда МФТП сам по себе) как он будет понимать от кого ему работать если на пример на станции не только несколько Вин пользователей (тут вроде всё ясно - они не в счёт) но если несколько випнет пользователей - и тут проблема. ВипнетКлиент я так понял ограничен одним пользователем и было замечено если его запустить на станции где несколько пользователей, то там действоет правило "кто первый встал того и тапочки" и чтоб потом второму с ним поработать, надо у первого его вырубать и запускать под вторым.

Получается при решении "отдельного МФТП" надо уже его серьёзно отделять, как отдельный независемый компонент и в нём прописывать ещё отдельно и авторизацию. Кстате было бы тоже не плохо тогда в нём сделать доп. функцию подгрузки сторонних CRL, т.е. то что люди БАТниками делают и разными скриптами.

[basid]

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

[Vintik]

Тут можно оспорить вопрос, т.к. узел не может быть без пользователя или я чего то не понимаю? Даже такая аномалия точно была. Я про то, что как этому узлу запускаться? Авторизацию в любом случае надо производить. Понимаю что на узел можно и 100 пользователей завести и они будут одну ДП читать если она на узел приходит. Вот я что не могу понять.

[Echo]

Все и так, и не так....

На узле могут работать несколько пользователей, для каждого формируется свой набор персональных ключей, с которыми он в ViPNet будет авторизовываться. И адресные книги ДП их всех покажут.

ДП - пользовательское приложение. MFTP - приложение узла и обслуживает много компонент, которые для Пользователя скрыты под общим названием ViPNet Client.

Поэтому с т.з. ДП передача конверта в MFTP и есть отправка. Соответственно, если на конверте стоит статус "У", то конверт подготовлен к отправке, но из ДП не ушел. А для статуса "О" прогресс-бар бессмысленен - передача файла с диска на диск занимает меньше времени. чем отрисовка этого процесса.

Что касается MFTP и его прогресс-баров...

Теперь о грустном. До версии 4, если я правильно помню, MFTP запускался автоматом при старте ViPNet Монитор и вывешивал в трее свой значок. В версии 4 его убрали и MFTP запускается теперь скрыто. Однако, возможность запуска интерфейса MFTP вручную и настроек оповещений о приходе писем осталась, ну так это вы тут пропатченные и прошаренные, и вам это нужно. Но вы ошибаетесь, если предполагаете, что пользователям в подавляющем большинстве нужно за этим следить. Так что скрытие MFTP было не случайным. А себе можете запустить его из меню Монитора: Приложения-Транспортный модуль или из ДП: кнопкой Отправить-получить...

"они будут одну ДП читать если она на узел приходит. Вот я что не могу понять."  - А это как настроите и какую задачу решаете. Кому-то так и надо работать

"MFTP можно было работать отдельно как служба, в не зависимости от компонентов Випнет Клиента"  - не можно, MFTP работает не сам по себе, а как компонент СКЗИ. без других компонент ViPNet это будет неработающий сервис. Поэтому без разницы, как он запускается.

В 31.01.2018 в 20:51, basid сказал:

Чтобы открыть окно MFTP, пользователь должен зарегистрироваться в системе.
А я хочу, чтобы и сервера и даже рабочие станции нормально принимали служебную информацию (списки отзыва, связи и т.д. и т.п.) вне зависимости от самого ненадёжного звена (человека).

P.S. Нет, автоматический вход в систему это не решение, это костыль.
На сервере Novell Netware (<=4.x) такой вариант был очень гармоничен, а для многопользовательской системы это отвратительный костыль.

"Низззяяяяяя": за действия над информацией, обрабатываемой СКЗИ, за сами СКЗИ, за их работу, за операции на АРМ отвечает человек персонально. Это права и обязанности пользователя СКЗИ, и их обойти не удастся.

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

Так что варианты есть, но так под них и систему надо строить посложнее чем развернуть ViPNet "по умолчанию".

[basid]

Человек и ответил, разместив узел в серверной с ограниченным физическим доступом и, за счёт этого, получил возможность автоматически авторизовывать пользователя ViPNet.

Если просто почитать варианты оформления КЭП, то можно заметить, что кроме людей существуют информационные системы.
Зачем информационной системе, которая, например, представляет собой веб-сайт, работающий в виде службы и защищённый ViPNet-ом на уровне связей и правил пакетного фильтра, "фиктивный человек", который "регистрируется" на консоли только для того, чтобы узел не выпал из сети?

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

[Vintik]

Да мне в этой теме не важно МФТП видно или нет, служба он или приложение, меня это не волнует.

Мне надо чтоб пользователь видел "ЖИРНЫЙ БОЛЬШОЙ КУЛАК" перед глазами, который говорил ему "Только попробуй закрыть ДП пока не ушло письмо на сервер, сразу фингала получишь!" 

Вот и всё.

[Echo]

[Vintik]

Спасибо Echo, но это понятно и хорошо, но это не то - Пятница, конец раб. дня, тут вспоминают что не отправили, кидают и даже если свернуть - когда письмо упаковано, пропадет "процесс" - ПК сразу выключается и человек со спокойной совестью думает, что всё ушло и это тут на востоке конецу  уже, а там на западе ещё 3-5 часов работы и как раз поработают.

Но письмо только упаковалось и машинка только начала его перевозить - но кто то решил этого не надо видеть клиенту и всё скрыто, так что он и не виноват.

Лано - нет так нет, это же просто предложение.

[basid]

Если в локальной сети есть координатор, то письмо "уезжает" на координатор со скоростью локальной сети.

P.S.
Да, координатор должен быть на каждой площадке, где находится более одного клиента.
Необязательно аппаратный, скорее - наоборот, но - должен быть.

[KIV]

Свои 5 копеек вставлю: есть у нас сеть в которой более 200 клиентов, все стоят в разных территориально местах по одной штуке. Штук 80 из них на спутнике. А теперь представьте как людям объяснить, что они должны дождаться ... неизвестно чего без индикации при получении письма и его отправки. В этом случае все вспоминают The BAT! который перед закрытием показывает как завершает все свои дела.