Програмно изменить createdBy

[novic]

Добрый день!
Можно ли записать автора создавшего строку через job

    rhrmStaffListHistory.overwriteSystemfields(true);
    rhrmStaffListHistory.StartDate = startDate;
    rhrmStaffListHistory.StaffListRefRecId = rhrmStafflist.RecId;
    rhrmStaffListHistory.HistoryType = RHRMStaffListHistoryType::Disable;
    rhrmStaffListHistory.(fieldnum(rhrmStaffListHistory, createdBy)) = curuserid();
    rhrmStaffListHistory.doInsert();

так не получается.

[S.Kuskov]

Только посредством прямого SQL

Если вам нужно не изменить уже вставленную запись, а подменить значение уже при вставке записи, то как вариант
можно запустить выполнение кода делающего вставку записи под нужной учёткой при помощи функции runAs.

[Mykola Galak]

Ваш код будет отлично работать если его выполнить на сервере. Джоб который запускается не через менюайтем всегда выполняется на клиенте. Соответственно задача сводится к тому как запустить код из джоба на сервере. Могу предложить два варианта:
1) вынести код из джоба в серверный метод. Вызвать этот серверный метод из джоба
2) создать меню айтем. Выставить ему свойство RunOn = Server. Открыть менюайтем, который в свою очередь запустит джобик на сервере

[novic]

Проделал предложенные варианты: - получаю ошибку -
"Сбой запроса на разрешение типа "OverwriteSystemfieldsPermission"."
DAX2009

[S.Kuskov]

Цитата:

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

Проделал предложенные варианты: - получаю ошибку -
"Сбой запроса на разрешение типа "OverwriteSystemfieldsPermission"."
DAX2009

Вот что находит Google по запросу "OverwriteSystemfieldsPermission" http://blog.equalized.be/tag/overwri...ldspermission/

if(isRunningOnServer() && CurUserId() == "Admin")
{
    new OverwriteSystemfieldsPermission().assert();
 
    salesLine.overwriteSystemfields(true);
    
    salesLine.(fieldnum(SalesTable,CreatedDateTime))    = str2datetime( "2010/04/03 11:00:00" ,321 );
    salesLine.doInsert();
    salesLine.overwriteSystemfields(false);
 
    CodeAccessPermission::revertAssert();
}

[sukhanchik]

Цитата:

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

Проделал предложенные варианты: - получаю ошибку -
"Сбой запроса на разрешение типа "OverwriteSystemfieldsPermission"."
DAX2009

это значит, что что-то было не на сервере.
Нижеприведеннный пример замечательно работает с "клиентским" курсором (т.е. с курсором из формы)

static server void saveRecord(Common _record)
{
    ;
    new OverwriteSystemfieldsPermission().assert();
    _record.overwriteSystemfields(true);
    _record.update();
    _record.overwriteSystemfields(false);
    CodeAccessPermission::revertAssert();
}

[driller]

Цитата:

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

Можно ли записать автора создавшего строку через job

Простите, я может чего-то не понял, или ваш пример сильно утрирован.
В чём проблема то, разве createdBy не будет всегда равен curserid()?
Если же нет, зачем и по какому принципу вы собираетесь присваивать создателя записи,
или же ваш следующий вопрос будет звучать - как после всех темных дел почистить SysDatabaseLog…
Очень уж как то, вся эта затея подозрительно выглядит.

[novic]

дело было в этом -
new OverwriteSystemfieldsPermission().assert();


Спасибо. все получилось.



2 driller:
я хочу знать, кто запустил job создающий строку. job запускается по кнопке на форме.

[S.Kuskov]

Цитата:

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

я хочу знать, кто запустил job создающий строку. job запускается по кнопке не форме.

И всего-то. Тогда всё на мнооого проще. Включите на таблице свойство CreatedBy

[novic]

Эх, Семен Семеныч... Как же я не заметил то, что оно выключено )

[driller]

Цитата:

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

я хочу знать, кто запустил job создающий строку. job запускается по кнопке на форме.

Ещё раз простите, видно уже стареть стал, заговоры везде мерещатся

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

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

Цитата:

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

Эх, Семен Семеныч... Как же я не заметил то, что оно выключено )

Да оно вроде как даже не появляется в таблице без этого свойства.

[gl00mie]

Цитата:

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

А в отношении возможности жонглирования с createdBy, считаю что это дыра в безопасности системы

Отчего же? Если у кода есть возможность создавать записи через AOS и менять системные поля за счет доступности разрешения OverwriteSystemfieldsPermission, то с таким же успехом этот код может получить разрешение SqlStatementExecutePermission и изменить данные прямым SQL-запросом, минуя все аудиторские следы, журналы БД и проч.

Цитата:

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

как можно верить аудиторскому следу, если с этим полем можно играть, как вздумается даже на уровне приложения,
и просто не могу представить

Аудиторский след отражает действия пользователя, а не программного кода, который пользователь выполняет. Для полноты ощущений там еще вроде есть возможность подписывать "следы" с помощью ЭЦП, что в общем случае одной подменой системного поля не обойдешь. А уж что программисты в приложении наворотили, это совсем другое дело. Может, при нажатии на безобидную кнопку где-нить в закрытых периодах проводки меняются или новые создаются в обход всех проверок стандартного приложения... Пользователь может об этом не знать, но это ведь не значит, что он из-за этого не должен фигурировать в авторах создания/изменения записей.

Цитата:

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

для каких благих целей это можно использовать

