PR - Add 'hide' support and a new meta-data option to List2need directive

[christopheseyler]

Added the support for "hide" option to affect the hidden status to all requirements in the list. This allows to easily create a list of requirements that could be only presented as a table in the final output.

.. list2need::
      :types: req
      :tags: A
      :hide: True
      * (NEED-A) Login user
      * (NEED-B) Provide login screen
      * (NEED-C) Create password hash
      * (NEED-D) Recalculate hash and compare
  
   .. needtable::
      :types: req
      :tags: A
      :style: table
      :columns: id, title, content, links

this example is added in the documentation

The PR also add a new meta-data option to give the ability to set meta-data (including extra defined custom option to all elements in the list)

.. list2need::
      :types: req
      :tags: A
      :meta-data: validation="Test, Review of Design", status="open"
      * (NEED-A) Login user
      * (NEED-B) Provide login screen
      * (NEED-C) Create password hash
      * (NEED-D) Recalculate hash and compare

[danwos]

Thanks for the great enhancement.
I really like the benefit of it.

The PR is also looking already quite good, just 1-2 minor comments to the code. And 1-2 test cases are missing :)
Can you add them? Then I will give it a go 👍

If any help is needed, just let me know.

[danwos]

Maybe we should rename meta-data to something with global or option in the name because we already have needs_global_options as a config parameter, which does something similar: setting values globally for specific needs.
That's the same here.

So, what about naming the parameter just global?`

[christopheseyler]

to stay in the same mind, I've renamed to list_global_options

[christopheseyler]

The PR is also looking already quite good, just 1-2 minor comments to the code. And 1-2 test cases are missing :) Can you add them? Then I will give it a go 👍

If any help is needed, just let me know.

I would like to know if these is a way to perform the tests based on the needs.json output instead of parsing/inspecting the html output. At this level, I don't want to test if the "hidden state" or "all options" are properly rendered, but I want to focus on "if the needs in the list have these global options attached to them (and the same with the hide status)

[danwos]

I would like to know if these is a way to perform the tests based on the needs.json output instead of parsing/inspecting the html output. At this level, I don't want to test if the "hidden state" or "all options" are properly rendered, but I want to focus on "if the needs in the list have these global options attached to them (and the same with the hide status)

For sure you can also build the test-projects with the "needs" builder to check the needs.json output.

And we also have some test cases, where the internal data (stored in the env var) is directly checked.
So it is open to you, to choose the best data element to check.

[christopheseyler]

I fixed some bugs and added tests for both features (list_global_inputs and hide)

[danwos]

I guess list_global_options needs to be documented also in the docs.
There it is still meta-data.

The tests are looking go.

When documentation fix is done and CI is green, I would give it a go.

[chrisjsewell]

Heya, the whole list_global_options I feel is overcomplicating things, and also negates the need for a separate hide option (or in-fact tags etc).
Just do this:

.. list2need::
   :need-options:
      :hide:
      :tags: a,b,c
      :status: open
      :validation: Test, Review of Design

then there is no need for any complex regex parsing; you just basically take the whole block and insert it into the jinja (removing top/bottom blank-lines)

[chrisjsewell]

Suggested change

	version = "4.2.0"
	version = "4.1.0"

you don't need to change the version in a PR

[christopheseyler]

Heya, the whole list_global_options I feel is overcomplicating things, and also negates the need for a separate hide option (or in-fact tags etc). Just do this:

.. list2need::
   :need-options:
      :hide:
      :tags: a,b,c
      :status: open
      :validation: Test, Review of Design

then there is no need for any complex regex parsing; you just basically take the whole block and insert it into the jinja (removing top/bottom blank-lines)

I though about something like that, I'm just a bit concerned about the fact I've never seen "nested" options elsewhere. So, I though that adding ":hide:", ":tags:", ... would be more the same syntax than with the ..need / ..req directive.

What do you think ?

[chrisjsewell]

Im just a bit concerned about the fact I've never seen "nested" options elsewhere.

list_global_inputs are nested options, just in a completely bespoke format 😅
nested options are fine, it just obviously a very rare use case

How I said above is the way to go; it is much clearer to the user what options will be parsed through to the needs