Централизованное обновление настроек

[GoogleCodeExporter]

При распостранении при первом запуске, 
достаточно создать options.xml 
(http://code.google.com/p/vacuum-im/issues/detail?id=490#c29)

А как быть если требуется обновить 
некторые параметры уже существующего 
options.xml?

Original issue reported on code.google.com by mr.lioncub on 26 Jun 2014 at 2:49

[GoogleCodeExporter]

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

Original comment by mr.lioncub on 28 Jun 2014 at 4:33

[GoogleCodeExporter]

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

Original comment by potapov.s.a on 28 Jun 2014 at 7:58

[GoogleCodeExporter]

вот и хочется запретить им менять 
некоторые настройки
или изменить уже установленные

Original comment by mr.lioncub on 29 Jun 2014 at 7:47

[GoogleCodeExporter]

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

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

Original comment by potapov.s.a on 1 Jul 2014 at 8:53

• Changed title: Централизованное обновление настроек
• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Unknown

[GoogleCodeExporter]

Можно посмотреть на сценарии firefox:

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

1. Настройки берутся из реестра HKLM
2. Настройки брутся из %PROGRAMFILES%\firefox /usr/lib/firefox/
3. С помощью плагина public-fox, который ставит 
запрет на редактирование некторых 
параметров. Есмли их нужно поменять нужно 
менять через плагин, предварительно габрав 
пароль.

Наиболее кроссплатформенное и удобное 
решение: 2.

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

Original comment by mr.lioncub on 1 Jul 2014 at 4:16

[GoogleCodeExporter]

Я не думаю, что задача состоит в том, чтобы 
что-то запретить пользователю, наоборот, 
пользователю нужно помогать настроить 
клиент. Все запреты должны стоять на 
сервере.

> Наиболее кроссплатформенное и удобное 
решение: 2.
Сейчас же так и работает. А какие настройки 
вам надо запретить изменять?

Original comment by potapov.s.a on 3 Jul 2014 at 8:00

[GoogleCodeExporter]

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

>Сейчас же так и работает.
Сейчас работает только если профиль не 
создан.

Original comment by mr.lioncub on 4 Jul 2014 at 12:03

[GoogleCodeExporter]

fixed in r2416

Original comment by potapov.s.a on 4 Sep 2014 at 1:14

• Changed state: Fixed

[GoogleCodeExporter]

Файл импортируемых настроек resources/options.xml 
разбит на 3 файла:
эти три файла вместо одного будут (а при 
постоянной работе 2)? 

Original comment by mr.lioncub on 4 Sep 2014 at 1:27

[GoogleCodeExporter]

или default-options.xml и initial-options.xml - нодно и то же и 
нужно при первом запуске?

и как это будет коррелировать с 
https://code.google.com/p/vacuum-im/issues/detail?id=490#c29

Original comment by mr.lioncub on 4 Sep 2014 at 1:33

[GoogleCodeExporter]

> default-options.xml и initial-options.xml - нодно и то же и 
нужно при первом запуске?
default-options.xml - меняет дефолтные настройки, 
которые не сохраняются и если этот файл 
убрать, то они вернутся в первоначальные 
значения
initial-options.xml - применяется применяется к 
каждому профилю однократно в момент 
создания, потом эти настройки можно 
изменить
static-options.xml - применяется при каждом 
открытии профиля, и если они были изменены 
пользователем, то вернутся обратно при 
следующем открытии профиля

Original comment by potapov.s.a on 4 Sep 2014 at 2:15

[GoogleCodeExporter]

static-options.xml куда ложить? Если в %appdata%..., то 
пользователь его может намеренно или не 
намеренно удалить/изменить.

default-options.xml - немного не понял для чего он. 
Если когда еще нет options.xml, то настройки 
берутся с него? Или те настройки которых 
нет еще в options.xml, берутся из default-options.xml.

initial-options.xml - т.е. он лежит вместе exe и 
применяется когда еще нет в профиле 
пользователя options.xml?

Original comment by mr.lioncub on 4 Sep 2014 at 2:30

[GoogleCodeExporter]

Все файлы должны лежать там же где лежал 
options.xml, а именно в папке resources, которая может 
быть как в папке пользователя, так и в папке 
приложения рядом с vacuum.exe.

default-options.xml - это настройки, которые были в 
примере без ns, считай настройки у которых 
приоритет ниже чем у пользовательских

initial-options.xml - применяется при создании 
профиля, пользователь может создать 
несколько профилей, если нет никакого 
профиля, то автоматически создается 
профиль с именем Default.

Original comment by potapov.s.a on 4 Sep 2014 at 2:40

[GoogleCodeExporter]

Теперь ясно. Благодарю за разъяснения! И 
спасибо за фичу. Теперь буду готовить и 
тестить обновление для пользователей.

Original comment by mr.lioncub on 4 Sep 2014 at 3:16