Windows Клиент-серверное ПО диспетчеризации (LKDSDisp)

[Andi]

Посылаю файл. Уже на нескольких серверах наблюдаю это извещение.

Файл я забрал и удалил из письма. Эти сохраненные данные нужно посылать по адресу, который выдаётся после формирования, т.е. на techno@lkds.ru.

И есть просьба - обновите ПО на последнее с сайта, после чего сформируйте данные и пришлите на адрес techno@lkds.ru

 

[Victorovich]

Файл я забрал и удалил из письма. Эти сохраненные данные нужно посылать по адресу, который выдаётся после формирования, т.е. на techno@lkds.ru.

И есть просьба - обновите ПО на последнее с сайта, после чего сформируйте данные и пришлите на адрес techno@lkds.ru

Обновил ПО. Пока ошибка не появляется.

 

[kurilka]

Андрей Владимирович, поясните пожалуйста:
SPult.Hist - "4.7.0.34(26.08.2014) - добавлена возможность сохранения в журнале сообщения оператора"
Где включается, как пользоваться? Обновился из развернутого дистрибутива, но так и не нашел такую функцию.

В SPult есть возможность группового исключение новых неисправностей. Если попытаться исключить все неисправности сразу, выделив их, SPult закрывается с ошибкой. Оставив хотябы одну, исключение происходит корректно. Также сюда хотелось бы добавить возможность группировать неисправности - подряд все вызова, все потери связи, все проникновения в МП и т.д.

IMHO. Пора SPult учить обновляться с сервера.

 

[Andi]

Андрей Владимирович, поясните пожалуйста:
SPult.Hist - "4.7.0.34(26.08.2014) - добавлена возможность сохранения в журнале сообщения оператора"
Где включается, как пользоваться? Обновился из развернутого дистрибутива, но так и не нашел такую функцию.

В SPult (и MPultPro) в панели инструментов Оператора появилась кнопка , с помощью которой можно записать в журнал пользовательское сообщение. При применении SPult для записи пользовательского сообщения нужно использовать сервер LKDSDisp версии 4.7.0.19 (текущий дистрибутив LKDSDrv.msi). Пользовательское сообщение можно отфильтровать из журнала, настроить посылку SMS (email) оповещение.

В SPult есть возможность группового исключение новых неисправностей. Если попытаться исключить все неисправности сразу, выделив их, SPult закрывается с ошибкой. Оставив хотя бы одну, исключение происходит корректно. Также сюда хотелось бы добавить возможность группировать неисправности - подряд все вызова, все потери связи, все проникновения в МП и т.д.

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

IMHO. Пора SPult учить обновляться с сервера.

Такие желания и мнения есть.
Если изменения связаны с исправлением ошибок типа описанной выше, то может быть это и возможно.
Изменения типа введения понятия профиля автоматически вводить нельзя, т.к. последствия плохо прогнозируемы.

 

[Andi]

Подготовлена очередная доработка - добавлено понятие профиля пользователя: Посмотреть вложение Profiles.doc
Хотелось бы, конечно, обсудить сам подход и еще хотелось бы понять как это все отлаживать.
На страницу "Программы" выложен экспериментальный дистрибутив v4.7.1., содержащий реализацию Профиля пользователя

 

[kurilka]

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

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

 

[Andi]

Я так и не понял, какое преимущество дает профиль, относительно текущей конфигурации - без профиля.

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

Что делать с этими профилями?

Профили используются операторами как готовое размещение лифтов, сделанное, возможно не ими

Для чего создаются общедоступные профили и почему их разрешено создавать всем?

Пользователей может быть много, они могут быть сгруппированы, например, сменные операторы одной диспетчерской. Эта группа пользователей скорее всего должна иметь одно размещение. Тогда можно сделать общедоступный профиль, например, "Дисп1" и использовать его всем пользователям данной группы. Если появился новый доступный лифт, то добавлять его придется только в один профиль "Дисп1" и все пользователи, использующие профиль "Дисп1" при следующем подключении или обновлении увидят этот новый лифт.

Почему нельзя редактировать профиль администратору, а только удалять?

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

Зачем сохранена возможность работы с профилем и без?

