Утверждение приказов по персоналу: проверка доп. условий

[Irina_]

Здравствуйте.
Надеюсь на Вашу консультацию.
Поставлена задача. Сформирован список должностей, имеющих определенный признак (внешний атрибут), сделана привязка внешнего атрибута в справочнике должностей. Кадровики сейчас сами утверждают все приказы по персоналу по всем РПД.
Надо:
Если в приказе есть ходя бы одна запись по сотруднику с должностью, к которой привязан заданный ВА, и приказ по заданному перечню РПД (например в перечень не включаются приказы на отпуск и некоторые другие), то не давать кадровикам утвердить такой приказ самостоятельно. Должно быть согласование, и только определенный пользователь после согласования может утвердить такой приказ. Другие приказы кадровики должны утверждать сами.
Иными словами, приказ может быть утвержден только при выполнении некоторых дополнительных условий к стандартным условиям по проверке приказа на корректность.
Каким образом это сделать?

[RAJAH]

Вижу 2 основных варианта:
1) перекрыть событие утверждения приказа своим кодом, который будет проверять дополнительные условия, и в зависимости от их выполнения делать inherited или не делать;
2) повесить на приказы триггер before update, где, например, запустить отмену утверждения в случае несоответствия дополнительным условиям.

[m0p3e]

Я тоже вижу два варианта.
1. Докомпилировать интерфейс OrdersList. В этом случае код будет работать для всех РПД, но структура самого интерфейса не очень удобна для работы.
2. Я бы пошел по другому варианту. Докомпилировать каждый РПД, для которого должно работать ограничение, отдельно. Добавляемый код будет шаблонным. Вызывать будем через стандартную паблик-функцию CheckOrder.
Первым делом выносим саму проверку в отдельный объект.

Код: Выделить всё

#component "Z_Staff" //для 8.1 или "Z_StaffOrders" для 9.1
interface MyStaffOrderAccess;
Create View
var cPart : comp;
as select 
from PartDoc
       ,ContDoc
Where ((cPart == PartDoc.nrec
       and PartDoc.nrec == ContDoc.cPart
       ...........
          ));
Public Function CheckAccess(c : comp) : boolean;
{
 Result := true;
 cPart := c;
 If GetFirst PartDoc = tsOk
   _loop ContDoc
     {
      If //Проверяем наши условия и 
        Result := false
     };
};
end.

В каждое RPD добавляем вызов нашей проверки.
На примере приема RPD_1

Код: Выделить всё

alter interface RPD_1;
overload
 function IRPD.CheckOrder : boolean;
end;
var iMyAccess : MyStaffOrderAccess;
Function CheckOrder : boolean;
{
 Result := inherited::CheckOrder;
 If Result and //Проверяем, что пользователь не имеет права утверждать приказ (я бы добавил настройку)
  {
   If not iMyAccess.CheckAccess(PartDoc.nrec)
     {
      Message('Вам запрещено утверждать данный приказ!', Information);
      Result := false; 
     };
  };
};

Встраиваем код во все нужные RPD. Можно для красоты через #declare.

[Irina_]

Здравствуйте.
Большое спасибо откликнувшимся, особенно Сергею. Суть в общих чертах понятна благодаря коду.
Ранее никогда не приходилось иметь дело с докомпиляцией стандартных интерфейсов. Поэтому буду пробовать.

[edward_K]

Там вроде есть точки расширения и до и после, проще их использовать

[m0p3e]

Там вроде есть точки расширения и до и после, проще их использовать

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

Код: Выделить всё

#doc
Утверждение приказа по персоналу
#end
ExtensionPoint epConfirmOrder (NrecTitleDoc : comp);

#doc
Удаление приказа по персоналу
#end
ExtensionPoint epDeleteOrder (NrecTitleDoc : comp);

До точки нет.

[Irina_]

Здравствуйте.
Наконец приступила к разработке по теме. Начала с приема на работу. Столкнулась со следующим:
1. В инерфейсе докомпиляции приказа по РПД=1 в начале тоже поставила #component "Z_StaffOrders". Без него
при компиляции получала ошибку: «В ресурсе нет интерфейса Vip_Pers::RPD_1 …». Так и должно быть?
2. Подключила свой res. Ввела приказ на прием с должностью, у которой заполнен ВА и в исходнике указала, что мне запрещено утверждать приказ с наличием по должности заданного ВА. При утверждении приказа получила ошибку «Загружаемый интерфейс «MyStaffOrderAccess» был выпущен 22.11.2019, т. е. после окончания Вашего абонентского обслуживания!...». Правильно ли я понимаю, что при необходимости каких-то доработок своего интерфейса по докомпиляции мне всегда надо проверять дату окончания абонентского обслуживания? Я писала уже много своих интерфейсов и никогда не ориентировалась на указанную дату. Новые лицензии получаем обычно перед установкой очередных патчей, которые ставятся не часто. А необходимость компиляции своих отчетов может возникнуть в любой момент (попросили в имеющийся отчет что-то добавить/ подправить, в проект добавила новый отчет, и т. д.). Т.е. при докомпиляции стандартных интерфейсов всегда надо учитывать дату абонентского обслуживания?
3. После предыдущего сообщения об ошибке получила следующее сообщение об ошибке: «Возникло необработанное исключение ExObjifcNoInit (ExRef) Ссылка не была инициализирована. Да-продолжить, Нет-отлаживать в окне отладчика, Отмена-не выдавать больше это сообщение». Нажала Да, получила свое сообщение о запрете на утверждение приказа. Но радость была преждевременной. Попробовала в приказе указать должность, для которой не задан ВА. При утверждении приказа опять получила ошибку о выпуске интерфейса после окончания абонентского обслуживания, далее ошибку о необработанном исключении, а потом опять свое сообщение о запрете на утверждение приказа. Но в приказе должность, при наличии которой приказ должен был утвердиться. Правильно ли я понимаю, что в данном случае проблема с утверждением приказа связана с ранее полученными ошибками об окончании абонентского обслуживания и о наличии необработанного исключения?

