Смотрите в сторону объекта Case пакета Case. на событие CaseSaving. Так же есть метод в процессе IsStatusChanged. 

Еще очень поможет методы событийного процесса объекта Case пакета SLM. Событие так же CaseSaving. Метод GetIsNeedToLogLifecycle() и GetLoggingColumns(). В последнем определяется на какие колонки пишется жизненный цикл обработки обращения. По аналогии я сделал свой журнал обработки обращения со своими колонками.

На событие CaseSaving получаете в параметр старое значение поля:

 

AccountOldId = Entity.GetTypedOldColumnValue<Guid>("AccountId");
return true;

На событие CasеSaved уже можно сравнивать полученный параметр с новым значением

 

var NameEntity = new Entity(Entity);
if (NameEntity.FetchFromDB(Entity.PrimaryColumnValue)) {
	Guid accountId = NameEntity.GetTypedColumnValue<Guid>("AccountId");
 
	if ((AccountOldId != accountId)  { 
               ....
    }
 
}
return true;

Владимир Соколов,

 Большое спасибо за Ваш ответ. Буду разбираться.

Алексей Следь,

 Большое спасибо за Ваш ответ. Буду разбираться.

Добрый день!

У нас это реализовано следующим образом:

Забираем у всех права на просмотр лидов. Если необходимо чтобы какая то роль или оргединица имела права на просмотр/редактирование/удаление лидов настраиваем штатно. Создали 2 бизнес-процесса, первый срабатывает при создании лида, второй при смене ответственного в лиде. В этих БП регулируются права на лид.

К тому же, надо помнить, что не только ответственные должны видеть все лиды, но и, например, ещё отдел маркетинга.



В Operation permissions создаём операцию CanReadLead и добавляем в неё роли. Затем в том же БП выдаём этим ролям права на чтение лидов.



И не забываем про права на редактирование.

А почему бы не использовать стандартную функциональность прав по умолчанию? Если для этого объекта в разделе настройки прав в соответствующей детали убрать всё, то на новые записи будет получать права только автор и ответственный, как Вы и хотите. Плюс можно добавить видимость их начальству.

Зверев Александр пишет:

то на новые записи будет получать права только автор и ответственный

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

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

Да. Сам так делаю примерно таким методом в схеме CommunicationPanelEmailSchema, а из БП шлю сообщение соответствующее:

onMyBpFinish: function(scope, message) {
    if (!message || message.Header.Sender !== "UpdateEmailHistory") {
        return;
    }
    var ID = message.Body;
    var collection = this.get("EmailCollection");
    var foundItem = collection.collection.items.find(item => item.id === ID);
    foundItem.set("IsNeedReload", false);
    this.reloadEmailsData([ID]);
    collection.remove(foundItem);
}

Скрипт в конце БП: 

var userConnection = Get<UserConnection>("UserConnection");
var EmailID = Get<string>("EmID");
EmailID.ToString();
Terrasoft.Configuration.MsgChannelUtilities.PostMessage(UserConnection,"UpdateEmailHistory", EmailID);
return true;

Возможно, можно как-то красивее и изящней, но вроде этот метод работает и наша ТП довольна результатом

Доброе утро.

Делала подобное, только детали располагала одна под другой.

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

Владимир, ещё тему двух деталей и нужных связей обсуждали тут.

Идея возможности создавать базовыми средствами мастер-деталь уже зафиксирована.

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

Или, если сохранение происходит до открытия карточки, а логика получения значения более сложная, можно вычислять её на уровне встроенных или отдельных БП.

Был бы мне нужен контрагент текущего пользователя, я бы им и воспользовался.



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

В 7.17.1 должны такое добавить.

Проблема в том что убрать Вам прийдеться не только кнопку круглую, но и из меню, и еще команду в окне поиска как на скрине

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

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

Учтите один нюанс, начиная с версии 7.17.0 если ТЭГ будет не заполнен то процесс в "Библиотеке процессов" виден не будет, и Вы не сможете им управлять - сменить версию можно будет только перейдя в процесс из цепочки и проставить "Сделать актуальной версией", а вот выключить уже не как не выйдет. Потому ТЭГ убирайте только у тех процессов что используете как подпроцессы (так как при его вызове, даже если он отключен он все равно включится), в других случаях можно к примеру в ТЭГ писать имя процесса.

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

Александр Тыра пишет:

Учтите один нюанс, начиная с версии 7.17.0 если ТЭГ будет не заполнен то процесс в "Библиотеке процессов" виден не будет

А почему бы разработчикам не придумать второй тэг "Hidden Business Process"?

Александр Тыра пишет:

Убрать кнопки можно, я уже делал это

 Александр, можете свой вариант скинуть убирания кнопки? Вариант с неотображением процессов не очень нравится заказчику. Кроме того, манипуляции с изменением/удалением тега не убирают из списка процесс, к сожалению.

Создайте модуль без наследников, в нем:

define("KtLeftPanelTopMenuModule", ["LeftPanelTopMenuModule"],

    function() {

        Ext.define("Terrasoft.configuration.KtLeftPanelTopMenuModuleViewModel", {

            alternateClassName: "Terrasoft.KtLeftPanelTopMenuModuleViewModel",

            override: "Terrasoft.LeftPanelTopMenuModuleViewModel",

            getTopMenuConfig: function() {

                var esq = this.callParent(arguments);

                var index = esq.map(function(e) { return e.id; }).indexOf("menu-startprocess-button");

                if (index > -1) {

                    esq.splice(index, 1);

                }

                return esq;

            }

        });

    }

);

Это уберет кнопку круглую. Думаю по аналогии можно убрать и кнопку с надписью "Запустить процесс", а вот как команду выпилить не подскажу, даже не смотрел

При этом необходимо замещать BootstrapModulesV2?

define("BootstrapModulesV2", ["KtLeftPanelTopMenuModule"], function() {

    return {

        methods: {},

        details: /**SCHEMA_DETAILS*/{}/**SCHEMA_DETAILS*/,

        diff: /**SCHEMA_DIFF*/[]/**SCHEMA_DIFF*/

    };

});

Павлов Антон,

 Нет, не надо

Спасибо за ваши ответы

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

Проведите отладку, отрабатывает ли у Вас вообще изменённая логика.

Добрый день! Уточните, в какой культуре работаете с дополнением?

Не совсем понял, что Вы собирались сделать: перенести записи в справочнике или его схему?

Если первое, то нужно, чтобы на базе, куда переностите, уже была такая схема и создавшаяся по ней после публикации таблица в БД. Или же схема создавалась или дополнялась в том же пакете, что и данные в неё. А наполнение справочника затем переносить при помощи привязки данных к пакету.

Если второе, то нужно не создавать объект или замещающий объект вручную, а переносить с сайта-источника готовую схему (или путём выгрузки в md-файл, или через SVN, или пакетами).

Объект Tax — стандартный, у Вас в нём есть какие-то доработки?

Михаил, причины могут быть различными.

Например,  если есть большое количество процессов, которые используют таймер (и, следовательно, планировщик), то может быть, сейчас очередь планировщика перегружена, что и могло вызвать проблемы с зависанием процессов. В таком случае нужно увеличить threadCount во внешнем Web.config с 5, например, до 10. Стандартно там:

<add key="quartz.threadPool.threadCount" value="5" />

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

Михаил, подскажите, пожалуйста, удалось ли решить проблему.

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