Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • fusiondirectory fusiondirectory
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 35
    • Issues 35
    • List
    • Boards
    • Service Desk
    • Milestones
  • Packages and registries
    • Packages and registries
    • Package Registry
    • Container Registry
    • Terraform modules
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • fusiondirectoryfusiondirectory
  • fusiondirectoryfusiondirectory
  • Issues
  • #6321
Closed
Open
Issue created Mar 28, 2024 by dockx thibault@tdockxDeveloper

[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.

Edited Mar 29, 2024 by dockx thibault
Assignee
Assign to
Time tracking