[DISCUSS] Job Code entry feature for graph changes

[DAVID SMITH <da...@btinternet.com>]

Hi 
I was doing a demonstration of NiFi to a new audience at work yesterday, the audience were most impressed and could see many uses, however two major questions arose. Audit and Accounting is a major thing where I work, and we would like to track who made changes and why.  
I think I have seen one of these questions as a discussion item on the forum but I can't remember the outcome.
The questions are:
1)     Is there going to be an undo feature in future releases?
2)     When a graph is made operational and a change needs to be made we would it be possible to have some sort of system that requires a work code or reason phrase to be entered before the updated graph is saved. Would this be feasible and could a reporting task be created to publish the change information (if any ) perhaps on a monthly basis?

Dave 

Re: [DISCUSS] Job Code entry feature for graph changes

[Joe Witt <jo...@gmail.com>]

Dave,

Undo is on the list to be supported and you can read more about the
thought process here [1].

Regarding the work code concept as described I think that
significantly alters the user experience of NiFi in a way that would
support a fairly narrow user base at the expense of the broader group.
That said I can see how it would be valuable to have flow change
information available as an audit-stream if you will.  We do record
who/what changes occur in the flow in the case of a secure
configuration.  That information could be pushed via a reporting task
most likely or could definitely be pulled via the REST api.  How I
could see that working is that we always report the process group
being affected by the change and that you use a naming convention for
those process groups which would be 'hooked' by the external process.
This is similar to 'hooks' in say commit messages that help link those
commits to specific JIRAs.  This way the user experience is preserved
but the external system can associate a user change to some work
database.  What my proposal would not support though would be the
ability to block a user in the event that their change was on some
unknown work.  We can approach that too perhaps as we tackle
multi-tenant authorization because at that point we need to expose
more details of what is happening for the authorization decision to be
made.

[1] https://cwiki.apache.org/confluence/display/NIFI/Configuration+Management+of+Flows

Thanks
Joe

On Thu, Sep 17, 2015 at 12:42 PM, DAVID SMITH
<da...@btinternet.com> wrote:
> Hi
> I was doing a demonstration of NiFi to a new audience at work yesterday, the audience were most impressed and could see many uses, however two major questions arose. Audit and Accounting is a major thing where I work, and we would like to track who made changes and why.
> I think I have seen one of these questions as a discussion item on the forum but I can't remember the outcome.
> The questions are:
> 1)     Is there going to be an undo feature in future releases?
> 2)     When a graph is made operational and a change needs to be made we would it be possible to have some sort of system that requires a work code or reason phrase to be entered before the updated graph is saved. Would this be feasible and could a reporting task be created to publish the change information (if any ) perhaps on a monthly basis?
>
> Dave