ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Delphi [игнор отключен] [закрыт для гостей] / Хранения Настроек Пользователя
26 сообщений из 26, показаны все 2 страниц
  все  
Хранения Настроек Пользователя
    #39607597
DimaBr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DimaBr
Участник
Здравствуйте !
Есть форма с большим количеством вкладок, на которых большое количество гридов и полей ввода.
Форма - карточка сотрудника, описывающая все данные о сотруднике.
Форма показывается различным пользователям.
В зависимости от настроек пользователя ему могут быть доступны различные вкладки формы и поля для просмотра или доступны для редактирования.
Данные о доступности той или иной вкладки/поля нужно хранить в базе
Возможно настройки нужно хранить не для пользователя, а для группы или же общие настройки группы и индивидуальные настройки пользователя

В каком виде хранить эти настройки ? Под каждую настройку отдельно поле таблицы, или же одно больше текстовое/бинарное поле в котором хранить настройки по типу Ini файла (Параметр=значение) или же например XML структуру
Может есть готовые обёртки ? Или подобные статьи в которых описаны плюсы и минусы.

Как это реализовано у вас ?
...
Рейтинг: 0 / 0
27.02.2018, 08:26
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607603
Фотография makhaon
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
makhaon
Участник
DimaBr,

Придумать права для пользователей. Что бы не привязываться жестко к интерфейсу, и, вообще, сущностей поменьше. Например, как у нас: пользователю разрешено просматривать протокол или нет, разрешено редактировать протокол или нет. Дальше возле этого права строится вся обвязка, и интерфейсная и кодовая. Возможно вообще в нескольких интерфейсах. Права в любом удобном виде хранить в базе. Цеплять это всё либо непосредственно к пользователям (если их относительно немного) либо, по хорошему, делать группы пользователей, раздавать права группам, а пользователей вносит в группы, по мере необходимости.
...
Рейтинг: 0 / 0
27.02.2018, 08:47
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607608
Фотография JayDi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JayDi
Участник
Привязывать доступ к элементам интерфейса, особенно к каждому полю-колонке-- заманчивая, но бесперспективная идея. В конечном итоге все эти настройки сами собой сведутся к небольшому количеству стандартных шаблонов/ролей, которые и будут назначаться пользователям.

Тут все зависит от объемов: если приложение несложное, а сами потенциальные роли ограничиваются небольшим перечнем типа "заказы-финансы-отчеты", то можно прямо в коде захардкодить проверки (в основном, в главном меню-форме).

Если что-то сложное, много разработчиков, разные системы и надо что-то универсальное -- можно все хранить в базе, внутри под капотом будут доступы к элементам форм и кастомным объектам, но все настройки и доступы будут идти через стандартные роли/группы.
...
Рейтинг: 0 / 0
27.02.2018, 09:04
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607629
DimaBr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DimaBr
Участник
Собственно вопрос о структуре хранения настроек:
1. Отдельные поля под каждый чих в настроечной таблице
2. Одно текстовое/блоб поле по типу Ini-файла
3. Поле XML типа или текстовое с хранением XML
4. Другой вариант
...
Рейтинг: 0 / 0
27.02.2018, 09:46
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607632
Фотография krapotkin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
krapotkin
Участник
я обычно делаю объект TMySettings и прямо туда загружаю данные из JSON с помощью XSuperObject
это удобнее чем XML. Если поля объекта поменяются, JSON тоже изменится.
Да и объем в два раза меньше
...
Рейтинг: 0 / 0
27.02.2018, 09:52
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607634
Фотография JayDi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JayDi
Участник
Отдельный список (одна настройка -- одна запись). Это позволит потом строить довольно полезные отчеты по типу кто чем пользуется, что востребовано, а что нет, подсчитать количество реальных пользователей у каждого модуля. Если писать логи доступа (кто какой доступ запрашивает) -- то и отчеты об использовании приложения тоже можно собирать.