Для совместимости. Если профиль при подключении не указывать, то ничего не изменится по сравнению с предыдущим ПО.

Что требуется отлаживать, правильность сохранения групп и размеры окон на сервере?

В код ПО были внесены значительные изменения, поэтому проверить нужно просто работоспособность ПО и без использовании профилей. Ну и хорошо бы, опять же, просто пробовать использовать Профиль.

 

[kurilka]

Андрей Владимирович, осмелюсь предложить другой алгоритм работы с профилями.
1. Только администратор имеет право создавать профили.
2. Администратор имеет право назначать профиль пользователю или группе пользователей.
3. Если у пользователя нет профиля, ему назначается «default Profile».
4. Изменения пользователем настроек программы сохраняются в «personal Profile».
5. Пользователь может удалить «personal Profile». (сброс в default).
6. Пользователь не имеет право изменять, удалять профиль, назначенный ему администратором.
7. При запуске программы загружается профиль, назначенный администратором. При отсутствии этого профиля загружается «personal Profile». Если нет персонального профиля, загружается «default Profile».

Как мне кажется, так администрировать будет проще и пользователям не надо объяснять про доп. настройки.

 

[Andi]

Андрей Владимирович, осмелюсь предложить другой алгоритм работы с профилями.
1. Только администратор имеет право создавать профили.
2. Администратор имеет право назначать профиль пользователю или группе пользователей.
3. Если у пользователя нет профиля, ему назначается «default Profile».
4. Изменения пользователем настроек программы сохраняются в «personal Profile».
5. Пользователь может удалить «personal Profile». (сброс в default).
6. Пользователь не имеет право изменять, удалять профиль, назначенный ему администратором.
7. При запуске программы загружается профиль, назначенный администратором. При отсутствии этого профиля загружается «personal Profile». Если нет персонального профиля, загружается «default Profile».

Как мне кажется, так администрировать будет проще и пользователям не надо объяснять про доп. настройки.

1. В реализованной в v4.7.1 модели профиля, пользователю-оператору тоже не нужно объяснять про дополнительные настройки. Все дополнительные настройки могут быть сделаны на компьютере Администратора, если зайти в SPult под нужным пользователем.

2. Если только Администратор имеет право делать профили, то возникает двухзвенная структура:

- Администратор
- Оператор

Уже есть территориально разделенные диспетчерские комплексы, в которых Администратор, например, в Москве:

- редактирует структуру для LKDSDrv с помощью LKDSDrvCfg, если появились новые УМ/слоты
- заводит ЛБ в базу LKDSDisp
- включает ЛБ в группы лифтов по доступности (не в размещение)

Подстройка изображения возлагается уже на персонал, скажем, в другом городе и логика в этом разделении полномочий есть.
Поэтому персонал на местах, не обладая Административными правами, должен иметь возможность сделать своё размещение лифтов (Профиль).
Т.е. должна быть возможна трехзвенная структура:

- Администратор
- Настройщик
- Оператор

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

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

 

[kurilka]

Дело в том, что структура получилась n-звенной, где n=количество пользователей.
Допустим, есть 30 человек, которые используют общий профиль "111". Нашелся какой то "умник", который залез в настройки, что то поменял, удалил пару лифтов, а может больше и все это сохранил. Все 30 разом получают неприятности - где то не звенит, группы перетасованны, не хватает лифтов и что то там еще. Потом надо найти злодея, а ведь он может быть и не из этих 30 а, к примеру, из 60. Потому что ВСЕ могут всё. Анархия, которая может привести к хаосу.
Именно по этому я предложил ограничить возможности пользователям. Если нужен некий "Настройщик", то пусть он будет назначен администратором, т.е. какой то пользователь получает разрешение создавать и управлять профилями, назначать профили пользователям или группе пользователей. Остальные могут редактировать ТОЛЬКО ЛИЧНЫЕ профили. Назначение профиля пользователю, с точки зрения "клиент-сервер", выглядит более логично. Ведь "Настройщику" гораздо проще сделать пару кликов мышкой, нежели обзванивать всех и диктовать по буквам название профиля.
Работу с несколькими профилями тоже предлагаю организовать в рамках клиент-серверных отношений. При подключении SPult выдает список доступных пользователю профилей, полученный с сервера. Дальше все просто, кликай нужный профиль, загружайся. Ведь какой-нибудь "пытливый ум" может попробовать подключиться под непредназначенным для него профилем. Результат непредсказуем.
Совместимость ПО аккуратно решается при помощи "профиля по умолчанию". Ведь конечному пользователю абсолютно все равно, где программа сохраняет настройки. При первом подключении пользователю загружаются настройки из "профиля по умолчанию". Изменив размеры окон, расположения групп лифтов и т.д. настройки сохраняются на сервере в "личном профиле", а не на локальном компьютере. При следующем подключении пользователю загружаются настройки из "личного профиля".

 

