права доступа | Community Creatio

Установка и Администрирование

справочник

Настройка прав доступа пользователей для справочника "Банки"

Алейник Алексей Вадимович

9 января 2014 15:14

Здравствуйте!

Бухгалтеру понадобилось добавить новую запись в справочник "Банки". Кнопки "Добавить", "Копировать", "Изменить" и "Удалить" оказались неактивными (заблокированными). Администратор, в свою очередь, наделён необходимыми правами и все кнопки активны. Как наделить правами пользователей, чтобы те могли работать со справочниками? В разделе "Администрирование" не нашёл как раздать права пользователям именно для справочников.

Нравится

1 комментарий

Бондарь Наталия

9 января 2014 18:35

Вам необходимо установить права доступа в разделе [Администрирование] - [Права доступа к группам таблиц] на группу таблиц "Справочники":

/system/files/09-01-2014_18-33-41.png

Ответить

Показать все комментарии

Публикация

MS SQL

3.x

права доступа по умолчанию

Скрипты

Коррекция прав доступа

1. С чего я начал - скорее для истории, чем для нужд населения
2. проходной вариант
3. Уже что-то полезное (Скрипт JS)
4. Самое вкусное для терпеливых

25 июля 2013 15:52

В Террасофт реализована вполне удобная система раздачи прав. По крайней мере, если разобраться :wink:

Но она позволяет настраивать только права на будущие записи. Те, которые уже созданы, приходится обрабатывать поштучно (в 3.4.1 можно уже постранично :biggrin: ).
Что же делать бедным администраторам или CRM-координаторам, когда надо, например, ввести новую группу пользователей или переопределить права для старой - ведь это должно касаться, как новых, так и уже созданных записей.

В моей практике подобные ситуации встречались уже не раз. В конце концов, я устал мастерить костыли и сделал себе несколько скриптов для решения подобных задач.

Делюсь с вами.
Считаю, что если Вы читаете это, значит Вы уже знаете, что такое tbl_AccountGroupRight, sq_Service, ds_ItemRight, Dataset.IsEOF, declare cursor и т.д. Хотя это вовсе необязательно, чтобы использовать скрипты - просто мне лень их полностью комментировать :redface:

Нравится

7 комментариев

25 июля 2013 15:56

1. С чего я начал - скорее для истории, чем для нужд населения :smile:

Добавление прав на продажи_контакты_контрагенты для пользователя\группы

CREATE TABLE #tbl_OpportunityRight(
	[ID] [uniqueidentifier] NULL,
	[RecordID] [uniqueidentifier] NULL,
	[AdminUnitID] [uniqueidentifier] NULL,
	[CanRead] [int] NULL,
	[CanWrite] [int] NULL,
	[CanDelete] [int] NULL,
	[CanChangeAccess] [int] NULL)
go 
 
insert into #tbl_OpportunityRight (RecordID) (select ID from tbl_Opportunity where ID in (select OpportunityID from tbl_OpportunityInGroup where GroupID = 'B66CAAD9-AF6B-4F12-B88C-1E3453F591C4'))
 
go
 
update #tbl_OpportunityRight set ID = NEWID(), AdminUnitID = '687D0624-5B5E-4F19-961E-D9F03A96939A', CanRead = '1', CanWrite = '1', CanDelete = '0', CanChangeAccess = '0';
 
insert into tbl_OpportunityRight select * from #tbl_OpportunityRight

Выставить прав для определенного пользователя\группы в конкретной таблице

update tbl_OpportunityRight set CanDelete = '0', CanWrite = '0', CanChangeAccess = '0'
	where ID in (select ID from tbl_OpportunityRight where AdminUnitID = 'D268BFB9-8118-4E3B-9F06-1D703D25C23E' and CanWrite = '1')

_service.rar

Ответить

tsp_updaterightsbydefaults.rar

25 июля 2013 16:12

2. В контексте решения одной задачи и после долгих мучений была создана процедура:
особого внимания ей уделять не стоит - это проходной вариант

В конкретной таблице (параметр) для конкретной записи (параметр) выставляет права, как будто она была создана от имени конкретного пользователя (параметр) входящего в конкретную группу (не параметр)

