Windows DispJournal

А будет ли функционал взаимодействия с клиентом онлайн, через сайт например?
Что-то вроде service desk , только заточенную под лифтовую тематику.
 
Здравствуйте.
1.А где взять клиентскую версию ? Или обязательно устанавливать на клиентской машине и серверную часть?
2.Если сервер работает на одном компьютере, а спульт на другом, то какие настройки указывать в спульт ? Localhost или IP (Домен) компьютера где установлена серверная часть? Имя пользователя и пароль в lkdsdomain и Dispjournal должны совпадать?
3. Можно ли сформировать заявку непосредственно из LiftJournalClient, или только из Spult?
 
Последнее редактирование модератором:
anatoliy написал(а):
А будет ли функционал взаимодействия с клиентом онлайн, через сайт например?
Что-то вроде service desk , только заточенную под лифтовую тематику.

Пока в планах такого функционала нет.

andreyzv написал(а):
Здравствуйте.
1.А где взять клиентскую версию ? Или обязательно устанавливать на клиентской машине и серверную часть?
2.Если сервер работает на одном компьютере, а спульт на другом, то какие настройки указывать в спульт ? Localhost или IP (Домен) компьютера где установлена серверная часть? Имя пользователя и пароль в lkdsdomain и Dispjournal должны совпадать?
3. Можно ли сформировать заявку непосредственно из LiftJournalClient, или только из Spult?


1. Дистрибутив единый.
2. Не очень понимаю зачем так делать. IP машины с клиентом электронного журнала надо вписать в SPult, но таких тестов не проводилось и задача так не стояла при разработке. Spult и клиент электронного журнала на одной машине, в них работает диспетчер.
3. Пароли и логины могут быть любыми - это отдельная независимая система.
4. Только из SPult.
 
Arcady написал(а):
2. Не очень понимаю зачем так делать. IP машины с клиентом электронного журнала надо вписать в SPult, но таких тестов не проводилось и задача так не стояла при разработке. Spult и клиент электронного журнала на одной машине, в них работает диспетчер.

Я наверно некоректно задал вопрос.
Если dispournal server запущен на компьютере1 с ip1.1.1.1и портом 4444 , а spult и dispjournal klient на компьютере 2 (связь с сервером через интернет,) то в настройках spult указывать ip адрес компьютера1, где запущен dispjournalserver? Или localhost:4444 ( или можно без порта)?
 
andreyzv написал(а):
Я наверно некоректно задал вопрос.
Если dispournal server запущен на компьютере1 с ip1.1.1.1и портом 4444 , а spult и dispjournal klient на компьютере 2 (связь с сервером через интернет,) то в настройках spult указывать ip адрес компьютера1, где запущен dispjournalserver? Или localhost:4444 ( или можно без порта)?


Пока нужно вписывать http://localhost:48084 в SPult. SPult шлет по этому адресу xml с данными.
Клиент электронного журнала принимает эти пакеты и перенаправляет в сервер, а тот в свою очередь складывает эти данные в БД и раздает их остальным клиентам.
 
Arcady написал(а):
Пока нужно вписывать http://localhost:48084 в SPult. SPult шлет по этому адресу xml с данными.
Клиент электронного журнала принимает эти пакеты и перенаправляет в сервер, а тот в свою очередь складывает эти данные в БД и раздает их остальным клиентам.

Понятно, спасибо.
А нельзя разве без этих манипуляций с локалхост? напрямую данные пересылать из Spult в Dsipjournal klient?
 
Попробовал немного. Сразу скажу, что необходимо на мой взгляд:
1. поле дополнительного описания заявки (раскрытия подробностей) в которое диспетчер может внести свои данные.
2. Возможность изменять , дополнять список основных неисправностей администратором.
3. Возможность редактировать заявку диспетчером и администратором.
4. Возможность вносить дополнительные комментарии механиком, что бы у диспетчера была информация о причинах и сроках исполнения заявки (когда появиться клиент для мобильных устройств).
5. Ввести права наблюдателя.
 
andreyzv написал(а):
Попробовал немного. Сразу скажу, что необходимо на мой взгляд:
1. поле дополнительного описания заявки (раскрытия подробностей) в которое диспетчер может внести свои данные.
2. Возможность изменять , дополнять список основных неисправностей администратором.
3. Возможность редактировать заявку диспетчером и администратором.
4. Возможность вносить дополнительные комментарии механиком, что бы у диспетчера была информация о причинах и сроках исполнения заявки (когда появиться клиент для мобильных устройств).
5. Ввести права наблюдателя.