[Andi]

Дело в том, что структура получилась n-звенной, где n=количество пользователей.
Допустим, есть 30 человек, которые используют общий профиль "111". Нашелся какой то "умник", который залез в настройки, что то поменял, удалил пару лифтов, а может больше и все это сохранил. Все 30 разом получают неприятности - где то не звенит, группы перетасованны, не хватает лифтов и что то там еще. Потом надо найти злодея, а ведь он может быть и не из этих 30 а, к примеру, из 60. Потому что ВСЕ могут всё. Анархия, которая может привести к хаосу.
Именно по этому я предложил ограничить возможности пользователям. Если нужен некий "Настройщик", то пусть он будет назначен администратором, т.е. какой то пользователь получает разрешение создавать и управлять профилями, назначать профили пользователям или группе пользователей. Остальные могут редактировать ТОЛЬКО ЛИЧНЫЕ профили. Назначение профиля пользователю, с точки зрения "клиент-сервер", выглядит более логично. Ведь "Настройщику" гораздо проще сделать пару кликов мышкой, нежели обзванивать всех и диктовать по буквам название профиля.

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

В условия компромисса между желаемым и возможным предлагаются следующие доработки:

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

2. В параметры пользователя добавить ссылку на основной профиль. Основной профиль может быть из общих и личных профилей.
Если основной профиль назначен из общих профилей, то пользователь не может создавать личный профиль с таким же именем. Это гарантирует то, что пользователь, подключившийся под основным профилем, назначенным из общих профилей, всегда будет видеть последние изменения в профиле.

Если пользователь подключается без указания в панели подключения профиля, то, при наличии у пользователя основного профиля, используется этот профиль, а если основного профиля у пользователя нет, то при первом подключении используется размещение, заданное Администратором (фактически общий основной профиль). При последующих подключениях используется размещение из сохраненного XML файла, если основного профиля у пользователя не появилось (т.е. работа производится, как и сейчас)

Назначать основной профиль пользователям может Администратор из дерева "Пользователи и группы лифтов" или сам пользователь. Если пользователь подключился с указанием профиля, то у него появляется в режиме настройки пункт меню
"Сделать личный/общий профиль <имя_профиля> основным"

3. Добавить для общих профилей признак - "Не замещаемый". Если признак установлен, то пользователь, подключившийся с использованием такого общего профиля, не сможет сохранить личный профиль под тем же именем, что и общий профиль. Это гарантирует то, что пользователь всегда будет видеть последние изменения в профиле.

4. При подключении SPult с использованием упрощенной (сокращенной) панели подключения, профиль выбрать нельзя (поле будет отсутствовать) и используется основной профиль.

5. При подключении SPult с использованием упрощенной (сокращенной) панели подключения нельзя перейти в режим Настройки.

Работу с несколькими профилями тоже предлагаю организовать в рамках клиент-серверных отношений. При подключении SPult выдает список доступных пользователю профилей, полученный с сервера. Дальше все просто, кликай нужный профиль, загружайся. Ведь какой-нибудь "пытливый ум" может попробовать подключиться под непредназначенным для него профилем. Результат непредсказуем.

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

Если пользователь подключается с указанием профиля, то профиль ищется в следующей последовательности:
- среди личных профилей
- среди общих профилей

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

Совместимость ПО аккуратно решается при помощи "профиля по умолчанию". Ведь конечному пользователю абсолютно все равно, где программа сохраняет настройки. При первом подключении пользователю загружаются настройки из "профиля по умолчанию". Изменив размеры окон, расположения групп лифтов и т.д. настройки сохраняются на сервере в "личном профиле", а не на локальном компьютере. При следующем подключении пользователю загружаются настройки из "личного профиля".

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

 

