Paul, Please create Jira tickets with your feature requests. I have not previously encountered users making this request, so I want to ensure we capture all of your desires for a successful implementation of this feature in order to accurately estimate the resources necessary for it and prioritize it accordingly.
Please consider how you would like NiFi to indicate the current mode, whether this “operational” mode would allow any changes to processor properties and addition of new processors or simply fixes the location of canvas elements, the mechanism to switch between modes conveniently, if this would affect the UI only or the REST API as well, etc. To the best of my knowledge, we have not had any requests for a feature like this, nor do many/most of our users envision the environment in this split mode mentality. Users who should not be able to modify the flow usually are assigned the ROLE_MONITOR role, and those who need to manipulate the flow itself have not mentioned the issues you brought up. Andy LoPresto [email protected] PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > On Mar 23, 2016, at 4:28 AM, Paul Nahay <[email protected]> wrote: > > Thanks. I wouldn't be able to send you any screen shots, as the system with > NiFi is not the same as this which I can send email on. > > Yes, I'm asking about a feature whereby a single user can switch back and > forth between these two modes. When I first encountered NiFi, THIS was the > most glaring omission, in my view. The use case occurs every day by many > people: we inadvertently move something, and since you have no "undo" (the > 2nd most glaring omission), the canvas is screwed up. THIS HAPPENS ALL THE > TIME. It seems an obviously need thing to me. Basically one is interacting > with the canvas in one of two situations: "operationally", in which case one > DOES NOT WANT ANYTHING TO MOVE, not matter how one clicks around the canvas, > and "editing-ally", in which we DO want to move things around. > > Computers routinely are programmed to help us, including help us NOT do > things we do NOT want done, including inadvertent things. Why can't NiFi help > us with this? Why can't we say "hey, NiFi, I'm going to use you > operationally, I'm not modifying anything", and have NiFi NOT allow things to > be moved around? > > I know your answer: "So don't move things around". But given that I have to > use the mouse when I'm using it operationally, including clicking to drag the > entire canvas around so I can see things, it is not hard to understand that > if I click slight off of where I intend, I can inadvertently move things that > I do not intend to move. Again, THIS HAPPENS ALL THE TIME, and not just by me. > > PLEASE, add an "EDIT MODE/OPERATION MODE" toggle, and although I know it > would be very difficult to do, add some for of canvas "undo", at LEAST "one > level", letting you restore something you just deleted! > > Paul > -----Original Message----- > From: Andy LoPresto > Sent: Mar 22, 2016 8:03 PM > To: Paul Nahay > Cc: [email protected] > Subject: Re: Errors in your Documentation > > Thanks Paul. > > Bugs and feature requests can be submitted here [1] which will ensure they > are seen by the entire team/community. The most helpful reports include > screenshots when applicable, current system description, and potential use > cases or unit tests to verify issue resolution. > > Very quickly, you can accomplish a “non-edit mode” by assigning > “ROLE_MONITOR” to a user in the authorized-users.xml configuration file, but > currently a feature whereby a single user can switch back and forth between > those two modes instantaneously does not exist. Can you describe the use case > where you see this being valuable? Are you having trouble and accidentally > modifying items on the canvas? > > [1] > https://issues.apache.org/jira/browse/NIFI/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel > > <https://issues.apache.org/jira/browse/NIFI/?selectedTab=com.atlassian.jira.jira-projects-plugin:summary-panel> > > Andy LoPresto > [email protected] <mailto:[email protected]> > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > >> On Mar 22, 2016, at 4:55 PM, Paul Nahay <[email protected] >> <mailto:[email protected]>> wrote: >> >> Great. >> >> I can tell you a list of things I think need to be improved in NiFi. The >> most important is having two “modes” that one is always in, an “edit mode”, >> which is basically what you have 100% of the time now, and a “non-edit >> mode”, where the user cannot move things (inadvertently) around on the >> canvas. >> >> Oh, and you desperately need an “undo”. >> >> Paul >> >> From: Andy LoPresto [mailto:[email protected] >> <mailto:[email protected]>] >> Sent: Tuesday, March 22, 2016 7:51 PM >> To: [email protected] <mailto:[email protected]>; Paul Nahay >> Cc: Jonathan Wood >> Subject: Re: Errors in your Documentation >> >> Thanks Paul. We always welcome feedback that helps us improve the product >> and documentation. I can’t promise those documentation fixes will be >> released in 0.6.0 but we will try to get them out as soon as possible. >> >> Andy LoPresto >> [email protected] <mailto:[email protected]> >> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 >> >>> On Mar 22, 2016, at 5:52 AM, Paul Nahay <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> I'm looking at: >>> >>> https://nifi.apache.org/docs/nifi-docs/html/expression-language-guide.html >>> <https://nifi.apache.org/docs/nifi-docs/html/expression-language-guide.html> >>> >>> >>> isEmpty >>> Description: The isEmpty function returns true if the Subject is null or >>> contains only white-space (new line, carriage return, space, tab), false >>> otherwise. >>> >>> This logically implies that isEmpty returns FALSE if the Subject contains >>> NO CHARACTERS AT ALL (not even white-space). This makes no sense at all. >>> >>> >>> allAttributes >>> Description: Checks to see if any of the given attributes, match the given >>> condition. >>> >>> Hopefully you actually mean "all", not "any". >>> >>> What's funny here is that THESE TWO functions were the ones I initially >>> needed, and your documentation has errors for BOTH of them. I'll expect >>> then to find more errors in your documentation, and will report them to you >>> as I find them. >>> >>> Feedback confirming the errors will be appreciated. >>> >>> Paul Nahay >>> [email protected] <mailto:[email protected]>
signature.asc
Description: Message signed with OpenPGP using GPGMail
