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

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

[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