[Andi]

До 12.11.2014 буду в отпуске, но форум, иногда, читать буду.

 

[evpu]

Добрый день!

Хочу вот проинсталлить это хозяйство. На машине (2008R2x64) уже запущен другой SQL. MsSQL надо ставить на другой порт (не 3306), но на localhost. Это допустимо?

 

[Andi]

Добрый день!

Хочу вот проинсталлить это хозяйство. На машине (2008R2x64) уже запущен другой SQL. MsSQL надо ставить на другой порт (не 3306), но на localhost. Это допустимо?

Добрый день.

Если этот "другой SQL" - Microsoft SQL server, то его можно использовать и для работы LKDSDisp.

Если все-же нужно установить Microsoft SQL server, то насколько я понимаю, LKDSDisp, при запуске на том же компьютере, что и MSQL, может использовать для связи с MSQL, клиентский протокол Shared Memopy, т.е. не TCP/IP

И для связи с MSQL по TCP/IP используется по умолчанию порт 1433

 

[Andi]

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

В условия компромисса между желаемым и возможным предлагаются следующие доработки:

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

2. В параметры пользователя добавить ссылку на основной профиль. Основной профиль может быть из общих и личных профилей.
Если основной профиль назначен из общих профилей, то пользователь не может создавать личный профиль с таким же именем. Это гарантирует то, что пользователь, подключившийся под основным профилем, назначенным из общих профилей, всегда будет видеть последние изменения в профиле.

Если пользователь подключается без указания в панели подключения профиля, то, при наличии у пользователя основного профиля, используется этот профиль, а если основного профиля у пользователя нет, то при первом подключении используется размещение, заданное Администратором (фактически общий основной профиль). При последующих подключениях используется размещение из сохраненного XML файла, если основного профиля у пользователя не появилось (т.е. работа производится, как и сейчас)

Назначать основной профиль пользователям может Администратор из дерева "Пользователи и группы лифтов" или сам пользователь. Если пользователь подключился с указанием профиля, то у него появляется в режиме настройки пункт меню
"Сделать личный/общий профиль <имя_профиля> основным"

3. Добавить для общих профилей признак - "Не замещаемый". Если признак установлен, то пользователь, подключившийся с использованием такого общего профиля, не сможет сохранить личный профиль под тем же именем, что и общий профиль. Это гарантирует то, что пользователь всегда будет видеть последние изменения в профиле.

4. При подключении SPult с использованием упрощенной (сокращенной) панели подключения, профиль выбрать нельзя (поле будет отсутствовать) и используется основной профиль.

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

Если пользователь подключается с указанием профиля, то профиль ищется в следующей последовательности:
- среди личных профилей
- среди общих профилей

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

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

Т.к. замечаний не было, будут сделаны предложенные доработки

 

[kurilka]

Прошу прощения. Надеюсь, что не опоздал.

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

Это пользователь должен принадлежать именно этой группе? Если этот пользователь создает профили для нескольких групп он должен будет находиться в каждой из этих групп?

Даже если пользователь случайно или намеренно указал непредназначенный ему общий профиль, то результат предсказуем.

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

При подключении SPult с использованием упрощенной (сокращенной) панели подключения

Что за упрощенная панель и с какой целью она вводится?

Если пользователь подключился с указанием профиля, то у него появляется в режиме настройки пункт меню
"Сделать личный/общий профиль <имя_профиля> основным"

Возможно ли в будущем при помощью профиля добавлять или убирать пункты меню в программе. Индивидуально для каждого.

Профиль не даёт доступа и прав - это только размещение

Грустно. Потенциал у профиля гораздо больше. IMHO.

По поводу совместимости ПО. Все-таки нужно оставить работу без профилей как она была и раньше

Видимо есть для этого какие то причины, невидимые и непонятные для меня. Для тестирования? Но ведь дистрибутив то отдельный. Мне кажется, что это просто приведет к лишним и никому не нужным "хвостам".
Я уже предлагал сделать проверку совместимости версий клиента и сервера. Сейчас "старый" SPult, который ничего не знает про расширенные права доступа, спокойно подключается к "новому" LKDSDisp. Это не правильно.

 