В базе всё это занимает мало места по сравнению с остальными данными, и работает быстро -- даже если запросы к серверу будут идти каждый раз при открытии формы и/или по таймеру. Зато запросы легко делать -- не надо ковыряться в тех же xml/json данных. А эти отчеты в последствие пригодятся -- например, для службы безопасности, при исследовании инцидентов с доступом/порчей данных, сливов. Да и самим разработчиком -- видеть, что чаще всего используется, а что никому неинтересно.
...
Рейтинг: 0 / 0
27.02.2018, 09:56
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607637
Фотография JayDi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JayDi
Участник
Плюс легко можно делать массовые изменения -- например, когда добавляется новая фича и ее надо включить у всех, у кого есть доступ к другой фиче из той же темы.
...
Рейтинг: 0 / 0
27.02.2018, 09:57
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607643
DesWind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DesWind
Гость
DimaBr,
У JEDI есть компоненты для однообразного хранения параметров в Ini|XML|DB, сам я правда их не смотрел, все руки не доходят
...
Рейтинг: 0 / 0
27.02.2018, 09:59
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607653
DimaBr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
DimaBr
Участник
JaDiОтдельный список (одна настройка -- одна запись).
Такого типа ?
ПользовательПараметрЗначениеИвановДоступКРедактированиюФИОестьПетровДоступКРедактированиюФИОнетСидоровДоступКРедактированиюФИОпо вторникам
...
Рейтинг: 0 / 0
27.02.2018, 10:16
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607665
Фотография JayDi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JayDi
Участник
DimaBr,

Почти.

Иерархический справочник всех объектов, к которым можут быть доступ. Например, в виде структуры: модуль/приложение - раздел/форма - меню/кнопки/экшены/своё (или как удобнее хранить).

Справочник ролей (тоже можно иерархический/папкам для удобного хранения, если их будет много) с настройками доступа под каждую роль -- тот самый список объектов, куда есть доступ (в виде ссылок на справочник выше).

Справочник пользователей с привязкой к реальным сотрудникам из кадровой базы, доменным пользователям и т.п. сведения. В т.ч. список ролей, назначенных пользователю (ссылки на справочник ниже) -- та самая таблица из поста выше, только в виде ссылок.
...
Рейтинг: 0 / 0
27.02.2018, 10:26
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607668
schi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
schi
Участник
Иерархическая система прав, хранится в базе данных в виде строк (одна строка - одно маленькое право). При соединении с базой данных эти права считываются (один раз) и в зависимости от их совокупности настраиваются интерфейсные элементы.
...
Рейтинг: 0 / 0
27.02.2018, 10:33
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607675
Фотография JayDi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JayDi
Участник
Были еще варианты в виде наследования ролей/доступов -- идея интересная, но усложняет некоторые запросы и логику настроек. Обычная техподдержка, которая потом всё это настраивает -- может не осилить и накосячить.

На самом деле это один из главных вопросов -- кто всем этим будет заниматься и как ОРГАНИЗАЦИОННО всё это будет сделано в организации. Я бы от него и отталкивался. Потому что могут быть разные ситуации -- например, надо каждому сотруднику уникальный доступ настраиватт, или делать это по подразделениям (тоже нетривиальная задача -- проконтролировать, чтобы при переходе из одного отдела в другой -- у человека убрался старый доступ и он получил его к новым). Плюс может быть доступ К ДАННЫМ. Причем как к постоянным данным (список компаний и их базы), так и к динамическим (конкретным заказам, клиентам, направлениям).

P.S. Был еще провальный опыт с доступом к объектам базы данных (через оракл). Но идея была оригинальной.
...
Рейтинг: 0 / 0
27.02.2018, 10:38
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607715
Василий №2
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Василий №2
Гость
Xml/json/ini - компактнее, первые два позволяют задать иерархию.
Таблица Юзер-Имя опции-Значение опции - удобнее для изменения и статистики. Но плоская структура дает сложности в задании иерархических данных.

