[Feature request] Drag and drop steps

[GrylledCheez]

[Feature request] Drag and drop steps

[MWedl]

Implemented in https://github.com/Syslifters/sysreptor/releases/tag/2023.145

For small fields (string, enum, date, CVSS, etc.) drag-and-drop is used for sorting. For large fields (markdown, object, nested list) move-up and move-down buttons are available.

[MWedl]

I guess steps is a custom field of type=list.

We can definitely make lists sortable via drag and drop in the UI. I think the sorting better fits into the main editing pane, because

• we want to keep the finding list clean to have a quick overview (without nested structures)
• in order to sort lists you need to have the editing lock of a finding. In the sidebar, we cannot guarantee that you have the lock and sorting might fail because another user is currently editing the finding. In the main view, however, you acquire the lock when opening the page and it is guaranteed that you have it while sorting, so there will be no conflicts.

[GrylledCheez]

You could implement it so that you can only sort it if it's locked to you. For example, have the user click the finding in the left side. Then it will lock and they can rearrange as desired.

Also, you could make it so double-clicking a finding in the left will un-nest steps. That way it isn't always cluttered.

It could also be an expanding tray that opens to the right so the findings don't jump around on you and both panes are visible.

[MWedl]

Only being able to sort fields while having selected a finding might be annoying when you want to sort of other/multiple findings. The finding list items are already quite densely filled with information (title, severity color, status, assignee, lock), so I would prefer not to add and additional expand icon. Double clicking would be a hidden features that you don't see in the UI, i.e. you have to know that it exists in order to use it.

The preferable solution, that integrates best into the current structure and functionality of SysReptor, is sorting in the main panel. It is also easier to handle edge cases like nested lists and makes it clear that you cannot move items between findings.

[GrylledCheez]

Skew the scale for a minute.

Pretend you have a finding (or phase) with 10 steps that have 1000 lines each as well as pictures.

How would you suggest we drag and drop?

If we do it like that, you could implement something like... When we grab a step in the main editor UI, each step collapses into the step name. Otherwise you run into the slow/fast elevator problem.

[GrylledCheez]

Also, apparently I'm the king of finding edge cases. Like the OSDA KQL template, apropos of nothing...

[aronmolnar]

@GrylledCheez I see you're talking about a concrete design: The OffSec OSDA design.

To give a bit of context to other readers: You can use SysReptor to do reporting for certifications.
The OSDA design holds an element: a list of objects, consisting of a title and a description. This list is called "steps". You can add as many as you like.

Looks like this:

I get your point that drag and drop is not the best solution, because of the height of this element.
Such lists of objects are, however, rather the exception. Usually, lists look like this:

Drag & Drop makes more sense there.

The "steps" case, however, is rather an edge case and exists due to the format of the OSDA report.
With SysReptor, you can even have multiple lists of different objects, that do not even have to have a title (to be referenced in the sidebar).

(e.g. many reports contain a list of strings for "affected targets" and a list of strings for "resources")

How would you now define...

• which of those lists should appear in the sidebar (if any)
• what text should appear there

For most lists, it does not make sense to appear there.
This is the reason, we will not go for this solution.

I still see however the point that drag&drop is difficult in this specific case.
(Maybe it could be solved to allow drag&drop via grip and also arrows to move it up or down. But this might not work well for smaller list elements.)

[GrylledCheez]

What if the grab bar collapsed each object with the step name being visible?

[aronmolnar]

We need a generic solution for this.
Objects in list can consist of anything. The fact that there is a title in this case is coincidence. The object could be a date and an enum field, or even be empty (instead of string and markdown).

[GrylledCheez]

Could it be the first line of text in the first text box per element?