Контроль версии настроек (постановка) - История изменений

SYSDBA: /* Решение */

2013-10-20T15:53:19Z

‎Решение

SYSDBA в 09:06, 28 сентября 2010

2010-09-28T09:06:16Z

SYSDBA в 09:06, 28 сентября 2010

2010-09-28T09:06:00Z

SYSDBA в 12:40, 24 декабря 2006

2006-12-24T12:40:18Z

SYSDBA: /* Временные настройки */

2006-12-21T23:12:46Z

‎Временные настройки

SYSDBA: /* Решение */

2006-12-21T23:11:42Z

‎Решение

SYSDBA: /* Решение */

2006-12-21T23:07:58Z

‎Решение

SYSDBA: /* Ситуация */

2006-12-20T14:13:53Z

‎Ситуация

Alex: /* Ситуация */

2006-12-20T08:06:52Z

‎Ситуация

SYSDBA в 23:40, 19 декабря 2006

2006-12-19T23:40:23Z

Внесённые изменения

@@ Строка 185: / Строка 185: @@
 При очередном открытии окна с настройками должна выполняться проверка. Если в базе данных присутствуют временные настройки «срок годности», которых истек, то на каждую задается вопрос удалить ее из базы или нет.  Если пользователь ответил утвердительно, то настройка удаляется.
-[[Category:Постановка]]
+[[Category:Постановка-Сделано]]
 __NOTOC__

@@ Строка 1: / Строка 1: @@
+Проблемы, связанные с сериализацией настроек, обсуждаются также здесь:
 Проблемы, связанные с сериализацией настроек обсуждаются также здесь:
 * [[Сохранение настройки в нескольких файлах (постановка)]]

@@ Строка 1: / Строка 1: @@
 Перечислим существующие проблемы и наметим возможные пути их решения:
 ==Перезапись изменений, сделанных на базе данных==
 ===Ситуация===
 Есть база данных. На нее загружена настройка Х. В этой настройке могли быть сделаны некоторые изменения. Через некоторое время поступает новая версия данной настройки в виде отдельного файла. Как при загрузке файла не затереть сделанные изменения? Если они, конечно, были.
@@ Строка 179: / Строка 187: @@
 [[Category:Постановка]]

← Предыдущая		Версия 12:40, 24 декабря 2006
Строка 177:		Строка 177:
	Решение может быть следующее: в объект настройки добавить поле Дата действия. Если это поле не заполнено, то настройка не имеет «срока годности» и считается не временной. Если это поле заполнено, то настройка считается временной.		Решение может быть следующее: в объект настройки добавить поле Дата действия. Если это поле не заполнено, то настройка не имеет «срока годности» и считается не временной. Если это поле заполнено, то настройка считается временной.
	При очередном открытии окна с настройками должна выполняться проверка. Если в базе данных присутствуют временные настройки «срок годности», которых истек, то на каждую задается вопрос удалить ее из базы или нет. Если пользователь ответил утвердительно, то настройка удаляется.		При очередном открытии окна с настройками должна выполняться проверка. Если в базе данных присутствуют временные настройки «срок годности», которых истек, то на каждую задается вопрос удалить ее из базы или нет. Если пользователь ответил утвердительно, то настройка удаляется.
		+
		+	[[Category:Постановка]]

@@ Строка 167: / Строка 167: @@
 С помощью перетаскивания в дереве можно было бы реализовать удобный механизм установки зависимостей между разными настройками.
 ==Временные настройки==
 ===Ситуация===

@@ Строка 144: / Строка 144: @@
 ===Решение===
 Следует разработать синхронизацию списка настроек в базе данных со списком настроек на диске, аналогично тому, как для файлов это сделано в TotalComander.
 Точно так же, как в TotalComander можно дважды щелкнуть по файлу и перейти в режим сравнения содержимого файлов, у нас можно будет дважды щелкнуть и перейти в режим сравнения содержимого настроек.

