flarum / issue-archive

0 stars 0 forks source link

[Tags] Secondary tags count restrictions affect nested primary tags #46

Open askvortsov1 opened 3 years ago

askvortsov1 commented 3 years ago

Bug Report

Current Behavior

Original report on discuss: https://discuss.flarum.org/d/28669-posts-and-users-are-not-visible-after-update-to-104-with-tags-plugin-enabled/4

https://www.youtube.com/watch?v=10aLM0ftTWE

Expected Behavior Secondary tags settings should not affect the selector for nested primary tags.

Environment

jordanjay29 commented 3 years ago

After a discussion with @askvortsov1, I'd like to propose the following solution:

Tag settings has requirements for 3 different tag types: Primary, Nested Primary, and Secondary tags.

The reasoning being as such: Nested tags cannot be treated strictly as primary tags without destroying the ability to enforce a hierarchical tag structure. To emulate a traditional forum board/sub-board structure, for example.

To further explain, I'll use this as a guide: image With current Flarum behavior, Nested and Secondary tags are equivalent, Correct and Incorrect Primary are equivalent too. If I start a new discussion, I can only select the Correct or Incorrect Primary to start. Then I can choose the Nested or Secondary (or neither) tags to add on.

Now assume the Primary and Nested Primary tags treated as the same setting. Now Correct Primary, Incorrect Primary, and Nested tags are equivalent. With the current settings, I cannot start a discussion that includes the Nested tag. Furthermore, the Primary settings is changed to 2 (or more), I can now start a discussion in both the Correct and Incorrect Primary tags. In this way, a hierarchical forum structure can be defeated from the top, whereas the current Flarum behavior allows it.

To allow both a simple and complex system of tags organization, a new setting for Nested Primary Tags should be added. This will allow for both a stricter hierarchy (the ability for sites to require distinct Primary and Nested Primary tags) and the same flexibility that the current system allows. It will also correct the problem presented in this issue, whereby the Flarum UI does not reflect current Flarum behavior.