BatchLabs: App splited in features that are can be enabled and disabled

[timotheeguerin]

Make the app support features that can be enabled and disabled which will not show disabled features.

Examples Features

• pool
  • pool.create
  • pool.patch
• certificate
• gallery

Configuration file

{
    "certificate": true,
    "pool": {
        "add": true
    },
    "job": {
        "add": true,
        "view": true
    }
}

Service

class WorkspaceService { 
    public currentWorkspace: Observable<Workspace>
    selectWorkspace(workspaceId: string);

    public isFeatureEnabled(feature: string): boolean;
    public isFeatureDisabled(feature: string): boolean;
}

Model

class Workspace {
// Takes the inputs from a file an process

    public isFeatureEnabled(feature: string): boolean;
    public isFeatureDisabled(feature: string): boolean;
}

Directive

Have a directive to use in the templates to make it easier to enable a feature

Name feature, featureEnabled, featureOn?

<div *featureOn="job.view">

</div>


<div *featureOff="job.add">

</div>

[ascobie]

How about something like this as a first go? completely unsure, but need a way to hide top level navigation as well. I like the separation between viewing and modifying. Though as the first cut, maybe we wont worry about the modification bits at all as these are more permissions based, and expand it into more feature areas.

Configuration file

{
    "job": {
        "navigate": true,
        "view": {
            "graphs": true,
            "statistics": true,
            "tags": true,
            "asJson": false
        },
        "maintain": {
            "add": true,
            "delete": true,
            "edit": true,
            "addTask": true,
            "terminate": true,
            "clone": true,
            "schedule": true,
            "export": true,
            "pin": true,
        }
    },
    "schedule": {
        "navigate": false,
        "view": {
        },
        "maintain": {
        }
    }
    "pool": {
        "navigate": true,
        "view": {
            "cost": true,
            "tags": true,
            "asJson": true,
            "availableNodes": false,
            "runningTasks": true,
            "appInsights": false,
            "nodes": true,
        },
        "maintain": {
            "add": true,
            "delete": true,
            "addJob": true,
            "resize": true,
            "clone": true,
            "export": true,
            "pin": true,
        }
    },
    "package": {
        "navigate": false,
        "view": {
        },
        "maintain": {
            "add": true,
            "delete": true,
            "addVersion": true,
            "edit": true,
            "pin": true,
        }
    },
    "certificate": {
        "navigate": false,
        "view": {
        },
        "maintain": {
            "add": true,
            "delete": true,
            "reactivate": true,
            "export": false,
            "pin": true,
        }
    },
    "data": {
        "navigate": true,
        "view": {
            "fileGroups": true,
            "containers": true,
            "accounts": false,
        },
        "maintain": {
            "addContainer": true,
            "deleteContainer": true,
            "addFileGroup": true,
            "deleteFileGroup": true,
            "modify": true,
            "download": true,
            "pin": true,
        }
    }
}

So based on the above, the user would only see the navigation options for: Jobs, Pools, Data, Gallery. Schedules, Packages, Certificates would be hidden from view. Oh, and I forgot all about the Dashboard.

And to take it even further, we could add more levels of customization:

{
    "job": {
        "navigate": true,
        "view": {
            "graphs": true,
            "statistics": true,
            "tags": true,
            "asJson": false,
            "configuration": {
                "general": true,
                "constraints": true,
                "envSettings": true,
                "executionInfo": true,
                "jobPrep": true,
                "jobRelease": true,
                "metadata": true
            }
        }
    },
}

[timotheeguerin]

Yeah not sure about this exact structure. Feel like maybe navigable shoud be inferred from the fact you want enable the entity. Also for every nested entities you could set to false to say everything is disabled or to true for everything is enabled

{
  "jobSchedule": false,
  "pool": {
      "view": {
        "cost": true,
        "tags": true,
        "availableNodes": false,
        "runningTasks": true,
        "appInsights": false,
        "nodes": true,
      },
      "action": false, 
  },
  "job": true,
}

[ascobie]

yeah cool, i was thinking that even though packages was disabled, there may be a case where we wanted to show something from packages in another view, but i guess that shouldn't be an issue.

so to start, do we need a master template config that contains the entire structure and lists everything that can be disabled/enabled. then a base admin/developer template and a base end-user template that holds the default state of these 2 workspaces.

the master developer template would be a copy of the master template with no changes, end-user template would have the features turned off that we decide.

our "edit workspace" UI would be driven from a combination of the master template and the workspace template that was currently selected as well as any user overrides.

we can probably just have a singe user-overrides-template that contained any edits to the selected workspace with the ability to reset it back to "standard".

one more thing, should we add a title and description in the workspace templates? then we can just load the templates and drive the workspace selector DDL from whatever templates we load:

{
  "workspace": {
    "title": "Developer mode",
    "description": "Shows everything ..... "
  },
  "jobSchedule": false,
  "pool": {
      "view": {
        "cost": true,
        "tags": true,
        "availableNodes": false,
        "runningTasks": true,
        "appInsights": false,
        "nodes": true,
      },
      "action": false, 
  },
  "job": true,
}

Edit: unless the developer/admin template was the master template. as the templates themselves don't get edited, only user settings that override the base template