USE [Our_backup]
GO
/****** Object:  StoredProcedure [dbo].[tsp_UpdateRightsByDefaults]    Script Date: 07/25/2013 16:57:21 ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE procedure [dbo].[tsp_UpdateRightsByDefaults] 
	@ARightTableName sysname,
	@Owner_ID uniqueidentifier,
	@Record_ID uniqueidentifier,
	@ADBSchema sysname = 'dbo'
with execute as 'fkeys'
AS
BEGIN
	SET NOCOUNT ON;
  DECLARE @ServiceTableID uniqueidentifier
  DECLARE @AdminUnitID uniqueidentifier
  DECLARE @RecordID uniqueidentifier
  DECLARE @TableRightsName varchar(250)
  DECLARE @DefaultGroupID uniqueidentifier
  set @DefaultGroupID = (select ID from [tbl_AdminUnit] where Name = 'продажники') -- меняем имя или пишем конкретный ИД
 
  SET @ServiceTableID = (SELECT [ID] 
  FROM [dbo].[tbl_Service] 
	   WHERE [Code] = (replace(@ARightTableName, 'Right', ''))
    AND [ServiceTypeCode] = N'Table')
 
  SET @AdminUnitID = (SELECT ID from [dbo].[tbl_AdminUnit] where UserContactID = @Owner_ID)
  SET @TableRightsName = '[' + @ADBSchema + '].[' + @ARightTableName +']'
  SET @RecordID = @Record_ID
 
 exec(' DELETE' +@TableRightsName + ' where RecordID = ''' + @RecordID + ''' 
 
  INSERT INTO ' +@TableRightsName + ' (
    [ID]
    ,[RecordID]
    ,[AdminUnitID]
    ,[CanRead]
    ,[CanWrite]
    ,[CanDelete]
    ,[CanChangeAccess])
  SELECT
    newid()
    ,''' + @RecordID + '''
    ,''' + @AdminUnitID + '''
    ,1
    ,1
    ,0
    ,0
 
  INSERT INTO ' + @TableRightsName + ' (
    [ID]
    ,[RecordID]
    ,[AdminUnitID]
    ,[CanRead]
    ,[CanWrite]
    ,[CanDelete]
    ,[CanChangeAccess])
  SELECT
    newid()
    ,''' + @RecordID + '''
    ,[D].[SubjectAdminUnitID]
    ,[D].[CanRead]
    ,[D].[CanWrite]
    ,[D].[CanDelete]
    ,[D].[CanChangeAccess]
  FROM (
    SELECT
      [D].[SubjectAdminUnitID]
      ,MAX([D].[CanRead]) AS [CanRead]
      ,MAX([D].[CanWrite]) AS [CanWrite]
      ,MAX([D].[CanDelete]) AS [CanDelete]
      ,MAX([D].[CanChangeAccess]) AS [CanChangeAccess]
    FROM [dbo].[tbl_TableDefaultRight] AS [D]
    WHERE ([D].[TableServiceID] = ''' + @ServiceTableID + ''')
    AND ([D].[AdminUnitID] = ''' + @DefaultGroupID + ''' 
		 )
  GROUP BY [D].[SubjectAdminUnitID])
	AS [D]
 ')
	SET NOCOUNT OFF;
END

PS. Не забываем - на процедуры надо давать права на исполнения для роли public

Ответить

25 июля 2013 16:11

3. Уже что-то полезное
Скрипт (JS для клиента - не SQL!!)

Добавляет во все записи все таблиц прав права для конкретного пользователя\группы. Либо редактирует, если уже есть такие права.
Опустил из скрипта таблицы прав на записи групп (например tbl_AccountGroupRight) - т.к. это было не надо, и там немного запутанно - не стал тратить время

ВАЖНО:
* создавался на версии 3.4.1
* для sq_Service надо добавить фильтр IsRightsTable:

//см приложение

scr_recreaterigths.rar

Ответить

prava_po-umolchaniyu_po_otvetstvennomu.rar
prava_po-umolchaniyu_po_sozdatelyu.rar

25 июля 2013 16:27

4. Самое вкусное для терпеливых :biggrin:
основано на скриптах от техподдержки, которые (в связи со спецификой :wink:) у меня работали неправильно или вообще не.
делал на 3.4.1 XRM

Раздает, используя механизм аналогичный базовому из триггеров для прав, права по-умолчанию для ВСЕХ записей ВСЕХ таблиц, для которых есть таблица прав. Таблицы берутся по принципу:

SELECT
	s1.[Code] AS [Code]
FROM
	[tbl_Service] AS s1
WHERE s1.[ServiceTypeCode] = 'Table'
and s1.Code <> 'tbl_TableField'
and exists( 
  select * from tbl_Service as s2
  where s2.Code = s1.Code + 'Right'
)

В двух вариантах:
1. как будто запись создал тот, кто ее создал :lol: (CreatedByID), если есть такой юзер, иначе подставляется из переменной @DefaultGroupID - не забудьте поставить свое
2. как будто запись создал ответственный (OwnerID), если есть такое поле в таблице и такой юзер, иначе - как в п.1

есть такой юзер означает, что заведен (и не удален, как было в моем случае) пользователь с таким контактом и он активен (активность необязательна - смотрите сами, надо ли):

	set @UserIsActive = (SELECT COUNT (*) FROM tbl_AdminUnit WHERE UserContactID = @OwnerID and UserIsEnabled = 1) -- UserIsEnabled = 1 опционально
	if (@UserIsActive != 0)
		set @AdminUnitID = (SELECT ID FROM tbl_AdminUnit WHERE UserContactID = @OwnerID)
	else set @AdminUnitID = @DefaultGroupID

Ответить

26 июля 2013 10:12

осторожнее с правами на записи, созданные Supervisor'ом (такие, как например, корневые группы типа Все контрагенты) - создайте для него права по-умолчанию, чтобы не было проблем

Ответить

30 июля 2013 10:10

я бы даже советовал вообще исключить группы записей из этого процесса

Ответить

24 февраля 2014 14:41

актуальная версия сервисов
извините, нет времени описывать
defaultrigths.rar

Ответить

Показать все комментарии

Вопрос

контакт

Установка и Администрирование

Права доступа к карточке Контакт

Соляник Алексей

18 февраля 2013 09:26

Добрый день!

Подскажите, пожалуйста, как правильно выставить права, чтобы карточку "Контакт" мог редактировать только тот человек, кто ее создал/ ответственный.

Ну и администраторы, естественно.

Спасибо!

Нравится

4 комментария

Арсений Белецкий

18 февраля 2013 11:25

Добрый день!

Для того, что бы реализовать необходимую раздачу прав доступа на запись Контакта, Вам необходимо воспользоваться разделом [Права доступа по умолчанию].

В этом разделе:

1. Выбираете группу Все пользователи
2. Отмечаете раздел [Контакты]
3. Указываете в детали [Доступ] группу Все пользователи - чтение

Во как это должно выглядеть:

Данная раздача прав доступа позволяет автору получить максимальные права доступа на свою запись (прописано в скриптах по умолчанию), Всем пользователям только на чтение, а Администратор и так имеет все права доступа, на него раздавать не обязательно :wink:

Хочу заметить, что данная настройка будет применяться только на новые записи.
Прошу настроить и проверять!

Хорошего дня!

С уважением,
Белецкий Арсений
Группа компаний Terrasoft

Ответить

Соляник Алексей

18 февраля 2013 11:42

Добрый день!
Обошел программно, так оказалось удобнее.

Спасибо!

Ответить

Осауленко Александр

18 февраля 2013 12:07

"Соляник Алексей" написал:Обошел программно, так оказалось удобнее

Алексей, возможно программно и удобнее в некоторых случаях, но такой подход чреват проблемами. Вы это реализовали в самой карточке? А что если у вас "Контакт" редактируется из разных мест и необязательно через карточку: кастомные запросы update, интеграции на уровне СУБД (хранимки) и т.п.? Правильно логику, которую вы описали, организовывать через существующие права на уровне СУБД, как показал Арсений. Так как это и в карточке будет работать и во всех местах где идет работа с данными Контакта.

Ответить

Соляник Алексей

18 февраля 2013 15:11

Александр, спасибо! Я обязательно учту на будущее!

Ответить

Показать все комментарии

Вопрос

Отражение записей в разделе Процессы

Тихенко Виктория

9 февраля 2013 12:15

Добрый день всем.

Помогите понять как правильно настроить отображение записей в разделе Процессы.

Я администратор системы, у меня в этом разделе отражаются списком запущенные всеми пользователями элементы процессов.
У всех остальных пользователей такой роскоши нет. Обычные пользователи в этом разделе видят (ВНИМАНИЕ !) те элементы которые были ими созданы для следующих в процессе исполнителей, те элементы, за которые ответственны другие! А свои элементы они увидеть списком в этом разделе не могут, исключение если пользователь сам выполняет и следующую задачу. В любому случае для таких пользователей раздел по сути бесполезный.

Вопрос возможно в раздаче прав доступа:
1) фильтра по создателю элемента процесса я так и не нашла, а раздел все же фильтруется
2) в разделе Настройка прав доступа в закладке права доступа по умолчанию раздела Процессы нет.
3) таблица tbl_Workflow не администрируется по записям (видимо из-за этого пункт 2)
4) если поставить таблицу tbl_Workflow администрироваться по записям, то у всех пользователей вообще появляется ошибка при попытке открыть свои задачи созданные по процессу, из-за ошибки прав доступа к ним.

Что было бы необходимо:
или отражать в разделе все элементы всех процессов не зависимо от того, кто является создателем
или отражать элементы за которые пользователь ответственный + которые он создал + все элементы по процессу который он создал.

Версия ТС 3.3.2.287
Заранее спасибо.

Нравится

2 комментария

Фильковский Павел

11 февраля 2013 12:59

Доюрый день.
Попробуйте изменить фильтр OwnerID в сервисе Workflow\General\Main Grid\sq_Workflow

Старый вариант я переименовал в OwnerID___
Новый - вместо Фильтра сравнения, добавлен "Набор фильтров" : OwnerIDFilter, AuthorIDFilter.

Ответить

Тихенко Виктория

12 февраля 2013 10:59

Сделать надо было так , да не совсем так.

В указанных двух CompareFilter надо фильтровать не tbl_Workflow, а tbl_WorkflowItem.
И во втором фильтре конечно по полю CreatedByID.

Спасибо за указание направления , где искать.

Ответить

Показать все комментарии

Вопрос

Технические вопросы

Нет доступа к записи журнала tbl_DocumentLog

8 февраля 2013 15:12

У пользователя (не являющегося администратором), создавшего запись в таблице tbl_Document, есть права на изменение этой запись в представлении vw_Document (проверяю с помощью MS SQL Server Management Studio), но нет прав на изменение соответствующей записи в журнале (представление vw_DocumentLog). В записи таблицы tbl_DocumentRight для этой записи и этого пользователя во всех столбцах CanXXX стоит 1.

При попытке обновления записи в журнале выводится сообщение:
TSObjectLibrary.UpdateQuery: The UPDATE permission was denied on the object 'vw_DocumentLog', database 'Terrasoft', schema 'dbo'

Что не так?

Нравится

7 комментариев

8 февраля 2013 15:29

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

Ответить

8 февраля 2013 16:28

Смысл в том, что, при переводе документа в состояние Отменен, пользователь должен указать причину, которая затем записывается в журнал. Для пользователя-администратора это работает.

Ответить

Тихенко Виктория

11 февраля 2013 10:28

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

Ответить

11 февраля 2013 11:24

Антон. Вижу для Вас два выхода - подправить триггер tr_tbl_Document_IU так, как Вам будет удобно. Либо дать права пользователям на vw_DocumentLog на Вставку. Ну или не переиначивать заложенную логику, а сделать как-то по-другому - например, при изменении стадии на Отменен делать видимым и обязательным поле "Причина отмены" (или типа того).
Для этого надо:
1) Добавить это поле edtCancelReason (или типа того) и сделать его невидимым и необязательным
2) В функцию function dlDataOnDataChange скрипта scr_DocumentEdit после

		case ('DocumentTypeID'):
			edtState.UnprepareDropDownList();
			break;

добавить

		case ('StateID'):
			edtCancelReason.IsVisible = Dataser.ValAsGUID('StateID') == '{сюда вписать ID из таблицы tbl_DocumentState для записи "Отменен" - фигурные скобки оставить}';
			DataField.IsRequired = Dataser.ValAsGUID('StateID') == '{сюда вписать ID из таблицы tbl_DocumentState для записи "Отменен" - фигурные скобки оставить}';
			break;

Ответить

11 февраля 2013 13:17

Спасибо, Виктория и Дмитрий. По ТЗ причина отмены должна записываться именно в Журнал изменений и там же отображаться. Триггер изменять не вариант, т.к. он автоматически перезаписывается при обновлении сервиса таблицы tbl_DocumentLog. Вдруг потом он будет кем-то обновлен, а случаи бывают разные :). Просто дам права на обновление vw_DocumentLog.

Ответить

Осауленко Александр

11 февраля 2013 14:19

"Антон Батюк" написал:Просто дам права на обновление vw_DocumentLog

Антон, давать права на изменение таблицы или вью журнала я бы не рекомендовал. На то он и журнал, чтобы он был в режиме чтения. Лучше создайте хранимку и полностью контролируйте, что будет сделано с данными (например, нельзя менять какую-то колонку или записи, которые создал не я), и дайте права на ее запуск всем. Запускайте ее в том месте, где у вас в конфигурации кастомная логика.
С уважением, Александр

Ответить

Не отображать деталь, если нет прав на раздел

11 февраля 2013 16:17

Да, Александр, это была моя первоначальная идея - с хранимой процедурой, запускаемой от имени администратора. Права тоже автоматически перезатираются при изменениях в клиенте в разделе Администрирование. Спасибо! Хранимая - "железный" вариант.

Ответить

Показать все комментарии

Вопрос

Ozzy

26 декабря 2012 17:06

Добрый день!

Создал раздел Карты. Раздал права доступа необходимым группам пользователей. Раздел отображается правильно только для тех пользователей, у которых есть права хотя бы на чтение записей этого раздела. На основании грида этого раздела создал деталь Карты в разделе Контакты. Но эта деталь отображается всем пользователям без исключения (без записей). Возможно ли сделать какую-то проверку, и, в случае, если у пользователя нет прав хотя бы на чтение для раздела Карты, не отображать эту деталь вообще? Желательно подробней на какие события какой скрипт прописать.

Нравится

5 комментариев

27 декабря 2012 12:53

Здравствуйте!

Да, можно сделать такую проверку. Для этого следует в скрипте раздела Контакты в процедуре function RefreshDetails() добавить следующий программный код:

pgMapsDetail.IsVisible = GetCanReadData('tbl_Maps');

Ответить

Ozzy

27 декабря 2012 13:29

Спасибо, Анна, помогло.

Ответить

Ozzy

27 декабря 2012 17:16

Все-таки поспешил я сказать что помогло. Точнее совет помог, но т.к. профиль пользователя сохраняется, то когда у пользователя появляются права на чтение этого раздела, деталь больше не появляется, потому что она сохранена как невидимая. Можно как-то решить эту ситуацию?

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

Ответить

Ошибка применения пользовательского фильтра

9 января 2013 10:10

Здравствуйте!

В данном случае добавьте ту же проверку в функцию InitializeGridData() в том же скрипте.

Ответить

Ozzy

10 января 2013 09:26

Всё работает, спасибо.

Ответить

Показать все комментарии

Вопрос

Пользовательский фильтр

Ozzy

26 декабря 2012 16:54

Добрый день!

TS 3.3.2.211, Оракл

Создал раздел Карты. Раздал права доступа необходимым группам. У группы все пользователи нет прав на этот раздел вообще. В разделе Контакты создал пользовательский фильтр ссылающийся на созданный раздел. Для пользователя, у которого есть права на раздел Карты фильтр работает идеально. Если у пользователя нет прав на этот раздел, то получаем ошибку ORA-00904: "tbl_Card"."ContactID": invalid identifier. При этом на сервер отправляется вот такой вот запрос:

SELECT

        "ID",

        "Name",

        "Communication1",

        "AccountName",

        "AccountID",

        "ContactTypeID",

        "ContactTypeName"

FROM (

SELECT 

        "tbl_Contact"."ID" "ID",

        "tbl_Contact"."Name" "Name",

        "tbl_Contact"."Communication1" "Communication1",

        "tbl_Account"."Name" "AccountName",

        "tbl_Contact"."AccountID" "AccountID",

        "tbl_Contact"."ContactTypeID" "ContactTypeID",

        "tbl_ContactType"."Name" "ContactTypeName"

FROM 

        "TS"."vw_Contact" "tbl_Contact"

LEFT OUTER JOIN

        "TS"."vw_Account" "tbl_Account" ON "tbl_Account"."ID" = "tbl_Contact"."AccountID"

LEFT OUTER JOIN

        "TS"."tbl_ContactType" "tbl_ContactType" ON "tbl_ContactType"."ID" = 

"tbl_Contact"."ContactTypeID"

WHERE (("tbl_Contact"."IsNotActive" > :pIsActive) AND

        (EXISTS 

        (SELECT 

                NULL "ID"

        FROM 

                "TS"."tbl_Empty" "tbl_Card"

        WHERE ("tbl_Contact"."ID" = "tbl_Card"."ContactID" AND

                1 = 0 AND

                1 = 0 AND

                1 = 0 AND

                1 = 0))))

ORDER BY

        2 ASC

)

 WHERE ROWNUM = 40

Что я прописал не так для пользовательского фильтра в запросе? Сервис запроса прилагаю.

Нравится

14 комментариев

Sergey Karpenko

27 декабря 2012 10:10

Здравствуйте!

В tbl_Empty нет поля ContactID:

SELECT 
                NULL "ID"
        FROM 
                "TS"."tbl_Empty" "tbl_Card"
        WHERE ("tbl_Contact"."ID" = "tbl_Card"."ContactID"

Ответить

Sergey Karpenko

27 декабря 2012 10:19

Если у пользователя нет прав на таблицу, то при построении запроса она заменяется на tbl_Empty, поэтому возникает такая ошибка.

Из решений вижу отключение фильтра перед открытием датасета, если нет прав на эту таблицу.

Ответить

Ozzy

27 декабря 2012 10:52

Сергей, спасибо за помощь. Действительно, в таблице tbl_Empty нет поля ContactID. Но я эту таблицу не подставлял, соответственно это делает ядро, в том случае, когда у пользователя нет доступа к этой таблице. Поэтому мне кажется, что тут в ядре надо что-то менять. Например, одновременно с подстановкой tbl_Empty все поля таблицы, к которой нет доступа, заменять на поле ID. Ваше предложение об отключении фильтра если нет прав на таблицу идеальное, но опять же, это должно делать ядро.

С моей стороны может быть сделано простое решение: добавить в таблицу tbl_Empty поле ContactID. Но тогда такое поле необходимо добавлять фактически для каждого раздела.

Может кто-то еще сталкивался с подобной ситуацией? Как решали данную проблему?

Ответить

http://www.community.terrasoft.ua/blogs/8267#comment-34549

28 декабря 2012 12:00

Здравствуйте!

В данном случае следует раздать права таким образом:

Дать права на чтение на tbl_Card группе Все пользователи;

Установить для нее признак "Администрируется по записям" и убрать из прав по умолчанию на записи группу Все пользователи.

в случае необхожимости можно отдельно скрывать кнопку раздела в меню в зависимости от прав пользователя.

В Вашем случае есть вариант воспользоваться отдельной функциоей получения результата запроса в CustomSqlColumn:

Ответить

Ozzy

27 декабря 2012 17:11

Анна, спасибо, но как-то неправильно давать права на чтение всем пользователям. Они вообще не должны видеть этот раздел, не говоря о его содержимом. Как Вы говорите можно скрыть раздел в зависимости от прав пользователя? Может все-таки можно в ядре что-то подправить? Ведь попытка обработать такую ситуацию ядром системы есть...

Ответить

27 декабря 2012 18:27

Записей они видеть не будут, только сам раздел.

Для того, чтобы скрыть раздел в меню, нужно в scr_Main в функции InitializeWorkspacesInfo() добавить проверку на вхождение пользователя в определнную группу, например.

amiCard.IsVisible = Value; //результат проверки

Ответить

Ozzy

28 декабря 2012 10:16

Я всё же настаиваю что это ошибка и вопрос необходимо передать разработчикам для исправления. Например сделать как при отображении детали, на которую нет прав доступа на чтение:

SELECT
	"ID",
	"SalesPointID",
	"SalesPointName",
	"PurchaseDate",
	"PurchaseNumber",
	"ContactID",
	"ContactName",
	"CardID",
	"CardNumber",
	"PromoutionCheckID",
	"CheckNumber",
	"DiscountTypeID",
	"DiscountTypeName",
	"BasicAmountPaid",
	"BasicTotalDiscount",
	"BasicTotalBonus",
	"CashierID",
	"CashierName"
FROM (
SELECT 
	NULL "ID",
	NULL "SalesPointID",
	NULL "SalesPointName",
	NULL "PurchaseDate",
	NULL "PurchaseNumber",
	NULL "ContactID",
	NULL "ContactName",
	NULL "CardID",
	NULL "CardNumber",
	NULL "PromoutionCheckID",
	NULL "CheckNumber",
	NULL "DiscountTypeID",
	NULL "DiscountTypeName",
	NULL "BasicAmountPaid",
	NULL "BasicTotalDiscount",
	NULL "BasicTotalBonus",
	NULL "CashierID",
	NULL "CashierName"
FROM 
	"TS"."tbl_Empty" "tbl_PromoutionPurchase"
LEFT OUTER JOIN
	"TS"."tbl_SalesPoint" "tbl_SalesPoint" ON "tbl_SalesPoint"."ID" = NULL
LEFT OUTER JOIN
	"TS"."vw_Contact" "tbl_Contact" ON "tbl_Contact"."ID" = NULL
LEFT OUTER JOIN
	"TS"."tbl_DiscountType" "tbl_DiscountType" ON "tbl_DiscountType"."ID" = NULL
LEFT OUTER JOIN
	"TS"."vw_Contact" "Cashier" ON "Cashier"."ID" = NULL
WHERE (1 = 0)
)
 WHERE ROWNUM <= 40

Ответить

28 декабря 2012 11:58

Я общалась на эту тему с разработчиками, в данном случае поведение системы соответсвует спецификации. За Ваш программный код Вы отвечаете самостоятельно.

В данном случае могу предложить поделиться постановкой задачи, которая Вами решается, чтобы мы могли предложить оптимальный с точки зрения системы способ реализции.

Ответить

Ozzy

28 декабря 2012 14:29

Анна, задача простая: необходимо дать пользователю, у которого есть право на чтение раздела Карты, вывести контакты, у которых есть карта, удовлетворяющая определённым условиям (по номеру, по типу и т.п.). Для этого в сервисе sq_Contacts (прикреплен к первому сообщению) я создал фильтр типа Exist с названием CardsFilter. Пытался сделать его на подобие аналогичных фильтров. Может я что-то перемудрил?

Ответить

Олейник Дмитрий

29 декабря 2012 12:20

Здравствуйте.

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

Поэтому все же оптимальным решением, с точки зрения логики системы, будет решение описанное Анной в сообщении №4.

Ответить

Ozzy

29 декабря 2012 14:21

Дмитрий, для меня так и останется загадкой почему конфигурация может определить что при применении пользовательского фильтра у пользователя нет доступа в другой раздел и подставить вместо tbl_Card tbl_Empty, а вместо tbl_Card.ContactID подставить NULL (как в посте №7) она не может.

Ну что ж, объясню пользователям что это нормальная ошибка: нечего фильтровать по разделам, на которые у них нет доступа.

Ответить

Олейник Дмитрий

29 декабря 2012 14:58

Ozzy, дело в том что эти данные подставляет не конфигурация, а ядро.
А почему Вы не хотите скрыть иконку "Раздела" для тех кому он не должен быть виден, а доступ на чтение на раздел "Карты" выдать?

Ответить

Ozzy

29 декабря 2012 15:58

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

Ответить

Олейник Дмитрий

29 декабря 2012 16:02

Ozzy, я сообщу в департамент разработки о проблеме. По результатам Вам отпишу в этом топике.

Ответить

Показать все комментарии

Вопрос

Установка и Администрирование

Права доступа к пользовательскому полю

22 ноября 2012 14:46

Здравствуйте!

Столкнулась со следующей проблемой:

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

В разделе Права доступа к полям, в контрагентах не отображается пользовательское поле. (скрин)

Почему? Как решить проблему?

Нравится

7 комментариев

Фильковский Павел

23 ноября 2012 10:10

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

Ответить

23 ноября 2012 10:44

Версия 3.3.2.275 без отраслевого решения.
Спасибо, жду.

Ответить

23 ноября 2012 14:36

Добрый день!

Евгения, поле не рассчитывается? Имею ввиду, оно физически данные хранит?

СУБД Firebird? В точку? :smile:

Ответить

23 ноября 2012 15:09

Поле не рассчитывается, данные из БД.
Да, это Firebird.

Помогите, пожалуйста.

Ответить

23 ноября 2012 16:27

Евгения, спасибо, за описание проблемы.
Связался с командой разработки, проблема будет решена в следующем обновлении для 3.3.2. О решении вопроса сообщу дополнительно.

Ответить

6 декабря 2012 16:49

Добрый день!

В принципе, обновление не потребуется.
Ситуация такова, что в Firebird разрешающие права. Т.е. если пользователь находится в группе, у которой есть доступ на все, то и пользователь получит доступ, не смотря на то, что у него лично будет запрет.
Решение такое, что у всех групп по иерархии, в которую входит пользователь должно быть запрещающее право, а потом внутри группы всем пользователям раздать нужные права.

Пример:

/system/files/06-12-2012_16-42-59.jpg

В этом случае у «Пользователь 1» действительно не будет права доступа, но если сделать так:

/system/files/06-12-2012_16-47-34.jpg

то у всех будет полный доступ, так как у группы есть доступ

Ответить

7 декабря 2012 07:13

Игорь, большое спасибо за ответ. Буду пробовать!

Ответить

Показать все комментарии

Вопрос

Технические вопросы

Права доступа к записям на деталях

Вячеслав Тихонов

20 ноября 2012 09:05

Добрый день!
Был создан новый раздел, в этом разделе кроме основной таблицы, еще несколько вспомогательных, которые используются как детали. Изначально поле "Группа таблиц" во вспомогательных таблицах не было установлено.
Сейчас поменялись требования к безопасности и потребовалось, чтобы при удалении прав пользователя на изменение конкретной записи в основной таблице, соответственно изменялись права доступа к записям вспомогательных таблиц, относящимся к этой записи.
Я добавил вспомогательные таблицы в нужную группу таблиц.
Что еще требуется, чтобы права во вспомогательных таблицах на уровне записей автоматически соответствовали правам записи, к которой они относятся?

Нравится

3 комментария

20 ноября 2012 13:04

Добрый день!

Группа таблиц необходима в том случае, если необходимо раздавать права доступа на несколько таблиц (права на чтение/добавление/изменение/удаление). Группа таблиц никоим образом не пересекается с правами на записи (чтение/изменение/удаление/изменение доступа) в таблице.

Автоматически права в основной таблице раздела и таблицах деталей соответствовать не будут. Поэтому такой вариант решения не подойдет.

Ответить

Вячеслав Тихонов

20 ноября 2012 13:41

А как же решить задачу? Только писать обработку для dataset'ов всех вспомогательных таблиц?
Или как-то более удобным способом можно справиться?

Ответить