[Andi]

Это пользователь должен принадлежать именно этой группе? Если этот пользователь создает профили для нескольких групп он должен будет находиться в каждой из этих групп?

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

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

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

Что за упрощенная панель и с какой целью она вводится?

Это уже имеющаяся панель подключения, которая появляется, если запустить SPult с ключом -s. Сейчас в этой панели только два поля -имя и пароль. Эти поля и останутся, т.е. в упрощенной панели не будет поля для указания профиля, а при подключении будет использоваться основной профиль (профиль по умолчанию)

Возможно ли в будущем при помощью профиля добавлять или убирать пункты меню в программе. Индивидуально для каждого.

И сейчас в профиле можно, кроме размещения, указывать дополнительные параметры, например,

параметры диспетчерского пункта:
- «разрешить звук и мерцание на новые сообщения»;
- «автоматически включать ГГС в панели управления».

общие параметры:
- продолжительность включения ГГС;
- продолжительность работы с диалогом управления ЛБ;
- автоматическое открытие списка непросмотренных неисправностей;
- автоматическое закрытие списка непросмотренных неисправностей;
- запрет группового плавного отключения лифтов;
- запрет просмотра списка сервисных ключей;

Можно, наверное, добавить так же доступность пунктов меню

Грустно. Потенциал у профиля гораздо больше. IMHO.

Думаю, я ответил выше

Видимо есть для этого какие то причины, невидимые и непонятные для меня. Для тестирования? Но ведь дистрибутив то отдельный. Мне кажется, что это просто приведет к лишним и никому не нужным "хвостам".
Я уже предлагал сделать проверку совместимости версий клиента и сервера. Сейчас "старый" SPult, который ничего не знает про расширенные права доступа, спокойно подключается к "новому" LKDSDisp. Это не правильно.

Дистрибутив 4.7.1 сейчас действительно выложен параллельно с дистрибутивом 4.7.0. И это действительно сделано для ознакомления с самим понятием "профиля" и для тестирования. После отладки останется только 4.7.1.
Так вот нужно, что бы после обновления ПО до 4.7.1, для тех, кто не хочет использовать профили, не возникало никаких дополнительных трудностей, иначе ПО не будут обновлять вообще.
Если кто-то не хочет использовать профили, то обновление ПО для него должно пройти незаметно.
И не должно быть требований немедленного обновления SPult и других приложений-клиентов на удаленных точках после обновления ПО, если новшества не используются.
А идентификацию вида и версии приложения - клиента при подключении, делать, наверное, нужно. Эту информацию можно сохранять в ЛОГах, показывать по кнопке "Удаленные подключения".

 

[kurilka]

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

В принципе да, единственное - "общий профиль" тут в терминологию не вписывается.

Это уже имеющаяся панель подключения, которая появляется, если запустить SPult с ключом -s. Сейчас в этой панели только два поля -имя и пароль. Эти поля и останутся, т.е. в упрощенной панели не будет поля для указания профиля, а при подключении будет использоваться основной профиль (профиль по умолчанию)

Предлагаю сделать наоборот:
при запуске SPult с ключом (любым, не важно каким), появлялась панель с настройками;
при запуске SPult без ключа, появлялась сокращенная панель.
Ну или сделать кнопку "Настройки", куда и вынести все изменяемые и настраиваемые параметры.

Можно, наверное, добавить так же доступность пунктов меню

Вот именно это интересует.
Если это реализуемо, то можно перенести некоторые пункты из режима настройки в основной режим. К примеру - загрузка выгрузка nvram, загрузка в блок микропрограммы и т.д.

Если кто-то не хочет использовать профили, то обновление ПО для него должно пройти незаметно.

Запустил SPult, изменил параметры, настроил окна, нажал сохранить. Где сохраняться эти настройки - в XML или в профиле на сервере, меня, как пользователя, не интересует. Сохранились на сервере в профиле "имя пользователя", при следующем запуске SPult от туда загрузились. Вроде бы незаметно.

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

