Process List: Sorting, Columns, One-Click Link

[iaktern]

Some things not only relevant for the process list table:

• Automatically add creator infos: during the creation of a new process, automatically add the information about the creator in the BPMN (see PROCEED schema file: https://docs.proceed-labs.org/xsd/XSD-PROCEED.xsd)

  • rename the existing elements "creatorEnvironmentId" and "creatorEnvironmentName" to "creatorSpaceId" and "creatorSpaceName"
  • fill all creator elements and write it into the BPMN XML (creatorId, creatorName, creatorUsername, creatorSpaceId, creatorSpaceName). This should be a one-time operation: a user should normally not be able to change the creator-values afterwards. (Can we also block the changing in the XML-Editor?)
  • In the Process Property Panel, show (but not editable) "Created By" and, as value, the current Username of the "creatorId" (don't show the value of "creatorUsername" from within the BPMN, because this is just one time set at the creation of a process, but the user can change her username by herself)
  • "Owner" column: rename to "Created by" + show current username of creator (not id)

• Change title of "Edit Process" modal to "Process Meta Data"

• Add "Responsibility" column in the table

  • in the "New Process" and "Process Meta Data" modal, add the input fields to set the Responsibility for a process (same inputs as in the Property Panel)

• Add a new user-defined input field "ID" for creating a process (max 50 chars), e.g. Proc001 (additional to "Name" (max 100 chars) and "Description" (max 1000 chars)). Show it in "New Process" and "Meta Data" modal, in the meta+property panel and add a new table column. Extend the BPMN in the definitions element with the attribute proceed:userDefinedId (See: https://github.com/PROCEED-Labs/docs/blob/main/public/xsd/XSD-PROCEED.xsd)

• Rename the versioning modal to "Release the latest Process Changes", rename the button to "Release" and add some explaining content under the heading ("A process is released to publish a specific state for documentation or automation. Releasing a process means that a new version of the current process is created. All process versions can be reloaded and further developed at any time. ")

  • Add new permission named "Release Process" (under "Processes", explanation: Allows a user to create a new version of the latest process changes.)
  • Implement this new release permission in PROCEED (Editor List and BPMN Editor)
  • Bug Fix: a new version should only be createable if something has changed in the BPMN diagram. Currently, it seems that new process versions can be created although nothing has changes -> already correct bahaviour afterwards: it is not stored or shown => better: the user should directly see in the release Modal that no new version can be created. Show a hint in red under the explaining text, deactivate the input fields and Release button
  • add a new Column "Released" in the table with tooltip (explaining the content) and three states: no icon (means unreleased), green checkmark (latest changes are released in a version, latest == last version), yellow checkmark (there is an old version of the process, but updates have been made that have not yet been released, latest != last version)

• Some minor changes in the BPMN Editor and some of the functionality:

  • Bug Fix: after opening a collapsed subprocess with the button, the button does not disappear if already inside the subprocess
  • Rename "Export" icon tooltip and modal headings to "Download"
  • change the icon order in the right action bar and correct the naming: Show/Hide Properties, Show XML, Vertical Bar, Open Process Documentation, Share, Download
  • Share modal -> Share Public Link: Add a drop down input field under the separator to select the released process version that should be shared. Default: the version that is currently shown in the editor ("latest" should also be possible)
  • Share modal -> Embed in Website: Add a drop down input field under the separator to select the released process version that should be embedded Default: the version that is currently shown in the editor. "latest" should not be possible to select.
  • Share modal -> Diagram as PDF (add tile): show the same options as in the Download modal and a "Download" button
  • Share modal -> Diagram as PNG (rename tile): show the same options as in the Download modal and show a "Download" button as well as a "Copy to Clipboard" button
  • Share modal -> Diagram as SVG (add tile): show the same options as in the Download modal and a "Download" button
  • Share modal -> Download: close Share Modal and open Download Modal

---

Just for the table (and related elements):

• Default Sorting mode: Creation Date

  • Store user-selected sorting Mode in localstorage of the browser

• Delete "File Size" column

• Value in the "Created on" column should include the time (not just the date). The important point is, it must be consistent with "Last Edited". Lets make is similar to MS Teams (implement logic in frontend):

  • if Date is smaller than 1 day, show the time, e.g. 13:37
  • if Date is smaller than 7 days, show the number of dates, e.g. "5 days ago"
  • if Date is more than 7 days away, show the date without time, e.g. "13.12.2024"
  • The hovering tooltip should always contain the full date and time.

• In the top action bar if a process is selected, show the following icons in this order (and name it like this): View Process Documentation, Open Editor, Open Editor in new Tab, Change Meta Data, Release Process, Vertical Bar, Move to Folder, Copy, Delete, Vertical Bar, Share, Download

• in row action bar if the mouse is hovering over an row, show the following icons in this order: View Process Documentation, Open Editor, Change Meta Data, Release Process, Share

• in in the right click menu, show the following icons and names in this order: Process Name, View Process Documentation, Open Editor, Open Editor in new Tab, Change Meta Data, Release Process, Share, Download, Move to Folder, Copy, Delete, Horizontal Bar, Create Process, Create Folder, Import Process (not anymore: Copy Process Link)

• Change Icon Symbols in right click and top and row action bars (of course, only if the icon appears there):

  • View Process Documentation (change icon also in BPMN Editor): import { GrDocumentUser } from "react-icons/gr";
    • this is the "Open Documentation" page from Janis where the process is shown on a A4 page with all meta data. Also change the name and icon inside the BPMN Editor
  • Open Editor: import { PiNotePencil } from "react-icons/pi";
  • Open Editor in new Tab: import { IoOpenOutline } from "react-icons/io5";
  • Change Meta Data: import { LuNotebookPen } from "react-icons/lu";
  • Release Process (change icon also in BPMN Editor): import { BsFileEarmarkCheck } from "react-icons/bs";
    • Should open the updated versioning modal
  • Share (change icon also in BPMN Editor): don't change
  • Download (change icon also in BPMN Editor and Share modal): import { PiDownloadSimple } from "react-icons/pi";
  • Move to Folder: import { RiFolderTransferLine } from "react-icons/ri";
  • Copy: import { IoMdCopy } from "react-icons/io";
  • Delete: don't change

  ---

  • Create Process button and right click: import { AiOutlinePartition } from "react-icons/ai";
  • Create Folder button and right click: don't change
  • Import button: import { PiFolderOpen } from "react-icons/pi";

• delete the file icon in front of the Name of every process -> no icon anymore

• Modal for "Move to Folder" action, if a process should be moved to another Folder. Either a nice Tree Structure or an Drop-Down Input Menu, showing all Folders a User is allowed to access

  • Add the "Move to Folder" component to the Copy-Modal, so that a copied process can directly placed into a target folder

• Rename "Import Process" to just "Import"

• Use a click to open the drop down menu for "Create Process" (not hovering like it is now). (Also for the User Profile Symbol on the top right corner.)

• Row Behaviour:

  • except the action columns (select, star, row action bar), the whole row should be clickable to open the Process Editor or open the Process Editor in a new Tab (if Ctrl is also pressed): the click should work on the whole "content area" of the row/cell, not on the padding, click should be indicated by the pointer mouse, no cell padding left and right in a cell so that the row is continuous, just some cell padding on top and bottom which is not clickable (smaller than now and the content area a little bit higher)
  • right click should work in whole row like it is now, but don't activate/set the select input/cell
  • drag and drop should work for the whole row (like it is now)
  • E2E-Tests

• Sorting on all Columns should be possible, execept from "Description"

  • Sorting: should Folder always be on top or not?
  • E2E-Tests

• Columns adding and deselecting Bug: should work again

  • E2E-Tests

• Process-List: 'Name' column should not be de-selectable

• 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 => Adjustable List-Column-Width #278

  • E2E-Tests => remove?

• Column Size should be adaptable (width) => Adjustable List-Column-Width #278

• 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 => Adjustable List-Column-Width #278

• Right Click Context Menu: Open, Open in New Tab, Copy Process Link, Make a Copy

• Button for Creating a new Folder

  • E2E-Tests

• store every User setting of the process list in the localstorage

• make the process list component abstract and reusable for usage in other view

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

[FelipeTrost]

Value in the "Created on" column should include the time (not just the date)
@iaktern I don't know if this is such a good idea, with dates that are really old, people don't usually care about the exact time, maybe the full date could be in a tooltip?

[iaktern]

Your right with old dates. But if they are new, the exact time is often quite interesting.

The important point is, it must be consistent with "Last Edited".

Lets make is similar to MS Teams (implement logic in frontend):

• if Date is smaller than 1 day, show the time, e.g. 13:37
• if Date is smaller than 7 days, show the number of dates, e.g. "5 days ago"
• if Date is more than 7 days away, show the date without time, e.g. "13.12.2024"

The hovering tooltip should always contain the full date and time.