Looking for clarification on various constraints experienced when evaluating 'Delayed Field Evaluation' featue

[MrChocolateMoose]

Overview

I am evaluating the delayed field evaluation functionality for the first time.

I am trying explicitly avoid developing my own functionality since I fear that the safety certification path for it may be more limited and it may not interact well with ubtools.

Because of that, I am trying to accomplish everything I want with the built-in functions and variant functions (rule based only).

My Use Case 1

I didn't see anything explicitly forbidding me from trying to combine both variant functions (rule based) and dynamic functions, but I could not get it working.

I will modify Example 2: Negative check from the documentation to explain what I was trying to do because check_linked_values returns None instead of having a result_if_true and result_if_false field:
Modified Example 2

.. spec:: result 1: Positive check
   :links: clv_A, clv_B
   :status: <<[[check_linked_values('True', 'status', 'in progress' )]]:progress, closed>>
   :collapse: False

I tried about 20 different combinations of syntax and was not able to get it to work (e.g. <[check_linked_values('True', 'status', 'in progress' )]:progress, closed>> - couldn't find the function check_linked_values)

My Use Case 2

I wanted to have a "checklist" with "checklist items". I wanted to cleverly implement the "checklist items" as inner needs of the checklist:

EXAMPLE

.. checklist:: Review for XYZ
   :id: CHK_LIST_001
   :reviews: SW_REQ_XYZ

   .. check:: Completeness
      :id: CHK_001_01
      :status: passed

   .. check:: Verifiable
      :id: CHK_001_02
      :status: failed

With the constraints I imposed on myself, I wasn't able to accomplish my goal which was:

• Automatically set the overall checklist to passed if all items are passed (e.g. no failed) or failed otherwise
• Automatically set the status of the linked SW_REQ_XYZ to passed or failed based upon the checklist(s) [may be 1..N] status fields
• A side note, I plan on link the checklist to the SW_REQ_XYZ via versioned links when it's available: Versioned links #1559

The challenges I met were:

check_linked_values does not let me specify what kind of links to check

I was expecting that I could specify I could key off of the automatically generated child needs backlink for an inner need to look at all of their status values, but I couldn't. It had to be links (at least that is what the examples and inspected code read needs["links"])

check_linked_values does not let me specify a true and false value for evaluation

I was expecting like excel to set a truthy/falsey into the function. I tried to workaround it unsucessfully via variant functions.

Multiple levels of evaluation seems unsupported

I wanted to be able to accomplish "Automatically set the status of the linked SW_REQ_XYZ to passed or failed based upon the checklist(s) [may be 1..N] status fields" goal via [needs.global_options.status] with a predicate that would use the backlinks of the reviews to either use some kind of copy or another check_linked_values (with variant support or truth/false arg support) to propagate the checklist state (passed/failed) to the requirement state.

Final Remarks

I need a bit of feedback to see if what I am trying to do is achievable in a safety-oriented manner.

I am not particular for how to bridge any gaps that may exist, as long as the functionality is flexible enough to combine various building blocks and be concealed. Ideally, I want to hide a lot of the complexities for delayed function evaluation in the configuration toml file because it may be daunting to the user to have to copy this functionality for 1000s of needs and the syntax is particular.

I think based upon what makes sense to support, that some of the documentation may need to be updated with a few more use cases and things that do not work (e.g. if multiple levels of delayed evaluation chaining is not expected to work).