@@ Строка 42: / Строка 42: @@
 # Пользовательский интерфейс стоит организовать следующим образом: в окне Пакеты выводить список пакетов как это делается и сейчас. Пользователь выбирает галочками пакеты, которые он хочет установить. Нажимает кнопку Загрузить. Программа находит для каждого пакета список опциональных настроек, которые входят в данный пакет, и выдает окно с чек листом. В окне сообщается, загрузка какого пакета осуществляется и что, мол, для него есть опциональные компоненты. Пользователь галочками выбирает, какие опциональные пакеты стоит устанавливать. Такое окно выводится для каждого пакета, выбранного пользователем, если у этого пакета есть опциональные компоненты.
 # Изначально стоит предусмотреть иерархическую структуру. Т.е. одна опциональная настройка может зависеть от других настроек, среди которых могут быть опциональные, те, в свою очередь от третьих, и так до бесконечности. Причем, сразу стоит оговориться, что наследование может быть не прямое, а через один, два или более уровней. Т.е. опциональная настройка зависит от нескольких настроек, среди которых все обязательные (неопциональные), а те уже зависят от некоторых настроек, среди которых есть опциональные.
 # Окно выбора опциональных пакетов:
+[[Изображение:Select_packet.png]]
-# Вариант к обсуждению:
-Не делать два окна, а непосредственно в окне со списком пакетов заменить список на дерево. Тогда: самый верхний уровень дерева образуют Пакеты. Если пакет зависит от опциональных настроек, то его можно открыть и отметить галочками нужные настройки. Опять-таки, опциональная настройка может находиться на произвольном уровне вложенности.
+Вариант к обсуждению:
 ==Защита настроек от перезаписи с другой базы==

← Предыдущая		Версия 14:13, 20 декабря 2006
Строка 36:		Строка 36:

	Подразумевалось, что пакетов будет немного. Например, пакет Бухучет, Ресторан, Торговля и т.п. Однако в процессе работы количество пакетов увеличилось, что дискредитировало саму идею. Сейчас в окне Пакеты несколько десятков позиций и по-сути мы вернулись к изначальной ситуации, когда пользователь должен знать какие пакеты выделить, чтобы получить базу данных нужной конфигурации.		Подразумевалось, что пакетов будет немного. Например, пакет Бухучет, Ресторан, Торговля и т.п. Однако в процессе работы количество пакетов увеличилось, что дискредитировало саму идею. Сейчас в окне Пакеты несколько десятков позиций и по-сути мы вернулись к изначальной ситуации, когда пользователь должен знать какие пакеты выделить, чтобы получить базу данных нужной конфигурации.
−
−	~~----~~
−
−	Мне кажется проблема с пакетами возникает из-за того, что мы отдаем пользователям (выкладываем на сайте) все настройки, которые у нас есть. А реально тех пакетов, которые действительно следует отдавать, я насчитал 17. Вот как получилась эта цифра. Всего в стартиме 56 конечных пакетов настроек. Из них:
−
−	- 16 пакетов - это кассы и сканеры. Конечно можно выставить опциональные зависимости Торговли от этих пакетов, но я не припомню случая, когда пользователь сам устанавливал эти пакеты (сам подключал кассу к Гедымину).
−
−	- 15 пакетов - это настройки под конкретных клиентов или настройки специализированных решений (многие из них не продаются, их просто жалко выкинуть). Вот их список: Регистрация иностранной безвозмездной помощи; Расчеты с поставщиками скота; Природный газ; ПОЛИГРАФКОМБИНАТ; Общежитие; Ремонт бытовой техники; СТО (2 шт); Общежитие; Зарплата для с/х; Заявка общая; Докладная записка для Департ.гум.помощи; MGAZ_001; Пеня для автобизнеса, Аренда)
−
−	- 5 пакетов - импорт из других систем (Основные средства импорт, Импорт данных из программы "Секрет Анжелики", Импорт из 1С. Проводки, Импорт данных из программ Анжелика и Анжелика-Бухгалтер, Импорт данных из 1С). Что касается настроек по импорту из наших старых программ, то они будут использоваться все реже. А импорт из 1с тоже не целесообразно подключать опциональной зависимостью к какому либо пакету.
−
−	- 3 пакета - нерабочие или устаревшие (Обновление платежек, Бланки строгой отчетности, Демонстрационные данные по банку и кассе).
−
−	Я считаю, с загрузкой пакетов можно все оставить как есть. Из существующих пакетов опциональные зависимости целесообразно устанавливать разве что с пакетами настроек по проводкам (а их не много).
−	~~--[[Участник:Alex\|Alex]] 09:06, 20 December 2006 (CET)~~

	===Решение===		===Решение===