Если настройки задаются админом, и юзер не может их менять (что-то вроде прав доступа) - то однозначно второй вариант. Если же это индивидуальные настройки, то особо без разницы.
...
Рейтинг: 0 / 0
27.02.2018, 11:20
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607737
LSV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
LSV
Участник
JaDiНа самом деле это один из главных вопросов -- кто всем этим будет заниматься и как ОРГАНИЗАЦИОННО всё это будет сделано в организации. Я бы от него и отталкивался. Потому что могут быть разные ситуации -- например, надо каждому сотруднику уникальный доступ настраиватт, или делать это по подразделениям (тоже нетривиальная задача -- проконтролировать, чтобы при переходе из одного отдела в другой -- у человека убрался старый доступ и он получил его к новым). Плюс может быть доступ К ДАННЫМ. Причем как к постоянным данным (список компаний и их базы), так и к динамическим (конкретным заказам, клиентам, направлениям).Делал возможность копировать права с эталонного юзера на целевого с опцией объединения прав.
Н-р у эталонного нет права редактировать ТипДокХХХ, а у пользователя есть. При копировании он это право потеряет, а при объединении нет.
...
Рейтинг: 0 / 0
27.02.2018, 11:35
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607913
Мимопроходящий
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Мимопроходящий
Участник
UserNameAppNameFormNameComponentNameVisibleEnabledВасяSuperBug.exeUglyFormTrueFalse
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
27.02.2018, 15:00
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607921
Glays
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Glays
Участник
JaDiP.S. Был еще провальный опыт с доступом к объектам базы данных (через оракл). Но идея была оригинальной.
О! Расскажи, пожалуйста, где провалилось?
...
Рейтинг: 0 / 0
27.02.2018, 15:16
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607935
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
Мимопроходящий,

как-то через name стрёмно

лучше через например Help Context

ну и Application/Form/Component я бы отдельной таблицей-справочником хранил древообразно.
Также как и список пользователей и ролей - отдельными таблицами.

А права доступа уже - их пересечения.
...
Рейтинг: 0 / 0
27.02.2018, 15:31
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607938
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
Glays,

как практически отслеживать, что через три года после реализации функции её обновили, и теперь доступ к объектам 1,2,3 больше не нужен; к 4,5,6 наоборот стал нужен, а к 7,8,9 поменялся тип доступа ?
...
Рейтинг: 0 / 0
27.02.2018, 15:33
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607944
Фотография X11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
X11
Участник
DimaBrВ каком виде хранить эти настройки ?

Простая таблица в виде ключ/значение + доп. поля, например, если нужно разграничивать по id пользователя.
Можно ещё добавить поле типа BLOB. Я так храню настройки cxGrid, dxLayoutControl - через TStream.
...
Рейтинг: 0 / 0
27.02.2018, 15:39
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607951
Фотография X11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
X11
Участник
DimaBrМожет есть готовые обёртки ?

Не обёртки, но пример:
 

Код: pascal
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
procedure StoreLayoutControlStream(LayoutControl: TdxLayoutControl);
var
  PatternLayout: string;
  stream: TStream;
  q: TpFibQuery;
begin
...
...
...

  stream := TMemoryStream.Create;
  try
//firebird
      q.SQL.Text := 'UPDATE OR INSERT INTO TLAYOUT (ID_USER, FORM_CLASSNAME, LAYOUTCONTROL_NAME, STREAM) VALUES (:ID_USER,:FORM_CLASSNAME, :LAYOUTCONTROL_NAME, :STREAM) MATCHING (FORM_CLASSNAME, LAYOUTCONTROL_NAME)';


    q.ParamByName('FORM_CLASSNAME').AsString     := LayoutControl.Owner.ClassName;
    q.ParamByName('LAYOUTCONTROL_NAME').AsString := LayoutControl.Name;

    PatternLayout := LayoutControl.Owner.ClassName + '.' + LayoutControl.Name;
    LayoutControl.Container.StoreToStream(stream, PatternLayout);
    stream.Seek(0, 0);
    q.ParamByName('STREAM').LoadFromStream(stream);
    try
      if not q.Transaction.Active then q.Transaction.StartTransaction;
      q.ExecQuery;
      if q.Transaction.InTransaction then q.Transaction.Commit;

    except
         ...
    end;

  finally
    q.Close;
    stream.Free;
    q.Free;
  end;
end;

