Process List: Sorting, Columns, One-Click Link

[iaktern]

• [ ] Default Sortig mode: ???
• [ ] Sorting on all Columns should be possible, execept from "Description"
  • [ ] File Size
  • [x] Sorting: should Folder always be on top or not?
  • [x] E2E-Tests
• [x] Columns adding and deselecting Bug: should work again
  • [x] E2E-Tests
• [x] Process-List: 'Name' column should not be de-selectable
• [x] Selecting of processes only on the checkbox column => had to remove shift-selection, as some browsers dont emit events, when shift+clicking inputs of type checkbox, as soon as one checkbox is checked => #278
  • [x] E2E-Tests => remove?
• [ ] Drag and Drop of processes into folders: not on the whole row anymore
  • [ ] if a process is selected, then show an icon in the action bar (on top of the table) for moving the process into a folder
  • [ ] Drag and Drop Symbol (Six-Point-Symbol) an the right row side of a Process and Folder: https://react-icons.github.io/react-icons/search/#q=drag
  • [ ] E2E-Tests
• [x] Column Size should be adaptable (width) => #278
• [x] Make the column blocks clickable with left click (also good for opening a process in a browser tab): ~all but Select Column and Star Column~ => Name and Description are clickable links, as soon as drag is changed, text selectable => #278
  • [ ] Text should be selectable (now it is not) -> see drag and drop
  • [ ] E2E-Tests
• [x] Right Click Context Menu: Open, Open in New Tab, Copy Process Link, Make a Copy
• [x] Button for Creating a new Folder
  • [x] E2E-Tests
• [x] store every User setting of the process list in the localstorage
• [x] make the process list component abstract and reusable for usage in other views

[FelipeTrost]

@iaktern I think adding a drag and drop symbol would make the process list too cluttered, what do you think?

[MaxiLein]

@iaktern I think the selection of Elements in the list via the checkbox should not be tested, as it is part of the antdesign table.

[iaktern]

@iaktern I think the selection of Elements in the list via the checkbox should not be tested, as it is part of the antdesign table.

yes, you're right: we should only test logic coming from our code. But in your case, isn't the selection logic coming from us? e.g., if someone clicks an icon within the row.

[MaxiLein]

@iaktern I think the selection of Elements in the list via the checkbox should not be tested, as it is part of the antdesign table.

yes, you're right: we should only test logic coming from our code. But in your case, isn't the selection logic coming from us? e.g., if someone clicks an icon within the row.

While the selection logic can be set from outside, I still think, it should not be tested as part of the selection of elements within the list.

The selection of an element in the list is given through AntDesign, we just pass it some callback for further functionality - which, currently, is just saving the selection in a state, as well as saving the last clicked element..

I think further added functionality should definitely be tested, however, this should come from the user's perspective, i.e. not checking state changes but rather gui changes associated with it. These test should then test the further functionality that follows / results from the selection. However, they should not test the selection itself, as it is given.

Functionality inside some nested elements such as buttons / icons can and should be tested - I agree - but they are not part of the selection either, but rather doing something else, such as copying or exporting.

As of for the way it is implemented currently, the only way to select an element, is via the 'Select all' shortcut, which has some tests on this branch (WIP), via the checkbox click (handled by AntDesign), or if starting some custom logic that then sets the selection from outside (e.g. exporting a process - which has, and should have its own tests). The latter - I think - should then be tested in tests for the respective functionality rather than a way of selection; otherwise the tests are overlapping.

[OhKai]

@MaxiLein We don't need to test implementation details of AntDesign, but we need to test that we use them correctly (e..g the correct props).

For example, we don't need to test the DatePicker component, that it displays the days of a month in the correct order - that is up to AntDesign. But we need to test that it is configured correctly (for example a max range of dates, show only months, also show day time, etc.). If, for example, we accidentally delete a prop or the name or type of a prop changes in AntDesign and we don't update it, it would be an error on our side that the E2E tests should catch.

For this selection case, AntDesign handles the drawing of the checkboxes, but only if we set the props correctly and store the selection. If we ever have a bug, that overrides the selection state, that needs to be caught by E2E tests. We don't need to test the checkboxes themselves, but we need to test that the selection as a whole works.

But as you said, since we should test user stories in Playwright, it should be enough to test the derived functionality of the modals etc. working with the selected processes, so that should be enough. Because that inherently also covers the selection of processes - it's just important that they are included in the tests somehow.