Просто надо научить SPult обновляться с сервера или скачивать с этого сервера exe-шник с dll-кой в папку, из которой он был запущен.
И как понять "новшества не используются". Дистрибутив, в итоге, останется один. Хочешь не хочешь, а придется обновиться и использовать новшества. А на время тестирования, наверное будет правильней, если новый SPult будет уметь работать со старым LKDSDisp.

И еще. Андрей Владимирович, надо что-то придумать с "диспетчерскими" в SPult. Без них никак, а с ними неудобно. Может какую-нибудь "супер группу" сделать, чтобы в панели адресов не повторялись несколько раз названия улиц. Иногда, чтобы найти лифт, приходится пролистывать несколько диспетчерских.

 

[Andi]

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

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

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

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

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

5. Если пользователь подключается без указания в панели подключения профиля, то, при наличии у пользователя профиля по умолчанию, используется этот профиль, а если профиля по умолчанию у пользователя нет, то при первом подключении используется размещение, заданное Администратором (фактически общий профиль по умолчанию). При последующих подключениях используется размещение из сохраненного XML файла, если профиля по умолчанию у пользователя не появилось (т.е. работа производится, как и сейчас)

6. Назначать профиль по умолчанию пользователям может Администратор из дерева "Пользователи и группы лифтов" или сам пользователь. Если пользователь подключился с указанием профиля, то у него появляется в режиме настройки пункт меню
"Сделать личный/групповой/общий профиль <имя_профиля> основным"

7. Добавить для профилей признак - "Не замещаемый". Если признак установлен, то пользователь, подключившийся с использованием такого общего/группового профиля, не сможет сохранить личный профиль под тем же именем, что и общий/групповой профиль. Это гарантирует то, что пользователь всегда будет видеть последние изменения в профиле.

8. При подключении SPult с использованием упрощенной (сокращенной - SPult -s) панели подключения нельзя перейти в режим Настройки.

9. Поле ввода/выбора профиля в панели подключения активно при запуске SPult с ключом –p (SPult -p). При запуске без ключа -p выбрать профиль нельзя, используется профиль по умолчанию, нельзя изменить/сохранить профиль.

Если это реализуемо, то можно перенести некоторые пункты из режима настройки в основной режим. К примеру - загрузка выгрузка nvram, загрузка в блок микропрограммы и т.д.

Просто надо научить SPult обновляться с сервера или скачивать с этого сервера exe-шник с dll-кой в папку, из которой он был запущен.

И еще. Андрей Владимирович, надо что-то придумать с "диспетчерскими" в SPult. Без них никак, а с ними неудобно. Может какую-нибудь "супер группу" сделать, чтобы в панели адресов не повторялись несколько раз названия улиц. Иногда, чтобы найти лифт, приходится пролистывать несколько диспетчерских.

Все это предлагается рассмотреть следующим этапом, хочется как-то закончить с профилями

 

[kurilka]

Логика работы с профилями становится понятной.
По п.п. 1 и 2:
все таки личное должно быть личным, наверное. Напрашивается возможность для пользователя-образца (в дальнейшем просто пользователь) создание "дополнительных общих профилей", доступных только пользователям-копиям (дальше просто копии). Здесь у меня вопрос - насколько так необходим обмен профилями между пользователями, т.е. профиль (имеется ввиду общий профиль), созданный одним пользователем, доступен другому пользователю? А если сделать так: общий профиль, созданный администратором будет доступен пользователям, а общий профиль, созданный пользователем будет доступен копиям. Получится такая иерархия, где админ на верхней ступеньке, ступенькой ниже пользователи, еще ниже копии, еще ниже ... Еще ниже пока нет, но как-то напрашивается, потому что:
по п.3
не все понятно с наследованием прав. Допустим, пользователь имеет минимальные права доступа к лифтам, т.е. может только смотреть. В этом случае копиям можно добавить дополнительные права. А если пользователь будет иметь административные права? У копий нужно уже будет отнимать права,ну или что-то им запрещать. А если под пользователем несколько копий, то доп. права надо будет назначать каждому? Собственно тут и напрашивается сделать "копию пользователя-копии", через которого и управлять правами. Как бы не запутаться в этом ), но получится такая "структура вложенных папок".
По п. 6 уточняющий вопрос. Если пользователю профиль по умолчанию будет назначен администратором, сможет он его поменять на другой или нет?