[Tasks] - Make the generic tasks even more generic, allowing the object type string to be custom in case of added plugins
[Tasks] - Make the generic tasks even more generic, allowing the object type string to be custom in case of added plugins
[Tasks] - Make the generic tasks even more generic, allowing the object type string to be custom in case of added plugins
Currently, the creation of subTasks is handled by :
public function createSlaveTasks (array $listOfDN, string $attributeType, array $attrs = NULL): void
example :
// Call the method from parent tasks object (first tab) to create sub-tasks.
$this->parent->getBaseObject()->createSlaveTasks($listOfDN, $attributeType);The variable attributeType was previously set for life cycle and mail tasks. (fdTasksGranularDN, fdTasksGranularMail). To differentiate the usage of DN (CN/UID or MAIL). We can still use that logic that could become beneficial for harder tasks in the future, set in the CORE.
Currently, a new argument should be passed to define fdTasksGranularType.
Modification should occur here :
case 'fdTasksGranularDN' :
$prepData['tasksGranular'] = [
"fdTasksGranularDN" => $dn,
"fdTasksGranularType" => 'Life Cycle',
];
break;
}Life Cycle was hard-coded on purpose but could definitely receive a string variable now. As more plugins will be developed, such as notifications, which also base itself on the concept of "pure" DN such as life cycle.
Added Note LastExec is currently using date format based on time() which is unix UTC format. Somehow using Date changes the local dateTime to local time. We have to have UTC globally. gmDate instead of Date could resolve the issue easily. As generalizeTime in FD use Z which is UTC already.