Add support in ui-library for tree data structures

[asmecher]

For https://github.com/pkp/pkp-lib/issues/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

https://github.com/user-attachments/assets/f18d3796-d845-4a66-ba19-54124322a98b

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

https://github.com/user-attachments/assets/f18d3796-d845-4a66-ba19-54124322a98b

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!

https://github.com/user-attachments/assets/cc4095a8-2831-4c4d-a3d3-2e1987291889

[taslangraham]

@asmecher @Devika008

Under Workflows Affected by This Change, it states: "The submission wizard – Authors will need to choose submission categories."

Currently, this is configurable—admins can decide whether category selection is required during submission. For 3.6, should this setting be enabled by default, requiring authors to select a category when creating a submission?

[asmecher]

@taslangraham, no, it should continue to be configurable. Most journals won't use categories at all, and some will want the editor only to choose what categories a submission might be assigned to.

[Devika008]

@asmecher I think isn't it a criteria for ORE for the authors to select which subject categories they are submitting to? Currently the author/editor selects the section? So a question will this remain and categories be added over and above this?

[asmecher]

@Devika008, I think sections should continue to be mandatory, though this perhaps needs a review with respect to continuous publication. Categories already can be made available for author selection in the metadata settings:

If possible, I'd like this to remain as is!

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