Как правильно создавать новые и использовать существующие SecurityKey

[Ivanhoe]

Цитата:

Сообщение от someOne

В этом случае как раз права на таблицу xRefTableRelation ничего не дадут.
Даже если вы откроете права на эту таблицу то при попытке пользователем открыть диалог добавления таблицы в источник данных получите сообщение как показано ниже. Поэтому решить проблему может лишь открытие права целиком на ключ SysDevelopmentTables, либо отключение свойства AOSAuthorization таблицы xRefTableRelation с CreateReadUpdateDelete на None. Это сделано. И этого не достаточно.

Проверил еще раз на НЕ модифицированном приложении ax2009 ru6

Не понял =). Если прав на таблицу xRefTableRelation нету - то все ок, а если есть - то выдается ошибка??

И по логике, и по факту на моей модифицированной, но не в части прав AX, всё наоборот - если прав на эту таблицу нет (не на ключ, а на таблицу), то ошибка выдается. Если права дать - то всё работает.

Как-то уж очень по-разному ведет себя аксапта в наших инсталляциях. Надо проверить у кого-то еще!

[someOne]

Цитата:

Сообщение от Ivanhoe

Не понял =). Если прав на таблицу xRefTableRelation нету - то все ок, а если есть - то выдается ошибка??

И по логике, и по факту на моей модифицированной, но не в части прав AX, всё наоборот - если прав на эту таблицу нет (не на ключ, а на таблицу), то ошибка выдается. Если права дать - то всё работает.

Как-то уж очень по-разному ведет себя аксапта в наших инсталляциях. Надо проверить у кого-то еще!

Видимо я выразился не слишком ясно.

Суть того, что я хотел сообщить, в следующем:
1. Права на таблицу xRefTableRelation, конечно же есть. Если бы их не было - то выдавалась бы ошибка о том что нет доступа (которую я привел), а не выдавался бы список "пусто" на сером фоне.

2. Этих прав (на таблицу xRefTableRelation) не достаточно. Для того чтобы в списке появились необходимые таблицы - приходится открывать пользователю права на ключи таблиц. Если этого не делать - в списке отображаются только таблицы БЕЗ ключей


Не поленился разобраться, в чем же "засада".

Все дело в методе класса
\Classes\SysQueryBuilder\buildRelations
Там есть такой метод, который определяет "доступна" ли таблица данному пользователю

Если на таблице есть какой нибудь ключ безопасности, и у пользователя нет прав на этот ключ, (хотя и есть право на объект (таблицу)) то при запуске проверка возвращает "false", поэтому таблицы и не отражаются пользователю.

private static client server Map buildRelations(Map _map, SysDictTable _orgDictTable, TableName _tableName, RelationName _relationName)
.....
    if (dictTable &&
        dictTable.rights() > AccessType::NoAccess &&
        !dictTable.isTmp())
    {

Особенность в том что в случае запуска на стороне сервера и на стороне клиента (у меня по крайней мере) он возвращает разные значения!!!

Вот пример. Проверьте у себя разве он у вас работает не так ?

static void test(Args _args)
{
    SysDictTable    DictTable;
    ;
  
    dictTable   = new SysDictTable(tablename2id("SalesLine"));

    if (dictTable.rights() > AccessType::NoAccess)
    {
        info("true");
    }
    else
    {
        info("fasle");
    }
}

Если на таблице есть какой нибудь ключ безопасности, и у пользователя нет прав на этот ключ, но есть право на объект (таблицу), то при запуске на стороне сервера пример вернет "false", а при запуске на клиенте - "true"

В этом кажется, и есть проблема.

Интересно, каким образом в вашем случае пользователю отображены табличные связи ? Неужели в вашем случае этот метод работает иначе ???

Кстати проблема решается если в классе SysQueryBuilder вместо
private static server container findRelations(tableId _tableId)
написать
private static client container findRelations(tableId _tableId)

[Ivanhoe]

Цитата:

Сообщение от someOne

Если на таблице есть какой нибудь ключ безопасности, и у пользователя нет прав на этот ключ, (хотя и есть право на объект (таблицу)) то при запуске проверка возвращает "false"

Почему сделан такой вывод? =) Так должно быть согласно документации? По мне (я не программист, могу и заблуждаться), dictTable.rights() должен возвращать доступ к объекту, а не его ключу. Ведь проверка на доступ к ключу обычно делается по-другому.

Цитата:

Сообщение от someOne

Особенность в том что в случае запуска на стороне сервера и на стороне клиента (у меня по крайней мере) он возвращает разные значения!!!

Вот пример. Проверьте у себя разве он у вас работает не так ?

Если на таблице есть какой нибудь ключ безопасности, и у пользователя нет прав на этот ключ, но есть право на объект (таблицу), то при запуске на стороне сервера пример вернет "false", а при запуске на клиенте - "true"

Интересно, каким образом в вашем случае пользователю отображены табличные связи ? Неужели в вашем случае этот метод работает иначе ???

У меня в дебагере стоит значек "сервера" напротив метода \Classes\SysQueryBuilder\buildRelations - значит выполняется на сервере? Джоб запускал и напрямую, и через меню айтем с запуском на сервере - в обоих случаях возвращает true.

Явно же барабашки нет? ) Не знаю, важно это или нет, но клиент стоит на самом сервере АОС.