Add support in ui-library for tree data structures

[asmecher]

For #10404, we'll need a UI tool that'll allow the construction of arbitrarily nested trees. For example, we might support a 4-level tree:

• Subject
  • Mathematics
    • Calculus
      • Integral Calculus
      • Differential Calculus
    • Geometry
      • Trigonometry
      • Non-Euclidean Geometry
    • Discrete Mathematics
      • Logic
      • Set Theory
  • Physics
    • ...
  • Biology
    • ...
• Funder
  • Agency A
  • Agency B
  • Agency C
• Thematic Area
  • Adaptation to Climate Change
  • Environmental Sustainability

At the simplest, we could just require a tool that supports the presentation of the tree, and leave editing (and rearrangement and deletion confirmation) to modals.

We may need fine-grained server-side control over how the tree can be re-arranged -- for example, control over "Mathematics" and its contents could belong to User A, and "Geometry" to User B, so while it's tempting to permit drag-and-drop rearrangement, that might complicate things unnecessarily. Rearranging the tree should be an uncommon task.

Specs Update - Friday, September 27th, 2024

Workflows Affected by This Change

• Settings > Journal > Categories - the entire interface will change to incorporate this change
• The form for "AddCategory" - removal of "Parent Category" Form Field
• Assignment of Editors / section editors to main and sub categories
• The submission wizard - Authors will need to choose submission categories

Detailed Specs

Here's a quick prototype of how the tested tables can work

Screen.Recording.2024-09-19.at.17.16.00.mov

Prototype can be found here: https://www.figma.com/proto/Wf7sDlUg2372jaKKTJ0Mgz/OJS-3.4-3.5?page-id=7200%3A7069&node-id=8927-11021&node-type=frame&viewport=1746%2C-16265%2C0.2&t=xtFViZnaW9GHQRLs-1&scaling=min-zoom&content-scaling=fixed&starting-point-node-id=7200%3A7075
Link to Designs: https://www.figma.com/design/Wf7sDlUg2372jaKKTJ0Mgz/OJS-3.4-3.5?node-id=8927-9658&t=L8lZRbByMRi3ASfK-4

Some Considerations

1. We already have similar functionality in our new navigation, so implementing this should be straightforward. It will work like the PrimeVue panel menu component found here: https://primevue.org/panelmenu/
2. The "Add Category" option will only allow the addition of main categories, removing the form field for the parent component when adding a category
3. To add subcategories, you can click "More Options" and add child items below the main categories. The table will keep expanding with nested categories unless a limit is set.
4. Also I think we should only allow ordering of main categories i.e. the first level and nothing below that
5. If an editor/section editor is assigned to a category no matter the level we display them in the table
6. Assigning the editors/section editors to categories.
7. Editors/Section Editors can be assigned to each sub-category as well. I don't want to limit this functionality and want to keep it at the discretion of the journal.

[Devika008]

Here's a quick prototype of how the tested tables can work

Screen.Recording.2024-09-19.at.17.16.00.mov

Prototype can be found here: https://www.figma.com/proto/Wf7sDlUg2372jaKKTJ0Mgz/OJS-3.4-3.5?page-id=7200%3A7069&node-id=8927-11021&node-type=frame&viewport=1746%2C-16265%2C0.2&t=xtFViZnaW9GHQRLs-1&scaling=min-zoom&content-scaling=fixed&starting-point-node-id=7200%3A7075

1. We already have similar functionality in our new navigation, so implementing this should be straightforward. It will work like the PrimeVue panel menu component found here: https://primevue.org/panelmenu/
2. The "Add Category" option will only allow the addition of main categories, removing the form field for the parent component.
3. To add subcategories, you can click "More Options" and add child items below the main categories. The table will keep expanding with nested categories unless a limit is set.
4. Also I think we should only allow ordering of main categories i.e. the first level and nothing below that
5. If an editor/section editor is assigned to a category no matter the level we display them in the table

[jardakotesovec]

Some implementation guidance:

Ideally if we could leverage this headless-component to bring this to the live - https://reka-ui.com/docs/components/tree .

We intended to rely on the primevue for some of these more complex headless components, but we had way too many issues with it. And the support was not great.

Therefore we are hoping that reka-ui, could help us in this area. nuxt-ui is built on top of it - that should help with momentum.

If there would be reason why it can't be achieved with this component, let me know so we can think about the options. Or maybe sometime design adjustments are also the option.

[Devika008]

Hi @taslangraham

Thank you for highlighting the considerations around adding multiple editors in the "Assigned to" option!

I have two possible approaches, but the final decision will depend on @jardakotesovec and how the initials for usernames are implemented.

Option 1

If initials for usernames aren’t used, we can follow the same approach as how authors are listed on a submission in the front-end—with names separated by commas.

Option 2

If we're ready to use initials, we can display them alongside the initials, and when hovered over, the full names will be visible. This keeps the interface clean while still providing full details when needed!

Screen.Recording.2025-02-12.at.17.16.57.mov

[Tribunal33]

@jardakotesovec or @taslangraham any reason to keep this one open. #10404 has passed QA. Anything left to do for this?

[taslangraham]

@Tribunal33 both tickets can be closed together. Thanks for testing!