[m0p3e]

Здравствуйте.
Наконец приступила к разработке по теме. Начала с приема на работу. Столкнулась со следующим:
1. В инерфейсе докомпиляции приказа по РПД=1 в начале тоже поставила #component "Z_StaffOrders". Без него
при компиляции получала ошибку: «В ресурсе нет интерфейса Vip_Pers::RPD_1 …». Так и должно быть?
2. Подключила свой res. Ввела приказ на прием с должностью, у которой заполнен ВА и в исходнике указала, что мне запрещено утверждать приказ с наличием по должности заданного ВА. При утверждении приказа получила ошибку «Загружаемый интерфейс «MyStaffOrderAccess» был выпущен 22.11.2019, т. е. после окончания Вашего абонентского обслуживания!...». Правильно ли я понимаю, что при необходимости каких-то доработок своего интерфейса по докомпиляции мне всегда надо проверять дату окончания абонентского обслуживания? Я писала уже много своих интерфейсов и никогда не ориентировалась на указанную дату. Новые лицензии получаем обычно перед установкой очередных патчей, которые ставятся не часто. А необходимость компиляции своих отчетов может возникнуть в любой момент (попросили в имеющийся отчет что-то добавить/ подправить, в проект добавила новый отчет, и т. д.). Т.е. при докомпиляции стандартных интерфейсов всегда надо учитывать дату абонентского обслуживания?

1. Все верно. Для 9.1 компонента "Z_StaffOrders".
2. Собирать лучше с отключением проверки даты лицензии. Создаем пустой файл autoexec.vpp в папке проекта. Запускаем сборку с параметром %GAL910VIP%\vip.exe /c:vip.cfg staff.prj /linc=autoexec.vpp
3. Скорее всего последствия пункта 2.

[Irina_]

Сергей. Я работаю c Viper. Вы же показали компиляцию vip-ом. Куда ввести параметр для компиляции в данном случае?

[RAJAH]

«Возникло необработанное исключение ExObjifcNoInit (ExRef) Ссылка не была инициализирована. Да-продолжить, Нет-отлаживать в окне отладчика, Отмена-не выдавать больше это сообщение»

Обычно такая ошибка возникает при отсутствии #define ComponentVersion.

[Irina_]

В prj в начале стоят:
#define ComponentVersion
#define Gal9_1

[m0p3e]

Сергей. Я работаю c Viper. Вы же показали компиляцию vip-ом. Куда ввести параметр для компиляции в данном случае?

по Viper-у не подскажу, но Михаил писал на это:

Код: Выделить всё

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

Любой экзотический параметр экзотического языка VIP вы может описать в PRJ-проекте чрез директиву #param

Таких параметров огромная куча. Мы не все выводили в окно Viper.

viewtopic.php?f=2&t=12514&p=64506&hilit=linc#p64506

[Irina_]

Сергей, то, что Вы рекомендовали, помогло решить проблему с проверкой даты лицензирования. Сейчас возникла новая проблема. Я ввела ВА с типом «признак». В ExtAttr.vih не вижу метода получения значения атрибута этого типа. Есть только строка, вещественное, дата, время, мемо, ссылка. Есть ли возможность получения значения ВА типа «признак»? Ранее не сталкивалась с ВА этого типа.

[m0p3e]

Есть ли возможность получения значения ВА типа «признак»?

Работа с boolean:

Код: Выделить всё

  function bGetAttr    (_wTable : word; _cRec : comp; _Name : string) : boolean;
  function bGetAttrID  (_wTable : word; _cRec : comp; _cAttrNam : comp) : boolean;
  function bSetAttr    (_wTable : word; _cRec : comp; _Name : string;   _Val : boolean) : boolean;
  function bSetAttrEx  (_wTable : word; _cRec : comp; _Name : string;   _Val : boolean; bRealTbl : boolean = true) : boolean;
  function bSetAttrID  (_wTable : word; _cRec : comp; _cAttrNam : comp; _Val : boolean) : boolean;
  function bSetAttrIDEx(_wTable : word; _cRec : comp; _cAttrNam : comp; _Val : boolean; bRealTbl : boolean = true) : boolean;

[Irina_]

Здравствуйте. Большое спасибо за помощь, особенно Сергею! Все получилось. Сначала я думала, что будет много РПД для докомпиляции интерфейсов, но оказалось только 4. Возникли затруднения с РПД=5 «Перемещение», т. к. надо было анализировать должности в назначении ДО и ПОСЛЕ перемещения. В результате после анализа журнала пришла к выводу, что в отличии от приказов на прием, увольнение, заключение/ продление контракта, в приказах по РПД=5, 3, 4 в ContDoc формируется не одна, а 2 записи. Это фактически учитывается в образце исходника, предоставленного Сергеем. И по его же совету написала интерфейс добавление своей настройки в реестр, чтобы потом анализировать ее на право утверждения приказов по нужным мне РПД, если в назначении у должности задан нужный внешний атрибут.