Abstract

This concept belongs to the BL-127 "As a user I can activate content so that it gets published" story. The goal is to allow users to activate/deactivate the content. ATM, the legacy commands from the Admin Interface legacy module will be used.

Goal

The goal is to allow users to activate/deactivate the basic content (pages, assets, contacts(question)) from author to public instance(s), and to show developers the way to provide this functionality for their own content types.

The solution must be flexible and allow dynamic replacing of the behavior, e.g. by the workflow modules.

Proposal

A fundamental premise here is that in M5 workflow will be an EE feature only. In CE only direct activation/deactivation will be available (no workflow engine involved).

The Activation / Deactivation actions will be created and linked to proper buttons in the action bar of required apps. Actions will execute 'activate' and 'deactivate' commands defined in appropriate catalogs (or the default ones) by calling CommandsManager.executeCommand(String catalog, String command, Map<String,Object> parameters) method.

The activation module will implement the basic CE de/activation operations by means of commands.

The workflow module will implement those commands using a workflow engine.

 

  • No labels

3 Comments

  1. Jan Haderka

    Why not to move those commands directly to activation module where they should have been from the start? Well RepoBasedCommand should be maybe directly in core. Also if we plan using them long term (and that is what will happen if we start using them now), we should deprecate command w/ the old package name and find more suitable package for it.

    Also, It might be time to slash the pooling feature from commands. It was always more of a pain then a benefit (imho).

    1. Jozef Chocholacek

      Speaking of it, I'd distinguish two things:

      Where the commands are defined:

      ATM, the activation / deactivation commands (plus delete and sendMail commands) are defined in the old admin interface module (/modules/adminInterface/commands). We want to get rid of that module, so I agree we should move the definitions of activate/deactivate commands to activation module, and the delete command to some UI module (Pages App?).

      Btw. a list of out-of-the-box commands with description and the config path would be IMHO useful - especially for third-party developers.

      Where the commands are implemented:

      Let's keep the old command classes in the AI Legacy module (marking them deprecated), and implement new ones in the Activation module later.

  2. Jozef Chocholacek

    Concept page for Commands created: Concept - Commands