1. Есть такое - поле "уточнение" редактируется на этапе назначения исполнителя. На этапе закрытия - поле "комментарии".
2. Утверждается, что любую неисправность можно распределить в одну из 13 из списка. Хотя изначально проектировалось как вы описали.
3. Для чего? Вы не имеете право вмешиваться в данные заявки. Если она заполнена ошибочно - закройте ее и создайте новую.
4. Это понятно.
5. Что должен уметь делать наблюдатель? Отчеты должен уметь строить?

andreyzv написал(а):
А нельзя разве без этих манипуляций с локалхост? напрямую данные пересылать из Spult в Dsipjournal klient?

Решили воспользоваться общим инструментом экспорта данных для сторонних систем.
 
Arcady написал(а):
1. Есть такое - поле "уточнение" редактируется на этапе назначения исполнителя. На этапе закрытия - поле "комментарии".
2. Утверждается, что любую неисправность можно распределить в одну из 13 из списка. Хотя изначально проектировалось как вы описали.
3. Для чего? Вы не имеете право вмешиваться в данные заявки. Если она заполнена ошибочно - закройте ее и создайте новую.
4. Это понятно.
5. Что должен уметь делать наблюдатель? Отчеты должен уметь строить?
Решили воспользоваться общим инструментом экспорта данных для сторонних систем.

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


При формировании отчета по заявкам поле выбора времени сделать наверное отдельно, и/или при выборе даты , ставить его по умолчанию 00:00 для поля ОТ. Для поля ДО по умолчанию текущее системное.
 
Последнее редактирование модератором:
andreyzv написал(а):
1. В это поле переноситься текущее состояние из spult, и не позволяет внести какие либо корректировки в стадии формирования, только если свернуть (нажав на красное поле) и заново раскрыть окно, тогда появляется возможность изменить данное поле, на фоне основного списка заявок. И кстати, очень не удобно в такую форму что-то вносить, более наглядно и практично вносить в многострочную.
3. Тогда хотя бы на стадии формирования завки, до того как назначить исполнителя, была бы возможность отменить ее. Вообще, на мой взгляд, формировать заявку лучше бы было в таком же примерно окне, как и ее закрытие, и в нем кнопки создать, отменить, отложить ну или что-то подобное.
5. Ну вроде того. Или просто просматривать заявки.
При формировании отчета по заявкам поле выбора времени сделать наверное отдельно, и/или при выборе даты , ставить его по умолчанию 00:00 для поля ОТ. Для поля ДО по умолчанию текущее системное.

1. и 3. Знаю про многострочность и узкие столбцы, но это требования которые выполнять пришлось в обязательном порядке.
 
Arcady написал(а):
1. и 3. Знаю про многострочность и узкие столбцы, но это требования которые выполнять пришлось в обязательном порядке.

