Product Development

Page tree
Skip to end of metadata
  • Created on 2015-03-03, last edited by Espen Jervidalo on 2015-03-16
Go to start of metadata

Abstract

This concept tackles problems around scheduled publication:

  • The information about scheduled publication is burried deep inside the jBPM engine and using its timer functionality
  • There's no way to take a look at future publications
    • when approving a scheduled publication it is marked as resolved, and stays there, unless it fails during the actual publication
  • No way to cancel future publications

This proposal/concept is about pulling the scheduling of publications out of the jBPM world and move it back into magnolia, by:

  • extending the Tasks core functionality
  • using the Magnolia's own scheduler

Tasks

Pulse refactoring

Abstract

Everything in Pulse is hard coded, starting with the 'Tasks' and 'Messages' tabs down to the column in the list views. Some abstraction work was done when we introduced the tasks in 5.3, but we didn't finish what we started.

PulsePresenter should load the Messages- and Tasks-List views from configuration. Generalize everything at this level. Will need investigation and try and error.

Steps

Try to generalize PulsePresenter.

Add Pulse config to Admincentral module.

Scheduling Tasks

Add new Status to Task-Pojo.

On TaskModule start we should retrieve all 'scheduled' tasks. TaskService should already have this functionality.

For every task we should create a job in the scheduler.

jBPM and Process changes

update to jbpm 6.2, see what breaks

ResolvetaskAction should not 'resolve' the task in case there is a publication date set. add it to the scheduler using same logic as when Task module starts.

What should the scheduler job do? in case of scheduled publication: just resolve the task and let the info.magnolia.module.workflow.jbpm.humantask.ProcessTaskEventHandler#taskResolved and the  jbpm engine take care of the rest (?).

UI

First step would be to have an easy overview of scheduled publications inside the Pulse's task overview.

In the detailed view you should be able to abort a scheduled task (This is crashing with the abort introduced with 5.4, duh).

Further improvements in the Pulse

  • Simplify statuses (to get some space back)
    • All statuses are duplicated in the list view (e.g. 3 x 'New')
  • Wishlist: 
    • make the columns not hardcoded
    • remove task tab if it's not used (configurable), general cleanup
    • make badge actions configurable: keep in mind that the actions are tide to the task type -> what's the lowest common denominator?

Implementation

Tasks and Scheduler

I'm proposing to introduce 'Scheduling of tasks' (read: not only for publication) as a core functionality of Pulse tasks. Currently we have these statuses defined as Enums:

  • Created ('New'), InProgress ('Assigned'), Resolved, Failed, Archived (removed from the view), Removed (not used)
  • introduce: Scheduled

Register a scheduled job using Magnolia Scheduler, which gets all Scheduled tasks which publication date has passed (every 15' ?) and execute them.

Pros

  • we can reuse the tasks persistency, no need to do changes in the Scheduler module, e.g. add persistency.
  • Other tasks can benefit from the future
  • One should be able to query the for pending publications based on the node and workspace. Won't be as cheap as adding a flag to node itself.
  • No additional app or something like that. It fits neatly into our concepts.
  • Easy to implement

Cons

  • The publication will be "delayed" by the execution period of the job. Does it matter?

Workflow

We will have to update the processes. Remove the timer and take care of either 'Resolving' the task, when it gets approved or schedule it, which basically means setting the status.

Here's the current process, which should get simplified:

Pros

  • We move one more critical step out of the jBPM-world.

 

Not related stuff for discussion

Core Module - Component Status in Page Editor

MGNLUI-3250

  • No labels

4 Comments

  1. Jan Haderka

    I don't see the benefit of having one periodic job in Scheduler looping through all scheduled tasks

    • there can be many and you would be looping through them again and again
    • you would need to take care in execution that one failed one doesn't affect others
    • you might possibly fail to finish within your loop period if there are many and publication is slow
    • possible race conditions when aborting task while publishing job is executing

    I would propose to deal with it like we do with any other scheduled tasks

    • on startup of pulse (or workflow?) module you register all scheduled tasks with scheduler as jobs. 
    • You can still locate those jobs and cancel them if you need to abort
    • persistency stays stil w/ pulse
    • concurrency in cancelling while executing is taken care of by scheduler itself
    • jobs can be executed exactly on time
    • multiple long running jobs do not affect each other

    What about other scheduled tasks? If they stay in Magnolia can they still trigger other actions? Long time ago, there was following workflow we had to help client pull together. Would it be possible if we had to pull something like that again:

    • upon request for publication, fork workflow and
      • approval task is assigned to group of publishers
      • start timed task for 7 days to reassign task to super-publisher in case publishers didn't react
      • start timed task for 2 days to send reminder mail to publishers in case they didn't approve yet
    • once approved, if there was future publishing date set, publish content at given future date
    • if super-publisher got assigned task, there was another fork to cancel whole publishing and notify author in case super-publisher didn't approve/reject publishing in 2 days
    • there were few other extras like assigning task to different group of publishers depending on which part of web that was, but that is mostly irrelevant here.

  2. Espen Jervidalo

    I agree to your concerns and proposed solution. The use case you outline can probably be solved in different ways. Here's one not involving changes in workflow:

    I think that would be possible much in the same way the scheduling would work? register a job to the scheduler for all 'New', which would notify. Register a TaskEventHandler to cancel the jobs, when status changes.

    Thanks!

  3. Andreas Weder

    I've had a look at your UI proposals and have, one two suggestions. I didn't review the entire flow, though, but I certainly welcome that you'd like to introduce more flexibility in how Pulse's view are configured (tabs as well as columns). Pulse is still way below it's potential, but we're improving with changes like that.

    My suggestions:

    • We introduce a "scheduled" filter tab, as you're showing, but please not at the cost of the "all" tab.
      We need that to have a non-filtered view. We could discuss removing the "assigned" filter, if that does help, but we could be just fine if we add an additional column and maybe reduce the width of the tabs a bit.
    • We can narrow the "new" column, if we replace the "tick" icon with a "unread" icon (we don't have that yet) and remove the column title.
      The resulting appearance would be similar to what we have in our mail apps.
    • Instead of introducing a "scheduled for" column that shows the scheduling date, we could add scheduling info to the status column and make it wider (e.g. "Scheduled for" \r "March 12, 2015 14:40"). That works if sorting that column would first sort by status type, then a configurable second criterion (in this case: the schedule date).
      This also helps to not have columns specific to a particular status, but irrelevant to all others.
    • On the "abort" action: I'd go for a specific "Abort publication" here and make sure it's only available to scheduled tasks (-> action availability). Thus, the action name should be configurable according to the type of the task.
    • But we have to resort and rename those task actions anyway, e.g. "reject" could be "reject publication" and have a different icon. I'd like to discuss this in time, once that comes up.

    If you'd like to me supply more detailed mockups or sketches, please let me know.

    1. Andreas Weder

      Finally, I'm including a visual design here that shows how we plan to rework Pulse to make it quicker to use and more like an interactive notification stream. I'm not doing this because I think we should do that now, but because it might influence a decision you take in favor of or to facilitate moving to such a solution.

      What we're mainly looking for is having inline detail views to quickly react on a task or message. Such detail views only show the main actions available. Additional actions only show up in a separate app (or, possibly, an overlay).

      The entire UI design can be found here: Managing my work with Pulse

      Implementation-wise, such a thing would probably be easiest to do if we switch to Vaadin's new Grid component, introduced with 7.4, once it got extended with "row details" in the next version 7.5.