I'm not a big fan of having a read-only mode by default. It sounds like
something that would be frustrating for users when they try to make
changes and then have to figure out how to switch modes.
I think a clearer picture of the problem we're trying to solve would
help my understanding. I'm primarily thinking of the delete case you
mentioned with these comments...
If we're talking about accidentally deleting processors, then the
current mechanisms (IIRC) work pretty well: not deleting a running
processor, one that has live incoming connections, etc. If those rules
are insufficient, I would explore extending them rather than having a
global read-only mode.
For the case where the wrong processor is selected because it is off the
screen, maybe having the confirmation pop up if anything affected wasn't
displayed to confirm? That way we don't have confirmations all the time
but still don't do unexpected things.
I really like the idea of "undo" as well. If that is limited to
processors that weren't running (because you can't delete ones that
are), then that makes the undo operation easier to implement.
rb
On 08/08/2015 11:31 AM, Joe Witt wrote:
I can dig the user pref aspect but it would mean we start storing user
prefs which is a bummer.
On Aug 8, 2015 1:42 PM, "Tony Kurc" <[email protected]> wrote:
Personally not a fan of the idea. Maybe something analogous to something
like 'lock the taskbar' in Windows that can have a system default setting
and a user preference of on or off.
On Sat, Aug 8, 2015 at 11:44 AM, johny casanova <
[email protected]>
wrote:
I agree it is easy to move it delete something by mistake. Some flows are
huge or are using,more resources and are slower to load and you can
accidently do something by mistake. I believe the "are yous sure u want
to
delete?" its a good start.
On Aug 7, 2015 10:31 PM, "Joe Witt" <[email protected]> wrote:
Team,
We've been hearing from users of nifi that it is too easy to
accidentally move something on the flow or delete large portions of
the flow. This is the case when panning the screen for example and
accidentally having a processor selected instead.
What is worth consideration then is the notion of making the flow
'read-only' by default. In this case the user would need to
explicitly 'enable edit mode'. We would then also support a
confirmation dialog or similar construct whenever deleting components
on the flow.
Anyone have a strong objection to this concept? If so, do you have an
alternative in mind that would help avoid accidental movement?
Thanks
Joe
--
Ryan Blue
Software Engineer
Cloudera, Inc.
