Skip to content
GitLab
Projects Groups Topics Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • fusiondirectory-orchestrator fusiondirectory-orchestrator
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributor statistics
    • Graph
    • Compare revisions
  • Issues 20
    • Issues 20
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 1
    • Merge requests 1
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • fusiondirectoryfusiondirectory
  • fusiondirectory-orchestratorfusiondirectory-orchestrator
  • Issues
  • #43
Closed
Open
Issue created Apr 02, 2024 by dockx thibault@tdockxMaintainer

[Orchestrator] - Create a possible plugin endpoints, allowing new endpoints developed to be considered as plugin base.

[Orchestrator] - Create a possible plugin endpoints, allowing new endpoints developed to be considered as plugin base.

The concept and design must be discussed deeply, the idea is to have a generic endpoint which would allow calling of specific class being autoloaded.

The idea is to open the API to developers to implement their own plugins if they have a plugin within tasks which would required further processing via Orchestrator.

First Concept

The current version uses a switch case based on the method passed, and the arguments set in tasks.

Line 32
       switch ($method) {
        case "PATCH":
          switch ($object_type) {
            case "mail":
              $result = $this->gateway->processMailTasks($task);

The new concept would not use the gateway->process but the class set in a folder /plugins/tasks/pluginName.inc

Therefore, the switch case would validate the object_type based on the class_availibility.
processMethod would be generic and should be defined an in development documentation.

We could arrange all new tasks, even the official, in that manners.

Edited Apr 02, 2024 by dockx thibault
Assignee
Assign to
Time tracking