View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0005442||SUMo||New Feature||public||2019-04-23 09:48||2019-04-23 20:08|
|Target Version||Long term||Fixed in Version|
|Summary||0005442: create an additional report view hierarchical and a configuration option to switch between the current and the new view|
|Description||SUMO currently creates a flat report of locally detected applications, versions and update state. This is done in some intransparent and inconsistant manner. I don't think it makes sense to fix these inconsistancies as long as no other report view exists as. These inconsistancies were propably introduced to make some users happy resp. satisfied while others were happy with a former behaviour.|
Instead of having just one kind of report, SUMO needs at least one additional form of report including the configuration option to switch of one kind to the other. A hierarchical report view seems helpful for different use cases then the current flat report view. Both are helpful and meaningful. Take a look at threat https://www.kcsoftwares.com/forum/viewtopic.php?p=5116 in the forum for further discussion. Various kinds of browsers already have such a hierarchical view implemented like file system browsers in the file system tree resp. forest.
The first level of abstraction resp. grouping shall not be any already displayed attribute. Instead at the new high level only installed and detected applications shall be reported. Those application which have components shall be reported expandable. Only by expansion its components shall be reported too.
I know that there exist applications with components that have components itself. And there exist installations with several applications coming with a common component possibly in different versions. (This will be difficult to see in a hierarchical view and easy in a flat view.) Hiding the components improves ease of use makeing it useful for less experienced users. Such a view does not suppress reporting on the components. Their relationship and other detail will be accessible by expansion (unless a user wants a configuration option to expand all hierarchy levels by default enabled).
When such a hierarchical view is added and enabled another revision may add other grouping preferrable not as an alternative but as an additional abstraction level. There exist 2 proposals (application domain and application publication organisation). These may be competing or almost independant and may be discussed in the forum, i.e. in the existing above mentioned threat. They should not be implemented with this issue in order not to delay implementation and release of the feature so that these additional proposals may be decided, implemented and released in another release.