Права по умолчанию

Ну как бы это нехорошо работает... вроде не должно такого быть
а группа "Все пользователи" у вас кому права по-умолчанию дает? может отсюда ноги растут если этот пользователь в ней еще состоит... и сам он лично кому права по-умолчанию дает, надо все варианты проверить
вообще скрины настройки прав и детали "группы" для пользователя в студию:smile:

Как видно из прикрепленных картинок группа Все пользователи(pic1) дает ограниченные права всем пользователям и полные права группе администраторов. Аналогичные скрины с правами по умолчанию для групп Call-центр(pic2) и Бронисты(pic3). Скрин с группами, в которые входит пользователь - pic4. Результат создания записи в разделе контакты - деталь Права доступа - pic5. Явно здесь строка Бронисты лишняя.

А скрин где права по умолчанию для самого пользователя (не для группы)? вот если и там Бронисты не фигурируют...

Права по умолчанию конкретных пользователей пока не было надобности настраивать, поэтому про этот скрин забыл. Но и там бронисты не фигурируют (pic6).

"Ozzy" написал:Права по умолчанию конкретных пользователей пока не было надобности настраивать, поэтому про этот скрин забыл. Но и там бронисты не фигурируют (pic6).

Посмотрите, пожалуйста, с помощью профайлера, какие запросы выполняются при добавлении нового контакта этим пользователем. Особенно интересуют запросы на вставку (Insert).

Также прошу уточнить последовательность действий. Пользователь добавляет контакт сразу же после того, как его перенесли в другую группу, или это происходит после перезапуска системы?

Пользователя из одной группы в другую я перенес давно (около месяца назад). Просто проблему заметил только сейчас. Пользователь просто добавляет Контакт.
SQLMonitor'ом удалось отследить что вставка происходит в две таблицы "tbl_CompetitiveSession" и "vw_Contact". К правам доступа они не имеют никакого отношения. Делаем вывод, что раздача прав происходит на уровне триггеров сервера, генерируемыми автоматически Администратором. Сервер Oracle.
В триггере права берутся из таблицы "tbl_ContactRight". А вот почему при удалении пользователя из группы не удалились права по умолчанию для этого (и для других тоже) пользователя я не скажу. Что и где надо исправить чтобы в дальнейшем работало всё корректно и как привести права по умолчанию в соответствие с текущими настройками пользователей и групп?

Проблема только при добавлении контактов, или возникает также и при добавлении записей в другие разделы? Если только с контактами, проверьте, пожалуйста, тексты триггеров на вставку у tbl_Contact и vw_Contact. Если с ними всё в порядке (принципиально не отличаются от других триггеров), значит, необходимо анализировать записи таблиц tbl_AdminUnit, tbl_UserAdminUnit, tbl_UserInGroup, связанные с пользователем.

Может помочь отвязка пользователя от всех групп и привязка заново. Если не поможет, попробуйте выполнить хранимую процедуру tsp_UpdateAllUsersGroup, которая восстановит актуальную информацию по пользователям в группах. Крайне желательно перед выполнением сделать резервную копию базы.

Аналогичная проблема возникает и с Контрагентами. На других разделах не проверял, потому что права по умолчанию не раздавались. В триггерах на представление vw_Contact права не выставляются. А вот в триггере на tbl_Account (tbl_Contact тоже) права берутся из таблицы tbl_TableDefaultRight. В предыдущем посте

"Ozzy" написал:В триггере права берутся из таблицы "tbl_ContactRight". А вот почему при удалении пользователя из группы не удалились права по умолчанию для этого (и для других тоже) пользователя я не скажу.

Можете выгрузить из Вашей конфигурации все сервисы и выслать на адрес support@tscrm.com для сравнения с базовыми? Дело в том, что при попытке воспроизвести ситуацию на конфигурации, на которой изначально велась разработка Вашего проекта, права по умолчанию раздались корректно. Если Вы не вносили изменений в базовые хранимые процедуры, тогда причина в сервисах.

Сервисы лучше выгружать утилитой tsmergeservices.exe с параметрами: /cfg="<Название конфигурации>" /usr="<Имя пользователя>" /pwd=<Пароль> /fmt=true /js=true

Ушло письмо на сапорт с сервисами.

Как оказалось, проблема была в том, что не отрабатывало удаление в конце процедуры tsp_LoadUserAdminUnit:

DELETE FROM "tbl_UserAdminUnit"
  WHERE UPPER("UserName") = RoleName
    AND NOT EXISTS(
      SELECT *
      FROM (
        SELECT DISTINCT
         au."ID" AS "AdminUnitID",
         drp.granted_role AS "AdminUnitName",
         RoleName AS "UserName"
	 FROM DBA_ROLE_PRIVS drp,
       "tbl_AdminUnit" au
	 WHERE UPPER(au."SQLObjectName") = UPPER(drp.granted_role)
   START WITH UPPER(drp.grantee) = RoleName
	 CONNECT BY PRIOR drp.granted_role = drp.grantee
	 UNION
	 SELECT AdminUnitID, RoleName, RoleName
 	 FROM dual) t
   WHERE t."AdminUnitID" = "tbl_UserAdminUnit"."AdminUnitID"
   AND UPPER("tbl_UserAdminUnit"."UserName") = RoleName);

А именно, хотя внутренний запрос (SELECT DISTINCT) возвращал корректные значения, но выборка из этого результата внешним запросом (SELECT *) возвращала пустой набор данных. Почему так происходило, определить не удалось. Александр, у наших разработчиков возникло предположение, что на Вашей версии Oracle установлены не все обновления, которые есть на текущий момент. Возможно, проблема была в этом.

Решить удалось путём изменения запроса таким образом, чтобы убрать внешний SELECT:

DELETE FROM "tbl_UserAdminUnit"
  WHERE UPPER("UserName") = RoleName
    AND "AdminUnitID" NOT IN (
        SELECT DISTINCT
         au."ID"
     FROM DBA_ROLE_PRIVS drp,
       "tbl_AdminUnit" au
     WHERE UPPER(au."SQLObjectName") = UPPER(drp.granted_role)
   START WITH UPPER(drp.grantee) = RoleName
     CONNECT BY PRIOR drp.granted_role = drp.grantee
     UNION
     SELECT AdminUnitID
      FROM dual);

Спасибо, всё заработало как надо.