Доступ к журналу для пользователей
Модератор: mike
-
- топ-софт
- Сообщения: 34
- Зарегистрирован: Вт, 23/10/2007 14:15
- Имя Фамилия: Александр Соколов
- Откуда: Галактика-Урал
- Контактная информация:
Доступ к журналу для пользователей
Как можно обеспечить доступ к журналу (а точнее до таблицы x$journal) для простых пользователей на платформах Oracle и MS SQL? Если используется модуль права доступа.
-
- топ-софт
- Сообщения: 566
- Зарегистрирован: Пт, 21/09/2007 15:19
- Имя Фамилия: Фёдор Терсин
- Откуда: Галактика Софт
- Контактная информация:
Re: Доступ к журналу для пользователей
Через Атлантис - никак.
А зачем?
А зачем?
-
- топ-софт
- Сообщения: 34
- Зарегистрирован: Вт, 23/10/2007 14:15
- Имя Фамилия: Александр Соколов
- Откуда: Галактика-Урал
- Контактная информация:
Re: Доступ к журналу для пользователей
Уже у второго клиента возникает потребность запускать отчет из под пользователя, который должен выполнять запрос по таблице x$journal.cruger писал(а):Через Атлантис - никак.
А зачем?
И понятно - администратору выводятся данные по запросу, а пользователю - пустая таблица.
1? Можно или нет дать права пользователю средствами администрирования СУБД для получения данных для конкретного пользователя по журналу - или это нельзя сделать?
2? Если можно, то каким образом?
-
- топ-софт
- Сообщения: 566
- Зарегистрирован: Пт, 21/09/2007 15:19
- Имя Фамилия: Фёдор Терсин
- Откуда: Галактика Софт
- Контактная информация:
Re: Доступ к журналу для пользователей
Отчёт, очевидно, вытаскивает данные по изменениям. По каким изменениям? В общем случае - по любым. В т.ч. по таким, на которые у обычных пользователей прав нет. Например, по какой-то таблице, которую пользователь не видит. А тут, получается, конкретный пользователь должен видеть всё. Ну так сделайте его админом, раз у него такие большие права.
Права обычному пользователю никаким образом дать не удастся.
Права обычному пользователю никаким образом дать не удастся.
-
- заказчик
- Сообщения: 17
- Зарегистрирован: Пт, 14/09/2007 08:06
- Имя Фамилия: Надежда Морозова
- Откуда: СИТНО
Re: Доступ к журналу для пользователей
Поддерживаю потребность пользователей в доступе к таблице x$journal.
Например, нужно сделать анализ: как менялись цены в прайс-листе. У пользователя права на прайс-лист есть. Но анализ изменения цен он сделать не может, т.к. нет доступа к таблице x$journal.
Например, нужно сделать анализ: как менялись цены в прайс-листе. У пользователя права на прайс-лист есть. Но анализ изменения цен он сделать не может, т.к. нет доступа к таблице x$journal.
-
- топ-софт
- Сообщения: 65
- Зарегистрирован: Пт, 07/09/2007 11:57
- Имя Фамилия: Александр Крахотко
- Откуда: ТопСофт
- Контактная информация:
Re: Доступ к журналу для пользователей
мне кажется нужно делать доступный для прикладников второй механизм (наверное он должен использовать журнализацию) но API должно быть немного другим (например содеражать и типовую визуальную часть). Дело в том, что независимо от того используется журнализация или нет, прикладная функция должна работать... ну или хотя бы выдавать сообщение "просмотр истории изменения [цены] недоступен в виду отсутствия журнализации". это должен быть некий системный API, а предоставлять прямой доступ к системной таблице напрямую неправильно.
-
- топ-софт
- Сообщения: 566
- Зарегистрирован: Пт, 21/09/2007 15:19
- Имя Фамилия: Фёдор Терсин
- Откуда: Галактика Софт
- Контактная информация:
Re: Доступ к журналу для пользователей
А кто будет проверять, имеет ли пользователь права на доступ к данным журнала? И как разруливать протектные фильтры? Типа, новое состояние (удовлетворяющее протектным фильтрам) видно, а старое состояние - нет? А ведь ещё разруливать права на поля (совсем не журнала, но ограничивать придётся по журналу).
Тут, сдаётся мне, глюков будет больше чем пользы.
Штука в том, что как обычно - механизм (журнализация) делалась для одного, её пытаются попользовать для другого. Неудобно, вот и возникают такие предложения.
А если сделать, то возникнут другие неудобства. Сходу: такую историю захочется видеть за длительный промежуток времени. Стало быть придётся в БД хранить большой журнал. БД будет расти, клиенты жаловаться на необоснованный рост БД и торомоза... Сходу предвижу следующее предложение: сделать чистку журнала настраиваемой потаблично, ;)
И ведь это только начало.
А на самом деле стоит грамотно сформулировать исходную задачу, как сразу становится понятно, что хоть журнал и даёт что-то похожее, но это как операция битового сдвига похожа на умножение: да, умножить на степени двойки можно, а вот на что-то другое - сложнее.
Давным давно стоит задача возможности хранения истории изменений каких-то ключевых полей определённых таблиц. Совершенно без привязки к журнализации. Ибо нужно это для другого.
История изменений фамилий сотрудников, названий контрагентов...
В общем - это отдельная задача, и решать её надо отдельно. А журнал оставить в покое: он работает так, как и должен работать для решения поставленных перед ним задач.
Тут, сдаётся мне, глюков будет больше чем пользы.
Штука в том, что как обычно - механизм (журнализация) делалась для одного, её пытаются попользовать для другого. Неудобно, вот и возникают такие предложения.
А если сделать, то возникнут другие неудобства. Сходу: такую историю захочется видеть за длительный промежуток времени. Стало быть придётся в БД хранить большой журнал. БД будет расти, клиенты жаловаться на необоснованный рост БД и торомоза... Сходу предвижу следующее предложение: сделать чистку журнала настраиваемой потаблично, ;)
И ведь это только начало.
А на самом деле стоит грамотно сформулировать исходную задачу, как сразу становится понятно, что хоть журнал и даёт что-то похожее, но это как операция битового сдвига похожа на умножение: да, умножить на степени двойки можно, а вот на что-то другое - сложнее.
Давным давно стоит задача возможности хранения истории изменений каких-то ключевых полей определённых таблиц. Совершенно без привязки к журнализации. Ибо нужно это для другого.
История изменений фамилий сотрудников, названий контрагентов...
В общем - это отдельная задача, и решать её надо отдельно. А журнал оставить в покое: он работает так, как и должен работать для решения поставленных перед ним задач.