Разрешенная группа прайс-листов.
Модераторы: m0p3e, edward_K, Модераторы
-
- Местный житель
- Сообщения: 2896
- Зарегистрирован: 24 июн 2005, 12:12
- Откуда: Иркутская область
Разрешенная группа прайс-листов.
поставил 5.4.25
настройка "Настройки Галактики \ Логистика \ Прайс-листы \ Разрешенная группа прайс-листов" теперь там можно делать множественный выбор, но ни суть важно.
у юзера слетела настройка. что я только не делал, и удалял всё, и выбирал одну группу, и выбирал две группы, по фигу.
Как видит ВСЕ прайс-листы при выборе в ДО так и видит.
Самое странное что если сделать настройку другому юзеру - всё отрабатывает. Может она в паре с какой другой настройкой пашет?
настройка "Настройки Галактики \ Логистика \ Прайс-листы \ Разрешенная группа прайс-листов" теперь там можно делать множественный выбор, но ни суть важно.
у юзера слетела настройка. что я только не делал, и удалял всё, и выбирал одну группу, и выбирал две группы, по фигу.
Как видит ВСЕ прайс-листы при выборе в ДО так и видит.
Самое странное что если сделать настройку другому юзеру - всё отрабатывает. Может она в паре с какой другой настройкой пашет?
-
- Местный житель
- Сообщения: 1357
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: СПб, ЭП-Аудит
- Контактная информация:
Было замечено, но трудноповторимо!!
Суть в том, что под пользователем видна одна настройка(при входе в настройки из модулей), а реально подхватывается другая настройка.
Иногда отлавливается интерфейсом "Статистика обращения к настройкам".
Но бывает что и не отловить.
Можно зайти в администратор настроек. По Alt+A переключить вид интерфеса и руками посмотреть какие есть настройки. Могут быть настройки не привязанные ни к одному пользователю, могут быть по две и более настройки на одного пользователя(видел собственными глазами: у клиента сбойнул реестр настроек видно одну настройку и используется другая - правда давно это было).
Ну и последнее - филиальность. Сам напоролся на грабли. Стоит 24 атлантис. Настройка периода планирования берется из корпорации, а не из фирмы. С чем связано выяснить не смог-плюнул на это дело до лучших времен.
Суть в том, что под пользователем видна одна настройка(при входе в настройки из модулей), а реально подхватывается другая настройка.
Иногда отлавливается интерфейсом "Статистика обращения к настройкам".
Но бывает что и не отловить.
Можно зайти в администратор настроек. По Alt+A переключить вид интерфеса и руками посмотреть какие есть настройки. Могут быть настройки не привязанные ни к одному пользователю, могут быть по две и более настройки на одного пользователя(видел собственными глазами: у клиента сбойнул реестр настроек видно одну настройку и используется другая - правда давно это было).
Ну и последнее - филиальность. Сам напоролся на грабли. Стоит 24 атлантис. Настройка периода планирования берется из корпорации, а не из фирмы. С чем связано выяснить не смог-плюнул на это дело до лучших времен.
-
- Местный житель
- Сообщения: 1357
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: СПб, ЭП-Аудит
- Контактная информация:
В теории да. Но надо полагать что какая-то настройка (другая) также "глючит", а проверка реестра с модификацией реестра приведет в неглючное состояние настройки, но и не верно работающее. Где-то так.тогда вопрос - проверка реестра настроек должна помочь со всеми галочками ?
С филиальностью - наврядли.
А статистика обращения к настройкам дает какой-либо результат?
-
- Местный житель
- Сообщения: 2896
- Зарегистрирован: 24 июн 2005, 12:12
- Откуда: Иркутская область
хм. ну запущу уходя домой проверку реестар, глянем.
1. настройка у нас филиальная - пользовательская. у нас вообще филиальность не используется, но по типу стоит это
2. статистика результатов не дает, пишет в отчет одну строчку когда я последний раз менял эту настройку.
3. запрос в саппорт выдает только одну строчку на этого юзера в таблице tuneval
1. настройка у нас филиальная - пользовательская. у нас вообще филиальность не используется, но по типу стоит это
2. статистика результатов не дает, пишет в отчет одну строчку когда я последний раз менял эту настройку.
3. запрос в саппорт выдает только одну строчку на этого юзера в таблице tuneval
Код: Выделить всё
select x$users.XU$LOGINNAME, * from tuneval where((
0000000000000085h == tuneval.ctune
and 00010000000001F3h == tuneval.cuser(noindex)
and tuneval.cuser == x$users.atl_nrec
));
-
- Местный житель
- Сообщения: 1357
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: СПб, ЭП-Аудит
- Контактная информация:
хм.2. статистика результатов не дает, пишет в отчет одну строчку когда я последний раз менял эту настройку.
Как вы смотрите статистику? Я имел ввиду:
Настройка \ Администратор \ Статистика обращений к настройкам.
Жмакаем собрать статистику, топаем по интерфесу где вызывается прайс. Жмакаем закончить сбор статистики. Анализируем.
-
- Местный житель
- Сообщения: 2896
- Зарегистрирован: 24 июн 2005, 12:12
- Откуда: Иркутская область
нифига не выскочило на экран и никаких файлов в рабочей директории не создалось
а ещё для юзера стоит доступ к документам только в рамках группы.
заходим в разноску ТХО и видим ВСЕ документы ВСЕХ юзеров.
правда нажав фильтр и тут же продолжить - автоматом срабатывает настройка и записи фильтруются, но они должны фильтроваться после запуска интерфейса!
хорошо что хоть с чужой группой только видно, редактировать нельзя.
неужели 5.4.25 с сюрпризами?
а ещё для юзера стоит доступ к документам только в рамках группы.
заходим в разноску ТХО и видим ВСЕ документы ВСЕХ юзеров.
правда нажав фильтр и тут же продолжить - автоматом срабатывает настройка и записи фильтруются, но они должны фильтроваться после запуска интерфейса!
хорошо что хоть с чужой группой только видно, редактировать нельзя.
неужели 5.4.25 с сюрпризами?
-
- Абориген
- Сообщения: 943
- Зарегистрирован: 29 мар 2005, 17:49
- Откуда: External Developer
- Контактная информация:
Хех...
Ради интереса потестил данную проблему на данном патче и сделал кое-какие выводы.
Может кому интересно, если конечно то что я скажу, известно и попугаю
В Галактике существует два типа настроек -
1. собственно пользовательская (настройки, которые пользователь самостоятельно может настроить под себя). Доступны они из меню Настройка-Настройка любого модуля
2. админсие настройки по пользователям (те, которые админ может настроить каждому пользюку). Доступно из модуля Настройка - Администратор настроек
И, похоже, настройка 1 типа всегда приоритетнее настройки 2 типа. Собственно говоря логически оно правильно - в галке сначала были реализованы настройки 1 типа, а потом на них навешан был функционал настроек 2 типа.
Посему проблема с разрешенными группами прайс-листом может возникнуть в следующем случае :
1. сначала в настройках обоих типов хранились одинаковые значения (наверняка просто ссылка на группу для фильтра) и проблем не возникало
2. затем когда в этом патче реализовали множественный выбор, то в настройке стала храниться не ссылка, а структура (таблица либо маркер - не суть важно). Естественно при реализации данного ф-ла необходимо было сделать проверку и корректную замену значений настроек. По всей видимости сделали проверку при замене настроек 2 типа, забыв про настройку 1 типа.
В итоге получили конфликт значений настроек. Т.к. пользовательская главнее и существует (!) то пофик на админскую для этого же юзера. Вот если запись об этой пользовательской настройке грохнуть, то при проверке настроек, пользовательская создастся а основании админской.
ВЫВОД ил икак попытаться полечить данную проблему
1. Зайти под каждым юзером и грохнуть значение этой насторйки
2. выйти из галки и на всяк случай грохнуть дески
3. зайти под админом и поновой для каждого юзера указать нужные группы прайсов
4. запустить проверку реестра.
по желанию можно пункт 1 заменить ковырянием в табличке tuneval под админскими правами. правда для этого нужно знать что и как удалять, т.е. быть очень аккуратным
По идее должно сработать, НО...
здесь начинаются "идейные противоречия"
т.е. если простому пользователю порезаны права на установку своих настроек (что правильно с точки зрения безопасности и разграничения прав), то сл-но п.1 выполнить нельзя и нужно ковырять таблицу настроек вручную... НО ведь проще и правильнее с точки зрения существующего механизма грохнуть настройку из под пользователя стандартными средствами самой системы...
Вот такой вот парадокс...
Короче еще один мой субъективный вывод - нужно каким-то образом переделать механизм обновления обоих типов настроек при изменении получения значений любой из настроек. Может быть корректно конвертировать, может быть просто удалять пользовательское значение для того чтобы наследовать из админски выставленной... Во всяком случае не мне решать, но в принципе все то что я написал - реализуемо... Другой вопрос когда, кем, в какие сроки...
ПыСы - ногами не пинать, это всего лишь некоторые прикладные выкладки конкретного исследования отдельно взятой проблемы
Выполнено пр всем при этом из чисто спортивного интереса
Ради интереса потестил данную проблему на данном патче и сделал кое-какие выводы.
Может кому интересно, если конечно то что я скажу, известно и попугаю
В Галактике существует два типа настроек -
1. собственно пользовательская (настройки, которые пользователь самостоятельно может настроить под себя). Доступны они из меню Настройка-Настройка любого модуля
2. админсие настройки по пользователям (те, которые админ может настроить каждому пользюку). Доступно из модуля Настройка - Администратор настроек
И, похоже, настройка 1 типа всегда приоритетнее настройки 2 типа. Собственно говоря логически оно правильно - в галке сначала были реализованы настройки 1 типа, а потом на них навешан был функционал настроек 2 типа.
Посему проблема с разрешенными группами прайс-листом может возникнуть в следующем случае :
1. сначала в настройках обоих типов хранились одинаковые значения (наверняка просто ссылка на группу для фильтра) и проблем не возникало
2. затем когда в этом патче реализовали множественный выбор, то в настройке стала храниться не ссылка, а структура (таблица либо маркер - не суть важно). Естественно при реализации данного ф-ла необходимо было сделать проверку и корректную замену значений настроек. По всей видимости сделали проверку при замене настроек 2 типа, забыв про настройку 1 типа.
В итоге получили конфликт значений настроек. Т.к. пользовательская главнее и существует (!) то пофик на админскую для этого же юзера. Вот если запись об этой пользовательской настройке грохнуть, то при проверке настроек, пользовательская создастся а основании админской.
ВЫВОД ил икак попытаться полечить данную проблему
1. Зайти под каждым юзером и грохнуть значение этой насторйки
2. выйти из галки и на всяк случай грохнуть дески
3. зайти под админом и поновой для каждого юзера указать нужные группы прайсов
4. запустить проверку реестра.
по желанию можно пункт 1 заменить ковырянием в табличке tuneval под админскими правами. правда для этого нужно знать что и как удалять, т.е. быть очень аккуратным
По идее должно сработать, НО...
здесь начинаются "идейные противоречия"
т.е. если простому пользователю порезаны права на установку своих настроек (что правильно с точки зрения безопасности и разграничения прав), то сл-но п.1 выполнить нельзя и нужно ковырять таблицу настроек вручную... НО ведь проще и правильнее с точки зрения существующего механизма грохнуть настройку из под пользователя стандартными средствами самой системы...
Вот такой вот парадокс...
Короче еще один мой субъективный вывод - нужно каким-то образом переделать механизм обновления обоих типов настроек при изменении получения значений любой из настроек. Может быть корректно конвертировать, может быть просто удалять пользовательское значение для того чтобы наследовать из админски выставленной... Во всяком случае не мне решать, но в принципе все то что я написал - реализуемо... Другой вопрос когда, кем, в какие сроки...
ПыСы - ногами не пинать, это всего лишь некоторые прикладные выкладки конкретного исследования отдельно взятой проблемы
Выполнено пр всем при этом из чисто спортивного интереса
Последний раз редактировалось Maverick 05 фев 2010, 15:27, всего редактировалось 1 раз.