View Issue Details

IDProjectCategoryView StatusLast Update
0005485SUMoBugpublic2019-06-10 14:36
ReporterwolfAssigned ToKyle_Katarn 
PrioritynormalSeverityminorReproducibilityalways
Status acknowledgedResolutionopen 
Product Version 
Target Version5.9.xFixed in Version 
Summary0005485: "Blocking action" feature still not documented after more than 11 years now
DescriptionBlocking 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 InformationThe 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.
TagsNo tags attached.

Relationships

related to 0000556 acknowledgedKyle_Katarn Remove the Loading, Checking, and Scanning Pop-Up Windows 
related to 0005541 acknowledgedKyle_Katarn scan action takes very long without any display changes 

Activities

Kyle_Katarn

2019-05-16 09:24

administrator   ~0003292

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 ?

Zer0 Voltage

2019-05-16 09:24

reporter   ~0003293

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?

Kyle_Katarn

2019-05-16 09:24

administrator   ~0003294

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...

Zer0 Voltage

2019-05-16 09:24

reporter   ~0003295

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!

Kyle_Katarn

2019-05-16 09:24

administrator   ~0003296

OK !

avmaksimov

2019-05-16 09:24

reporter   ~0003297

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!!!

wolf

2019-05-16 09:24

reporter   ~0003298

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.

wolf

2019-05-19 19:47

reporter   ~0003352

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.

Issue History

Date Modified Username Field Change
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
2019-06-10 14:36 wolf Issue cloned: 0005541
2019-06-10 14:36 wolf Relationship added related to 0005541