Пример "подмены" значений системных полей можно найти в логировании входа пользователей в систему: там дата/время создания записей журнала работы пользователей немного корректируется. Аналогично, подмена автора создания записи может использоваться для "логирования" того, что действие произведено "в интересах" того или иного, а не текущего, пользователя, хотя это, конечно, какой-то нереалистичный сценарий. В любом случае, насколько я знаю, ядро не позволяет штатными средствами изменить системные поля с автором/датой/временем создания уже существующих записей - это намного важнее с точки зрения безопасности.
В целом, насколько я могу судить, в той же 4.0/2009 изменения с т.з Trustworthy Computing были продиктованы примерно такими соображениями:

• Dynamics AX все больше становится интегрирована с внешними приложениями, подчас даже написанными сторонними разработчиками, не относящимися напрямую к организации, внедрившей у себя Dynamics AX;
• если взаимодействие ограничивается обменом данными, то тут хватает обычной бизнес-логики для их проверки, и ничего дополнительно делать не нужно;
• если взаимодействие идет, скажем, через Business Connector, то выполняемая бизнес-логика разделяется на две части: та, которая есть в приложении Dynamics AX, и та, которой в этом приложении нет, потому что она "зашита" в программу, дергающую Business Connector, а его можно "науськать" выполнить что угодно, в обход всех существующих в приложении Dynamics AX проверок.
• из предыдущего пункта следует, что в общем случае "доверять" можно лишь коду, выполняемому на сервере, потому что сервер выполняет код приложения Dynamics AX, написанный "в интересах" организации и удовлетворяющий ее требованиям по безопасности и разного рода проверкам и ограничениям; если же на сервере нужно выполнить сторонний код (через COM/DLL/.NET), то на это опять же явно нужно запросить разрешение и в приложении указать, что разработчик отдает себе отчет в том, что он делает.

Именно исходя из таких соображений, по-моему:

• все проверки и запросы разрешений, связанные с Code Access Security, актуальны только для серверного кода;
• часть разрешений в принципе не может быть получена клиентским кодом (OverwriteSystemfieldsPermission, SqlStatementExecutePermission, SkipAOSValidationPermission, Uncheck::TableSecurityPermission и т.д.), и, соотв., определенный функционал не может выполняться на клиенте;
• доступ к ряду таблиц принудительно проверяется на AOS'е с помощью методов aosValidateXX(), в т.ч. доступ на чтение данных.

Т.е. в ядре были реализованы механизмы для принудительного выноса части бизнес-логики на сервер с тем, чтобы эта логика была реализована в приложении Dynamics AX. Никому и в голову не приходило, что может понадобиться защищать систему на базе Dynamics AX от ее же собственного приложения, в котором кто-то что-то может наворотить полухакерскими методами. Для этого предназначен "ручной" контроль (просмотр) модификаций, поднимаемых на рабочее приложение, если эти модификации разработаны сторонними подрядчиками, а также проверка людей при приеме на работу, если модификации разрабатываются штатными сотрудниками.

[Pustik]

Цитата:

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

для каких благих целей это можно использовать,

Вот сегодня тоже была необходимость в такой нужде.У руководства появилось желание видеть дату создания номенклатуры, скажем для своих каких-то внутренних целей. А в справочнике номенклатур это поле установлено не было. Естественно всем очень хотелось видеть и дату создания старых номенклатур. Выручило то, что за номеклатурным справочником велся лог на создание номенклатуры. Чтобы привести все к человеческому виду, решили включить поле createdDateTime в номенклатурный справочник,а для старых номенклатур пробежаться job-ом по справочнику, заглянуть в лог на создание и вручную проставить дату создания из лога.

И вот сегодня натолкнулись на особенность, что системные поля createdBy и createdDateTime упорно не хотят обновляться, в то время как ModifiedBy и ModifiedDateTime успешно изменяются. Используем конструкцию :

static server void saveRecord(Common _record)
{
    ;
    new OverwriteSystemfieldsPermission().assert();
    _record.overwriteSystemfields(true);
    _record.update();
     CodeAccessPermission::revertAssert();
}

Есть подозрения, что в ядре поля типа created... просто исключены из списка обновляемых полей когда происходит update, они присутствуют в списке только при вставке (insert). С одной стороны вроде бы похоже на умную идею намертво закрыть возможность редактирования системных полей created..., c другой нафига оставили overwriteSystemfields с возможностью редактировать поля modified...
AX2009 RU5

[George Nordic]

SQL.

С Уважением,
Георгий

[Pustik]

Цитата:

Сообщение от George Nordic

SQL.

Вы имеете в виду, что причина лежит в SQL?
После запуска Job-a

ttsbegin;
select forupdate Table1;
    Table1.Field1 = 'ggg';
    Table1.(fieldnum(Table1, modifiedBy)) = '11111';
    Table1.(fieldnum(Table1, createdBy)) = '11111';
    Utility_AN::OverwriteSystemfields(Table1);
    ttscommit;

трассировкой на SQL-е мы получили такое
..........UPDATE TABLE1 SET FIELD1=@P1,RECVERSION=@P2,MODIFIEDBY=@P3WHERE (((DATAAREAID=@P4) AND (RECID=@P5)) AND (RECVERSION=@P6))..............

а где CREATEDBY? Сама Аксапта не послала SQL-ю команду обновить CREATEDBY.

PS (метод OverwriteSystemfields один в один как я указал выше)

[ZVV]

Цитата:

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

Вы имеете в виду, что причина лежит в SQL?

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

[Pustik]

Цитата:

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

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

Деваться то конечно не куда больше. Но после кареты в телегу пересаживаться не очень хочется