15.06.2005, 17:20 | #1 |
Модератор
|
Слетают права при импорте проекта
Коллеги!
Никто не сталкивался со следующей ситуацией: при импорте проекта (новый функционал или даже просто измененный существующий) слетают настроенные права доступа. Ключи прописаны. Ситуация возникает, даже если в новом проекте не создавались ключи! Кто-нибудь сталкивался? Как решали проблему? С Уважением, Георгий |
|
15.06.2005, 18:39 | #2 |
Administrator
|
Хм.... напрашиваются сразу 2 версии:
1. Табличка AccessRightsList. Все хранится по ID-шникам. Если ID-шники изменились после импорта - то пиши пропало. Но вероятность этого низка - т.к. изменить ID элемента в АОТ просто так - не просто (ну кроме как опускания в слой). Извратиться конечно можно - но причина скорее всего не в этом 2. Таблички SysSecurity*. Если настройка прав идет по контролам формы (в правах доступа через главное меню и т.д., не через Контроль доступа) - то права хранятся-то привязанные к ID-шникам контролов на форме..... А вот тут-то вы и попали... Добавляется новый контрол, у старого (на который настроены права) - ID-шник слетает.... ну соотв права тоже МОРАЛЬ: права доступа к элементам, которые выделены жирным шрифтом, даже несмотря на то что к ним отсутствует доступ - желательно не менять. Ибо потом форму недоработаешь.... Или же писать утилиту экспорта/импорта прав, работающую по именам контролов ... Опять-таки - отход от стандартной функциональности |
|
15.06.2005, 18:45 | #3 |
Модератор
|
Да, тут у меня тоже подозрения были, со слоями связанные...
Старый-то функционал (утвержденный, так сказать) лежит в cus-слое. А поднимается-то все на usr! Возможно, при этом слетают айдишники. Даже 100% так, хотя и стоит флаг "импортировать со значением идентификаторов". Видимо, у большинства разработчиков разработка идет в одном слое, поэтому и проблема столь специфическая, мало кому известная. Спасибо за советы огромное! Будем подумать, что можно сделать. Мораль учтем! Спасибо огромное, г-н sukhanchik! С Уважением, Георгий |
|
15.06.2005, 18:58 | #4 |
Administrator
|
тогда сразу вам подводный камешек.... ID-шники элементов АОТ имеют для каждой пары слоев свой диапазон - для cus-cup - это 40000-49999. Для usr-usp - 50000-59999. А теперь внимание на экран. В CUS-слой закачивается элемент, у которого ID - из диапазона USR-слоя. В тоже время, в USR-слое имеется элемент, с таким же ID-шником (если просто одинаковые имена, но разные ID - тоже интересно). Аксапта начинает "путать" эти элементы. Лечится - удалением из верхнего слоя и импортом уже без ID-шников (по сути сменой ID-шника).
Конечно это не Ваша ситуация, однако проблема из той же оперы ... |
|
15.06.2005, 19:08 | #5 |
Участник
|
Цитата:
Изначально опубликовано sukhanchik
В тоже время, в USR-слое имеется элемент, с таким же ID-шником (если просто одинаковые имена, но разные ID - тоже интересно). Аксапта начинает "путать" эти элементы. Лечится... Сервис \ Средства разработки \ Переход к новой версии \ Переименованные прикладные объекты Согласен про ID. Но на самом деле, не только они. Были случаи, когда AccessRights слетал и не только при импорте из слоя в слой. Первый признак, что она готовиться к фигне - Admin вдруг не получает права на что-то. Слетание остальных прав - похоже наведенная ошибка. Но какие условия вызывают ограничения админа в правах - так и не понял. я просто нажимаю кнопку установить полные права для админа. George, а у твоего admin полные права? |
|
15.06.2005, 19:16 | #6 |
Модератор
|
2 sukhanchik: Да, фича известная, но от этого не легче
Правда, в идеале у нас должно все работать так: 1 База - разработчиков 2 База - аудит/тестовая 3 База - рабочая в 1 идет разработка на usr. потом накатываются (без идентификаторов) на 2, на usr слой. потом я его чищу, делаю аудит кода, консультант тестирует функциональность, я его поднимаю на cus и тру на usr. Потом Администратор поднимает на рабочую (с идентификаторами cus слоя, присвоившимися в тестовой) и дает права. Так в идеале... Кстати, кажись, на рабочую поднимается на usr?! Брр-р-р попадос... 2 Mazzy: Да, у админа права полные. А хрень со слетом админских прав сам наблюдал неоднократно. С Уважением, Георгий |
|
15.06.2005, 19:23 | #7 |
Administrator
|
Цитата:
а диагностируется запросом
Цитата:
AccessRights слетал и не только при импорте из слоя в слой.
Цитата:
Первый признак, что она готовиться к фигне - Admin вдруг не получает права на что-то
|
|
15.06.2005, 20:31 | #8 |
Участник
|
Цитата:
Изначально опубликовано sukhanchik
Если родительский ключ разрешен, то... |
|
15.06.2005, 22:46 | #9 |
Member
|
Re: Слетают права при импорте проекта
Цитата:
Изначально опубликовано George Nordic
... Никто не сталкивался со следующей ситуацией: при импорте проекта (новый функционал или даже просто измененный существующий) слетают настроенные права доступа. ...
__________________
С уважением, glibs® |
|
16.06.2005, 08:46 | #10 |
Злыдни
|
А почему бы разработчиков не перевести на usp? После ревизии кода подымать его на usr. У usp и usr хоть диапазон id одинаковый.
|
|
16.06.2005, 10:08 | #11 |
Модератор
|
Цитата:
Изначально опубликовано KiselevSA
А почему бы разработчиков не перевести на usp? После ревизии кода подымать его на usr. У usp и usr хоть диапазон id одинаковый. 1) Есть еще "буферные" cup и usp, которые можно задействовать. Правда, реально я этой возможность пользовался всего пару раз, и без неё можно нормально обойтись. Правда, можно еще периодически копировать слой в old, но этим никто не хочет заниматься или постоянно забываем. 2) У нас же на cus права куплены! Надо же их приспособить хоть под что-то! Спасибо всем! Я-то думал, это какая-то наша заморочка. А вон оно как С Уважением, Георгий. |
|
21.09.2005, 11:52 | #12 |
Участник
|
Я с этой проблемой уже совсем замучился, народ подскажите никто не решил ее. А то я только и делаю что права настраиваю в Аксапте. Как только что нибудь импортирую так все права слетают. Я могу только на usr слое программировать. Что делать подскажите?
|
|
21.09.2005, 12:08 | #13 |
Модератор
|
Хе-хе.
Только на usr слое, говоришь? Хорошо. МЫ ТОЖЕ. А теперь внимание: 1) Настраиваешь права, в т.ч. на контролы формы. Все нормально. 2) Пользователь залезает в настройку формы и двигает контролы. 3) Заливаем модификацию 4) Что такое? Где наши прива?? Короче, как вариант: делай бэкап таблиц SysSecurityFormControlTable и SysSecurityFormTable перед накаткой модификаций. Если будешь импортировать со значениями идентификаторов и потом восстанавливать эти таблицы, то есть вероятность, что права не поедут. Но ну нас это прокатывает через раз... Есть подозрение, что сама форма раздачи прав несет в себе какую-то бяку... При построении дерева что-то не то. Если дороешь, дай знать, ок? Да, и письмишко напиши. С Уважением, Георгий. |
|
21.09.2005, 17:00 | #14 |
Administrator
|
Из нарытого
1. Форма раздачи прав несет в себе лишь ту бяку - что при первом просмотре дерева права грузятся в память, после чего там и остаются... до перезапуска Аксапты. Более бяк там нет... Она просто строит дерево 2. Бэкап таблиц SysSecurity* по-хорошему надо делать по-другому: Модифицируется экспорт/импорт прав в Аксапте таким образом - чтобы в получившемся файле лежали только ИМЕНА элементов АОТ. Т.е. по сути - нужно экспортнуть таблички AccessRightsList и таблички SysSecurity*, заменив при экспорте ID-шники на имена. Ну и ессно обратно - при импорте - подставив вместо имен текущие значения ID-шников. При экспорте - надо не забыть сохранить права перед экспортом. После импорта - их надо перегрузить и обновить дерево в форме Файлы, в которых сохранены права - можно хранить в сейфе 3. Упаси Бог изменять права в трехуровневой конфигурации. Аксапта сохраняет права по принципу кто последний вышел из нее - тот и прав. А если вы настроили права, а после этого другой юзер вышел - можете смело считать свою работу напрасной. При импорте прав (т.е. изменении данных в табличках) - крайне нежелательно вообще иметь АОС под рукой.... Ибо его наличие аккурат приводит к глюкам, описанным George Nordic Цитата:
Но ну нас это прокатывает через раз
__________________
Возможно сделать все. Вопрос времени |
|
23.03.2006, 13:10 | #15 |
----------------
|
Проверка прав после каждого переноса
Написал жобик для проверки прав настроенных на отдельные поля (любые элементы) формы.
PHP код:
|
|
|
За это сообщение автора поблагодарили: Dron AKA andy (2), glibs (5), Logger (5). |
23.03.2006, 16:47 | #16 |
Участник
|
Запустил этот джоб, что за информацию он выдал? Как использовать информацию которую он выдал?
|
|
23.03.2006, 17:32 | #17 |
----------------
|
синие - актуальные настройки права на элементы формы
красные - утерянные настройки |
|
23.03.2006, 20:50 | #18 |
Member
|
А я думал, оно сразу и чинит...
Хотя, и за это спасибо.
__________________
С уважением, glibs® |
|
24.03.2006, 13:17 | #19 |
----------------
|
версия 2 - продвинутая
Добавлена возможность автоматического исправления ошибок и удаления мусора.
Как любое автоматическое исправления, имеет свои "особенности". Если будете использовать, то сначала потестируйте внимательно. PHP код:
|
|
|
За это сообщение автора поблагодарили: glibs (4), George Nordic (5), Qaz Qwerty (1). |
06.11.2008, 18:25 | #20 |
Участник
|
Wamr спасибо вам за предоставленную информацию.
От себя еще добавлю, что настройка прав доступа на уровне контролов на форме (когда используются таблицы SysSecurityFormTable, SysSecurityFormControlTable) может глючить самым смешным образом. Реальный пример. 1. Используются домены. 2. Ключ доступа к доменам включен (возможно это не влияет на воспроизводимость глюка, привожу просто для справки) 3. Есть 2 компании 100 и 200. Им соответсвуют домены Домен100 и Домен200 4. Пользователь является членом групп Admin и Группа1 5. Для группы Группа1, формы Справочник1 и домена Домен200 в табличках SysSecurityFormTable, SysSecurityFormControlTable заведены настройки, скрывающие определенные. 6. Справочник1 отображает данные из виртуальной компании - так что все равно откуда его открывать. Теперь прикол. Если пользователь первый раз открывает форму справочник1 в компании 100 (т.е. Домен100) - то все нормально - кнопки ему доступны. Если же он первый раз открывает форму справочник1 в компании 200 (т.е. Домен200) - то кнопки ему уже недоступны ! Если при этом переключиться в компанию 100 и открыть справочник там, то кнопки станут доступны. И будут доступны, если обратно перключиться в компанию 200 и открыть в 3-й раз форму справочник1. Такое ощущение что один раз догрузив правильные настройки - система их уже не меняет. Все это очень странно. Выглядит как шаманство. Самое паршивое, что глюк действует на Админа ! Теперь понимаю почему техподдержка в ответ на просьбы настроить права нервно скрежещет зубами и тихо матерится. P.S. Ax 3.0 KR3 SP5 1-й джоб wamr-a натравил - проблем не выявлено. Красных сообщений не было. Только выведена информация о том какие кнопки скрыты. Последний раз редактировалось Logger; 06.11.2008 в 18:29. |
|