← Предыдущая		Версия 08:06, 20 декабря 2006
Строка 36:		Строка 36:

	Подразумевалось, что пакетов будет немного. Например, пакет Бухучет, Ресторан, Торговля и т.п. Однако в процессе работы количество пакетов увеличилось, что дискредитировало саму идею. Сейчас в окне Пакеты несколько десятков позиций и по-сути мы вернулись к изначальной ситуации, когда пользователь должен знать какие пакеты выделить, чтобы получить базу данных нужной конфигурации.		Подразумевалось, что пакетов будет немного. Например, пакет Бухучет, Ресторан, Торговля и т.п. Однако в процессе работы количество пакетов увеличилось, что дискредитировало саму идею. Сейчас в окне Пакеты несколько десятков позиций и по-сути мы вернулись к изначальной ситуации, когда пользователь должен знать какие пакеты выделить, чтобы получить базу данных нужной конфигурации.
		+
		+	----
		+
		+	Мне кажется проблема с пакетами возникает из-за того, что мы отдаем пользователям (выкладываем на сайте) все настройки, которые у нас есть. А реально тех пакетов, которые действительно следует отдавать, я насчитал 17. Вот как получилась эта цифра. Всего в стартиме 56 конечных пакетов настроек. Из них:
		+
		+	- 16 пакетов - это кассы и сканеры. Конечно можно выставить опциональные зависимости Торговли от этих пакетов, но я не припомню случая, когда пользователь сам устанавливал эти пакеты (сам подключал кассу к Гедымину).
		+
		+	- 15 пакетов - это настройки под конкретных клиентов или настройки специализированных решений (многие из них не продаются, их просто жалко выкинуть). Вот их список: Регистрация иностранной безвозмездной помощи; Расчеты с поставщиками скота; Природный газ; ПОЛИГРАФКОМБИНАТ; Общежитие; Ремонт бытовой техники; СТО (2 шт); Общежитие; Зарплата для с/х; Заявка общая; Докладная записка для Департ.гум.помощи; MGAZ_001; Пеня для автобизнеса, Аренда)
		+
		+	- 5 пакетов - импорт из других систем (Основные средства импорт, Импорт данных из программы "Секрет Анжелики", Импорт из 1С. Проводки, Импорт данных из программ Анжелика и Анжелика-Бухгалтер, Импорт данных из 1С). Что касается настроек по импорту из наших старых программ, то они будут использоваться все реже. А импорт из 1с тоже не целесообразно подключать опциональной зависимостью к какому либо пакету.
		+
		+	- 3 пакета - нерабочие или устаревшие (Обновление платежек, Бланки строгой отчетности, Демонстрационные данные по банку и кассе).
		+
		+	Я считаю, с загрузкой пакетов можно все оставить как есть. Из существующих пакетов опциональные зависимости целесообразно устанавливать разве что с пакетами настроек по проводкам (а их не много).
		+	--[[Участник:Alex\|Alex]] 09:06, 20 December 2006 (CET)

	===Решение===		===Решение===