Copy & paste from review discussion to help people understand the problem:

===========================================================

Hi Edwin,

The reason behind removing these actions is because an action plan is atomic.
The only way for us to be able to delete actions should be when we delete the
action plan these actions relate to.

Actions are chained one to another by the planner so we know the order of
execution. The action plan only references the first action UUID it has to
execute and the latter knows about the next one and so on and so forth.
Therefore, if an administrator is given the ability to delete one of them,
this may probably invalidate the whole action plan because it would break the
chaining that had been made by the planner.

IMHO, removing these verbs is the simplest way for us to ensure the integrity
of our action prior to execution. Another approach would be to actually enforce
the the re-chaining of the other related actions whenever we delete one (e.g.
we have 1->2->3->4 and we delete '3' so we re-chain it as 1->2->4). But the
problem with that second option is that whenever we will move on to use a graph
representation instead of a simple list (blueprint action-plan-flow-storage),
the question will get much more complex and that would definitely require a BP
of its own.

So we have these 2 options (you may have some other?), I think that it makes
more sense to first secure the integrity of the action plan using the 1st
option and then propose a blueprint that would follow the introduction of a
graph-shaped action plan that would tackle the following questions:

- In what way should we be able to alter an action plan after it has been
  issued?
- What are the mechanisms we would have put in place to rebuild the flow of
  actions after it got updated?

  * What rules are we setting to apply to re-map an action that does not have
    a parent anymore but still has some children actions attached to it?
  * Should we then submit the new version of the action flow to the planner?

That being said, you may have some use cases that require the alteration of an
action plan which would then justify going another direction. If so, I would be
happy to hear about it.

So thanks for your comment! It makes a lot of sense and actually gives an
opportunity to lay down the problem.
All this being said, what are your thoughts? Do you think we still need to lay
things down into a BP? And if so, do you think we need a spec for it?
Edwin Zhai
Feb 22 3:19 PM

Patch Set 1:

    Hi Edwin,That being said, you may have some use cases that require the
    alteration of an
    action plan which would then justify going another direction. If
    so, I would be
    happy to hear about it.

One possible user case in my head is that expert user could change suggested action flow by add/remove/modify single action.


    So thanks for your comment! It makes a lot of sense and actually
    gives an
    opportunity to lay down the problem.
    All this being said, what are your thoughts? Do you think we still
    need to lay
    things down into a BP? And if so, do you think we need a spec for
    it?

Need a BP if we decide to remove these actions API completely. But from your reply, it is for now to avoid user wrong operations before long term solution. I think it should be ok.

One suggestion: To avoid confusion, Could you pls. add one simple error/warning mesg returned to user, like "Do not delete one action directly." What do you think?