...
Рейтинг: 0 / 0
27.02.2018, 15:48
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607954
Фотография JayDi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JayDi
Участник
GlaysJaDiP.S. Был еще провальный опыт с доступом к объектам базы данных (через оракл). Но идея была оригинальной.
О! Расскажи, пожалуйста, где провалилось?
На одном промышленном предприятии -- там каких только подходов к организации доступа не применялось, в т.ч. и "оракловский".
...
Рейтинг: 0 / 0
27.02.2018, 15:51
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607955
Tactical Nuclear Penguin
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Tactical Nuclear Penguin
Участник
X11,
думаю ТС имел в виду права доступа, а не настройки гридов и прочего...
...
Рейтинг: 0 / 0
27.02.2018, 15:54
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607956
Arioch
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Arioch
Участник
JaDi,

зачод!!!

спрашивали наверное все же - в контексте форума - какие именно проблемы вылезли в реализации/эксплуатации. Где в программировании была засада, а не в географии.
...
Рейтинг: 0 / 0
27.02.2018, 15:57
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607970
Фотография JayDi
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
JayDi
Участник
Arioch,

Из того, что сейчас вспоминается про оракловский доступ:
- сервер загадился огромной кучей "пустых" пользователей/схем, которые стала мешать разработчикам чисто своим существованием -- и так было много схем под приложения/модули, а тут еще и "пустые" учетки в общую кучу подмешались;
- очень сложные запросы по работе с доступом (вместо обычного sql к таблицам приходилось писать запросы к внутренностям оракла);
- проблемы с доступом к объектам, когда по факту один модуль "тихо" использовал данные из других схем -- что вылилось к решениям вида "давай полный доступ ко всем объектам базы, чтобы уж наверняка";
- оракловская часть была пятым колесом, весь доступ все-равно "дублировался" в таблицах.
...
Рейтинг: 0 / 0
27.02.2018, 16:15
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39607977
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
softwarer
Участник
DimaBrВ каком виде хранить эти настройки ? Под каждую настройку отдельно поле таблицы, или же одно больше текстовое/бинарное поле
Одно большое текстовое/бинарное поле. Ибо во-первых, эти поля практически не используются в серверной бизнес-логике, а во-вторых, есть предмет постоянного расширения.

Конкретный формат хранения не особо важен. Лично я предпочитаю stringlist типа Раздел.Подраздел.Параметр=Значение как наиболее удачный вариант, сочетающий читаемость, лёгкость автоматической обработки, лёгкость ручного редактирования и отсутствие опасности задеть или забыть какую-нибудь закрывающую скобку.
...
Рейтинг: 0 / 0
27.02.2018, 16:25
| Ответить | Цитировать | Написать  
Хранения Настроек Пользователя
    #39608065
чччД
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
чччД
Участник
JaDi...
- сервер загадился огромной кучей "пустых" пользователей/схем, которые стала мешать разработчикам чисто своим существованием...

Очень похожую проблему поимел в одной конторе: они "самовольно" насоздавали такое количество ролей, что черт ногу сломит.
Причем, роли создавали не исходя из надобности доступа к объектам и действиям (для чего и создавалась конкретная система разграничений), а исходя из организационно-штатной структуры предприятия.
Например, роль "Октябрьская железная дорога", а в ней - "Дежурная бригада". И все, чисто названия, без логического наполнения, людям назначали роль - и все, "горшочек, вари!".
Ну насоздавали и насоздавали, но разруливать в итоге пришлось нам. Сперва пытались натянуть сову на глобус, создавая промежуточные "роли-адаптеры", потом грохнули все и построили заново, с предупреждением - "если кто-то создал новую роль - вот его и спрашиваете, что он имел в виду". Читайте документацию, короче. Или не влезайте, мы сами все сделаем, но за ваши деньги. Или влезайте, мы исправим, но тоже за деньги.

А без "ролей" вообще кирдык, ага.
...
Рейтинг: 0 / 0
27.02.2018, 18:38
| Ответить | Цитировать | Написать  
26 сообщений из 26, показаны все 2 страниц
  все  
Форумы / Delphi [игнор отключен] [закрыт для гостей] / Хранения Настроек Пользователя
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=58&tid=2041191]:
 0ms
get settings:
 9ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 175ms
get topic data:
 9ms
get forum data:
 2ms
get page messages:
 71ms
get tp. blocked users:
 2ms
others: 263ms
total:  550ms
созд. / загр.: 550ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]