Regarding the "undo" feature, just wanted to mention there is a ticket [1]. On a related note, there was also talk of confirmation dialogs as perhaps an alternate way of catching unintended actions [2].
[1] https://issues.apache.org/jira/browse/NIFI-833 [2] https://issues.apache.org/jira/browse/NIFI-1089 Rob On Wed, Mar 23, 2016 at 1:13 PM, Andy LoPresto <alopresto.apa...@gmail.com> wrote: > 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 > alopresto.apa...@gmail.com > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Mar 23, 2016, at 4:28 AM, Paul Nahay <pna...@sprynet.com> 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: dev@nifi.apache.org > 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 > > Andy LoPresto > alopresto.apa...@gmail.com > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > On Mar 22, 2016, at 4:55 PM, Paul Nahay <pna...@sprynet.com> 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:alopresto.apa...@gmail.com > <alopresto.apa...@gmail.com>] > *Sent:* Tuesday, March 22, 2016 7:51 PM > *To:* dev@nifi.apache.org; 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 > alopresto.apa...@gmail.com > PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4 BACE 3C6E F65B 2F7D EF69 > > > On Mar 22, 2016, at 5:52 AM, Paul Nahay <pna...@sprynet.com> wrote: > > I'm looking at: > > 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 > pna...@sprynet.com > > >
