View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005485||SUMo||Bug||public||2019-05-16 09:24||2019-05-19 20:23|
|Target Version||5.9.x||Fixed in Version|
|Summary||0005485: "Blocking action" feature still not documented after more than 11 years now|
|Description||Blocking action is a known bug, limitation and feature needing redesign, refactoring and documentation. Several users don't like such a feature and have some reasons (resp. motivations) already reported in the parent issue still not being addressed. Although they asked for the meaning and list of such actions, they still didn't get an answer neither by user manual, forum nor Mantis. It seems to me that due to lacking information mutual understanding of different perspectives is missing too leading to inappropriate priorities and scheduling. It further looks like there is not a sufficient distinction between requirements, design decisions and other kinds of issues which doesn't provide enough protection against bad and inappropriate design decisions. Communication and documentation helps to address this missing protection at design level and above (more abstract levels in increasing order of abstraction level like requirements, user stories and epics).|
Without such information, I can only provide feedback about the impressions provided so far that the tool probably needs some protection between scanning and reporting action. But such a protection does not require neither blocking these action requests against each other nor blocking against any action requests nor actions. Why shouldn't it be possible to open any kind of help lookup while a scan or check action is performed?
I can't imagine any such reasons to protect these help operations against scan or check actions resp. operations while observing that they are still protected against these scanning and checking actions. Didn't check the other way round which I can imagine as not being protected due to no need.
With a technical background, I can imagine a need to protect these scanning and checking actions against each other and against interfering with other operations. But blocking doesn't seem to be an adequate method with too heavy side effects. What about queueing interfering operations and performing non-interfering operations during such actions with some protection requirements instead of blocking anything including non-interfering operations like putting windows in background or system tray, resizing windows for changeing overlapping?
When may we expect some schedule for documenting or discussing these aspects on which platform (forum or Mantis)?
|Additional Information||The perspective of another user on time consumption and impact on priorities, I can't follow although understanding it. I've some devices of different capacities. I can say now that on a notebook with enough memory and considerable power limited by thermal aspects, I'm already beyond those durations although the volume of installed applications is neither small nor large, something in between. And I just started to put into service another mobile device with more memory, less power and half the number of installed applications (due to available disk limitations), SUMo does report me twice the number of detected software tools and also taking twice the amount of operation taking about 10 minutes! (I didn't investigate on some available customization and optimization options already available in SUMo using exclude lists yet as I just started putting into service.)|
And tablets are usually more resource limited devices. Durations of SUMo actions are well in access of the above reported once (as well as operating system startup operations). And my tablet has standard power resources while having more than standard memory resources. I agree that optimisation considerations on such limited resource devices may have lower priority in the past but think that with already increased use and relevance this has to change too.
|Tags||No tags attached.|
I'd prefer not as "modal" windows are the best and most efficient protection against side effects.
Maybe would you like more "real time" info displayed ?
||No, it's not an issue of real time info. That's already there. My problem is with the stolen focus and inability to move or resize the SUMo window when those pop-ups are open. The load, scan, and check processes can take very long to complete and the SUMo window is stuck in place until they finish - making it difficult to monitor the progress and also open other programs while waiting. Plus it may be harder to have SUMo run as a true background process if it needs to use pop-ups (and I assume that's probably a long term goal). What sort of side effects do they protect against?|
If you don't put "modal" pop-up you have to prevent user to launch any new "blocking" action... and to restore everything once processing's done.
It led me to many bugs on previous projects...
||I'm not sure what you mean by blocking action or what gets restored, but I would still like to request a way to do things without such popups since I often need to resize the program window when some function is processing and would eventually like to be able to run SUMo as a background process (though I suppose that should be a post-2.0 concern). Thanks!|
||I think that it is not so actual, there are other tasks for implementation. It is possible and suffer a little, after all almost all processes occupy no more than two-five minutes. If would be it is more, would be much more actual!!!|
Any progess in the mean time?
What's the state of operation of SUMo without GUI, especially as with version 5.9 SUMo Online has been added which should work even when a remote device has SUMo installed although not started with a GUI while initiating an operation request on the new dashboard?
(I didn't verify as not all devices monitored in my dashboard are located in the same room.)
And disabling / enabling of auto-focus may be in interesting feature also to prepare for taking screenshots for support requests on certain race conditions.
||Due to (static or configured) limitations of MantisBT, this issue doesn't show that its related to issue https://www.kcsoftwares.com/bugs/view.php?id=556 and I don't have the privilege to add this relation although configured it so at issue creation. Description and additional info as well as just preceeding note are different and so is the focus. That's why I created a new one.|
|2019-05-16 09:24||wolf||New Issue|
|2019-05-16 09:24||wolf||Issue generated from: 0000556|
|2019-05-16 09:24||wolf||Note Added: 0003292|
|2019-05-16 09:24||wolf||Note Added: 0003293|
|2019-05-16 09:24||wolf||Note Added: 0003294|
|2019-05-16 09:24||wolf||Note Added: 0003295|
|2019-05-16 09:24||wolf||Note Added: 0003296|
|2019-05-16 09:24||wolf||Note Added: 0003297|
|2019-05-16 09:24||wolf||Note Added: 0003298|
|2019-05-19 19:47||wolf||Note Added: 0003352|
|2019-05-19 20:22||Kyle_Katarn||Relationship added||related to 0000556|
|2019-05-19 20:23||Kyle_Katarn||Assigned To||=> Kyle_Katarn|
|2019-05-19 20:23||Kyle_Katarn||Status||new => acknowledged|
|2019-05-19 20:23||Kyle_Katarn||Target Version||=> 5.9.x|