Странные требования :( . Вообще исходить надо из того что пользоваться данным программным продуктом, будут люди весьма посредственно знакомые с компьютером, и электронный журнал заявок призван облегчить "жизнь" и повысить производительность труда диспетчера, иначе какой смысл в этой программе и на мой взгляд в текущем исполнении не совсем удобно пользоваться. Но это моё конечно видение данного вопроса. Будем ждать комментариев других, и развития данного направления.
 
andreyzv написал(а):
....Вообще исходить надо из того что пользоваться данным программным продуктом, будут люди весьма посредственно знакомые с компьютером, и электронный журнал заявок призван облегчить "жизнь" и повысить производительность труда диспетчера, иначе какой смысл в этой программе ...
Золотые слова, их бы в камне высечь.
 
Еще вот предложение, по поводу отложенных заявок. Почему бы не сделать так же как майкрософт в своей ОС для нескольких окон одного приложения. При наведении мышки на красное поле, появляются миниатюры окон формирования заявки, которые были отложены до назначения исполнителя, с возможностью выбора любого из них. Такое поведение предсказуемо и ожидаемо для пользователя современной версии ОС. Теоретически таких окон не должно быть много, так как заявка может быть отложена диспетчером на не продолжительное время, если есть более важные вопросы ( например множественные застревания), и после в обязательном порядке, либо назначен исполнитель , либо отменена. А при нажатии на это поле, уже открывается основное окно, в котором списком ( так же как и со всеми заявками) отображаются отложенные , при нажатии на пункт этого списка открывается основное окно формирования заявки, и заявка либо отправляется исполнителю с корректировкой уточнения, либо отменяется ( если все таки режим отмены будет введен) Это что касаемо
Frontend .
А вот касаемо серверной части , может внести перекрестные права доступа отдельно пользователи, отдельно группы.
Например три участка диспетчер1 имеет доступ и может отправить заявку механикам или аварийной службе из участка 1 и участка 2. А вот прораб уч 1 может просматривать (или даже формировать, изменять исполнителя путем создания новой заявки) только по уч1.
А вот третий участок полностью обособлен и диспетчер3 может создавать заявки только в уч 3.
Конкретно для меня это не актуально, но есть же компании у которых еще более сложная иерархия.
И в указанном примере с прорабом и изменением исполнителя,
а так же комментариями механиков о процессе исполнения заявки, идеально конечно использовать принцип ,например знаменитой системы OTRS, с выводом всех цепочек и этапов прохождения заявки до ее
закрытия, но это наверно следующий этап развития.
revit написал(а):
Золотые слова, их бы в камне высечь.

Спасибо конечно, но здесь нет ничего особенного, простая логика.
 
Последнее редактирование модератором:
Потыкал программу и назрел ряд вопросов:
1) Количество групп ограничено пятью?
2) Если в виджете клиента нажать отчеты диспетчера, когда красным светится надпись "не подключено", то окно разворачивается, но наглухо виснет.
3) А исполнителя может назначать только диспетчер участка? А как быть если у нас на 4 участка один диспетчер аварийной службы?
4) У пользователя обязан быть пароль, при пустом пароле программа ошибок не выдает, но и не подключается. Пароль, кстати, отображается в настройках сервера, за что спасибо, а то с домэйном ни в какую не удается добиться
 
Последнее редактирование модератором:
poiZon написал(а):
Потыкал программу и назрел ряд вопросов:
1) Количество групп ограничено пятью?
2) Если в виджете клиента нажать отчеты диспетчера, когда красным светится надпись "не подключено", то окно разворачивается, но наглухо виснет.
3) А исполнителя может назначать только диспетчер участка? А как быть если у нас на 4 участка один диспетчер аварийной службы?
4) У пользователя обязан быть пароль, при пустом пароле программа ошибок не выдает, но и не подключается. Пароль, кстати, отображается в настройках сервера, за что спасибо, а то с домэйном ни в какую не удается добиться


1) Нет. Сколько угодно
2) Обязательно поправим. Спасибо.
3) Только внутри участка. Обзывайте дубли ФИО 1 ФИО 2 и так далее. Посчитали, что это редкость.
4) Я считаю, что если злоумышленник видит окно сервера, то уже поздно что то делать и уж тем более прятать пароли...
 
revit написал(а):
В чем редкость?


Обычно механики закреплены за участком. Чаще всего вообще один участок. За исключением больших диспетчерских. Выход для них предложен постом выше.
 
Последнее редактирование модератором:
Arcady написал(а):
1) Нет. Сколько угодно


А больше 5 групп не получается создать

Arcady написал(а):
3) Только внутри участка. Обзывайте дубли ФИО 1 ФИО 2 и так далее. Посчитали, что это редкость.


Дублей нет. Диспетчер один, а участка 4, как создавать заявки?

Arcady написал(а):
4) Я считаю, что если злоумышленник видит окно сервера, то уже поздно что то делать и уж тем более прятать пароли...


Я с благодарностью, ибо тоже так считаю, только вот не смог донести это разработчикам LKDSDomain, они предлагают мне, как админу, все пароли выучить.
Вы только про пустые пароли что-то сделайте, а то при создании пользователя с пустым паролем ошибку не выдает, но подключаться потом отказывается.
 
Последнее редактирование модератором:
poiZon написал(а):
А больше 5 групп не получается создать
Вы только про пустые пароли что-то сделайте, а то при создании пользователя с пустым паролем ошибку не выдает, но подключаться потом отказывается.

Исправил.
 
Назад
Сверху