Windows Сервис LKDSDomain

[Andi]

Раньше можно было видеть сам ключ в списке ключей, а теперь я вижу только название, ключ скрыт. Это что за нововведения - мне как админу теперь не разрешается вспомнить введеный ранее ключ?

Вложение IPB #2302

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

 

[revit]

Но, как мне кажется, раньше ключи можно было видеть.
Если я забыл ключ что мне делать?

 

[Andi]

Но, как мне кажется, раньше ключи можно было видеть.
Если я забыл ключ что мне делать?

Ключи нельзя увидеть ни в ПКЛШ, ни в LKDSPro, ни в LKDSDomain

Если ключ потерян, то нужно делать новый ключ, т.е. ввести новый ключ в ЛБ и добавить в список ключей LKDSDomain.

 

[revit]

Какая то излишняя, имхо. секретность. Это вынуждает писать ключ в поле "имя ключа" чтобы его не забыть, т.к. совсем не хочется потом во всех блоках его перебивать. И вся секретность на этом кончается.....
Ладно в LKDSDRV и LKDSPro , там часто бывает что службы крутится на компе диспетчера и там еще это можно понять, но LKDSDomain крутят на отдельных серверах и тут совершенно необъяснимы такие меры. Даже в операционках и маршрутизаторах делают глазок для визуального контроля паролей.

 

[Andi]

Даже в операционках и маршрутизаторах делают глазок для визуального контроля паролей.

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

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

 

[revit]

Нет, я не понимаю зачем так усложнять? LKDSDomain - сервис для больших сетей, и тех же ключей у меня может быть пару десятков или больше. И я реально должен их помнить???? Уж лучше я их буду дублировать в открытом поле "имя ключа", что в общем то и делал для простых распространенных ключей. В качестве защиты у меня выступает авторизация входа на сервер.

 

[poizon]

Нет, я не понимаю зачем так усложнять? LKDSDomain - сервис для больших сетей, и тех же ключей у меня может быть пару десятков или больше. И я реально должен их помнить???? Уж лучше я их буду дублировать в открытом поле "имя ключа", что в общем то и делал для простых распространенных ключей. В качестве защиты у меня выступает авторизация входа на сервер.

Полностью согласен.

 

[Andi]

Андрей Владимирович, домен позволяет управлять всеми организациями из какого-то единого интерфейса?

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

Хотел бы обсудить такой подход.

 

[poizon]

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

Хотел бы обсудить такой подход.

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

У нас устроено так, т.е. на лицо обратная зависимость доступных лифтов, начиная от механика

 

[revit]

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

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

 

[Andi]

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

Связи "закладок" (диспетчерских пунктов в географической структуре) и групп лифтов по доступу и сейчас нет. "Закладки" предполагались для удобства визуализации, что бы прямоугольники лифтов не были бы слишком маленькие.

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

 

[revit]

Я не смог правильно выразить свою мысль по поводу закладок-групп.
Спрошу проще:
есть две закладки -два региональных отделения 800 и 300 . У центрального диспетчера их нельзя объединить в одну т.к организационно, территориально и по кол-ву это две разные группы осблуживаемых лифтов.
В этих закладках четыре города, в которых обслуживаются лифты большой УК и у этой УК есть своя диспетчерская, в которой они хотят смотреть свои объекты (квадратики лифтов с датчиком МП и датчиком на юзере1). Из этих 800 и 300 лифтов УК в четырех городах ~400 и смотреть их в двух закладках (250+150) они не хотят . Нужно вывести их на один экран. Как это сделать?

 

[Andi]

Я не смог правильно выразить свою мысль по поводу закладок-групп.
Спрошу проще:
есть две закладки -два региональных отделения 800 и 300 . У центрального диспетчера их нельзя объединить в одну т.к организационно, территориально и по кол-ву это две разные группы осблуживаемых лифтов.
В этих закладках четыре города, в которых обслуживаются лифты большой УК и у этой УК есть своя диспетчерская, в которой они хотят смотреть свои объекты (квадратики лифтов с датчиком МП и датчиком на юзере1). Из этих 800 и 300 лифтов УК в четырех городах ~400 и смотреть их в двух закладках (250+150) они не хотят . Нужно вывести их на один экран. Как это сделать?

В рамках одной организации так сделать нельзя, т.к. географическая структура одна для одной организации.

Можно сделать ещё одну организацию и включить туда только лифты этой большой УК.
В организации для УК будет своя структура с одним диспетчерским пунктом (т.е. закладок не будет).

 

[revit]

В рамках одной организации так сделать нельзя, т.к. географическая структура одна для одной организации.

Можно сделать ещё одну организацию и включить туда только лифты этой большой УК.
В организации для УК будет своя структура с одним диспетчерским пунктом (т.е. закладок не будет).

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

 

[Andi]

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

Сам переход от LKDSDisp к LKDSDomain формален и описан в документации - структура выгружается из LKDSDisp и загружается в LKDSDomain.

При изменении списка лифтов, если это изменение касается УК, то действительно изменять нужно в двух организациях.

 

[poizon]

Не знаю точно куда отнести проблему, поэтому напишу сюда. Ситуация такая:
на моноблоке два дома, в первом блоки КДК и 2 ЛБ6 УЛ, во втором доме 4 блока ЛБ6 Союз. Блоки союз включаются и выключаются нормально, блоки УЛ через ASpultPlus включаются и выключаются нормально, с помощью сервисного ключа включаются и выключаются нормально, а вот диспетчер через SPult не может выключить блок, причем при попытке отключения через SPult блок зависает, уходит со связи и вместе с ним со связи уходят два ЛБ союз из соседнего дома.

 

[revit]

А вы подождите 3 минуты-может восстановятся на связи? Может у вас блоки "заводятся" ?
По команде отключения в СПульт первый раз включается голосовая связь. А уже после нее можно со второго нажатия выключить.

 

[poizon]

А вы подождите 3 минуты-может восстановятся на связи? Может у вас блоки "заводятся" ?
По команде отключения в СПульт первый раз включается голосовая связь. А уже после нее можно со второго нажатия выключить.

Суть вопроса в том, что с телефона (ASpultPlus) всё работает нормально, хотя алгоритм с выходом на ГГС тот же самый.

 

[Andi]

Не знаю точно куда отнести проблему, поэтому напишу сюда. Ситуация такая:
на моноблоке два дома, в первом блоки КДК и 2 ЛБ6 УЛ, во втором доме 4 блока ЛБ6 Союз. Блоки союз включаются и выключаются нормально, блоки УЛ через ASpultPlus включаются и выключаются нормально, с помощью сервисного ключа включаются и выключаются нормально, а вот диспетчер через SPult не может выключить блок, причем при попытке отключения через SPult блок зависает, уходит со связи и вместе с ним со связи уходят два ЛБ союз из соседнего дома.

Добейтесь появления данной ситуации (...блок зависает...), формируйте и пришлите данные в тех.поддержку.
Укажите с каким и когда (по возможности точнее) ЛБ ситуация проявилась.

 

[Vincent Van Gog]

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

Хотел бы обсудить такой подход.

Что-то никакого обсуждения не наблюдается <_< .
Возникла необходимость перенести лифты внутри LKDSDomain из одной организации в другую. Немного, всего 25, но всё равно хотелось бы это делать "в два клика".

Может есть смысл изменить доступ к лифту следующим образом:
1. у лифта будет признак "принадлежность организации" (некая "супер группа" соответствующая текущему понятию "организация" в LKDSDomain).
2. "супер администратор" сможет при необходимости этот признак изменить.

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