Workflow specification

Owned by Henryk Rybinski

Last updated: Jan 02, 2024

5 min read

Workflow graph

This submodule defines a graph of process steps with an indication of the supported object class (indirectly, user group) and possible transitions in the graph.

In the example solution used at the Warsaw University of Technology, it was assumed that development takes place in two stages:

project launch
project implementation/completion

while in both stages, the scope of activities and powers of the central unit (COP) are significantly different from what the project manager (departmental level) can do

For this reason, four phases of the study's circulation were distinguished:

Start of project - preparation of project record by COP: COP_01.
1. object class: COP-managed projects.
2. possible transitions:
  - Faculty_01
  - Faculty_02
Project initiation - completion of the project description by the faculty (manager) in the initial phase: Faculty_01.
1. object class: COP-managed projects.
2. possible transitions:
  - COP_01
Project execution/completion - modification of project record by COP: COP_02.
1. object class: COP-managed projects.
2. possible transitions:
  - Faculty_01
  - Faculty_02
Project Execution/Completion - completion of the project description by the faculty (manager) during the project duration/completion phase: Faculty_02.
1. object class: COP-managed projects.
2. possible transitions:
  - COP_02

Authorized users can, in the proper state of description, "forward" the record for development in another phase. resulting from the needs of further supplementation of the data collected in the project description.

The following figures show the most important fields on the workflow record definition form.

The workflow record definition form contains, among other things, the following fields, which are most relevant to defining the process:

System name
Name in Polish
Name in English
Object class
Next stage
E-mail address of incoming mail recipients
E-mail address of incoming mail recipients (EL/script)
Sorting priority (in characters)
Default stage

The address of e-mail recipients can be designated automatically in two ways:

by providing a method for determining the list of addresses
attachment of the developed script

while it is possible to use several methods and a script at the same time.

The rules for using the available methods to determine mail recipients are described in subsection Metody automatycznego ustalania adresów poczty elektronicznej .

The example method was used in the FACULTY_01 phase definition and looks like the following figure

with the content of this definition as follows:

A script that specifies email recipients can include the following content:

This submodule defines a graph of process steps with an indication of the supported object class (indirectly, user group) and possible transitions in the graph.

In the example solution used at the Warsaw University of Technology, it was assumed that development takes place in two stages:

project launch
project implementation/completion

while in both stages, the scope of activities and powers of the central unit (COP) are significantly different from what the project manager (departmental level) can do

For this reason, four phases of the study's circulation were distinguished:

Start of project - preparation of project record by COP: COP_01.
1. object class: COP-managed projects.
2. possible transitions:
  - Faculty_01
  - Faculty_02
Project initiation - completion of the project description by the faculty (manager) in the initial phase: Faculty_01.
1. object class: COP-managed projects.
2. possible transitions:
  - COP_01
Project execution/completion - modification of project record by COP: COP_02.
1. object class: COP-managed projects.
2. possible transitions:
  - Faculty_01
  - Faculty_02
Project Execution/Completion - completion of the project description by the faculty (manager) during the project duration/completion phase: Faculty_02.
1. object class: COP-managed projects.
2. possible transitions:
  - COP_02

Authorized users can, in the proper state of description, "forward" the record for development in another phase. resulting from the needs of further supplementation of the data collected in the project description.

The following figures show the most important fields on the workflow record definition form.

The workflow record definition form contains, among other things, the following fields, which are most relevant to defining the process:

System name
Name in Polish
Name in English
Object class
Next stage
E-mail address of incoming mail recipients
E-mail address of incoming mail recipients (EL/script)
Sorting priority (in characters)
Default stage

The address of e-mail recipients can be designated automatically in two ways:

by providing a method for determining the list of addresses
attachment of the developed script

while it is possible to use several methods and a script at the same time.

The rules for using the available methods to determine mail recipients are described in subsection https://omega-psir.atlassian.net/wiki/spaces/OM/pages/5279580161.

The example method was used in the FACULTY_01 phase definition and looks like the following figure

with the content of this definition as follows:

A script that specifies email recipients can include the following content:

// build email address list of the record owner's unit chief
function chiefEmail(aff, cdaoHelper, iulq) {
var gemail='';
var ca='';
var csep='';
var semail='';
var culq='';
 if (culq =='') {
  var lid = 'cop_HB';
  switch (aff) {
	case 'DPK' : lid = 'cop_BK'; break;
	case 'DFS' : lid = 'cop_MLC'; break;
	case 'DPM' : lid = 'cop_AG'; break;
  }
  culq='login=\''+lid+'\'';
 } else culq = iulq;
 var lu = cdaoHelper.listQ(culq, 'user', "id;ascending");
 if (lu.size() > 0) {
  for (var i1=0; i1<lu.size(); i1++) {
	if (lu[i1].author) {
	 ca=lu[i1].author;
	 if (gemail !='') csep=';';
	 if (ca.email) {semail=ca.email;if (gemail.toLowerCase().indexOf(semail.toLowerCase()) ==-1) gemail=gemail+csep+ca.email;}
	}
  }
 }
 return gemail;
}
var daoHelper = component('daoHelper');
var temail='';
var cemail='';
var csep='';
if (entity) {
 if (entity.owner) {
  var ouq='login=\''+entity.owner+'\' or jcr:contains(@alias,\''+entity.owner+'\')';
  var ou = daoHelper.listQ(ouq, 'user', 'id;ascending');
  if (ou.size() > 0) {
   if (ou[0].author) {
	var oa=ou[0].author;
	if (temail !='') csep=';';
	if (oa.email) temail=temail+oa.email;
	if (oa.affiliation) {
	 var affil = oa.affiliation;
	 if (affil.accronymPL) {
		aff = affil.accronymPL;
		cemail=chiefEmail(aff, daoHelper, '');
		if (cemail !='') {
		 if (temail !='') csep=';';
		 temail=temail+csep+cemail;
		}
	 }
	}
   }
  }
 }
 if (temail =='') {
  if (entity.administratorUnit) {
	if (entity.administratorUnit.accronymPL) {
		aff = entity.administratorUnit.accronymPL;
		cemail=chiefEmail(aff, daoHelper, '');
		if (cemail !='') {
		 if (temail !='') csep=';';
		 temail=temail+csep+cemail;
		}
	}
  }
 }
 if (temail =='') {
	var tulq='login=\'cop_BK\' or login=\'cop_MLC\' or login=\'cop_AG\' or login=\'cop_HB\'';
	cemail=chiefEmail(aff, daoHelper, tulq);
	if (cemail !='') {
	 if (temail !='') csep=';';
	 temail=temail+csep+cemail;
	}
 }
}
temail;