Advance to recommended button is not consistently available when it seems base requirements are met

[mcking65]

In staging, I advanced the meter plan to candidate. Required reports are complete. There are 0 open issues. The advance to recommended button is not available.

I am guessing there is a date-based rule associated with the visibility of the button. If my guess is correct, to resolve this bug, please remove it and allow admins to advance sooner than the timeframe specified in the working mode.

While it is not yet apparent in the current version of the working mode, there are scenarios where at its discretion, the CG should be able to advance a new version to recommended sooner than the timeframe specified in the working mode. For example, a new version of a plan contains only a minor but still substantive change and that change impacts only one AT. In that case, 180 days is unnecessary. They agreement may have been made in advance, so 0 days may be needed.

In lieu of preventing advancement on a faster time table, the confirmation dialog could contain the following text:

Warning! the TEST_PLAN_NAME test plan has been in candidate review for X days, which is Y fewer days than recommended by the ARIA-AT working mode. Confirm this action only if impacted stakeholders have had sufficient opportunity to provide consensus.

In addition, as part of this proposed resolution, make it possible for admins to control the recommended number of days for candidate review by adding a workingMode object to property to /tests/support.json with a property for the length of candidate review in days:

{
  "workingMode": {"numberCandidateReviewDays": 180}
}

[mcking65]

Potentially related to #798

[lolaodelola]

Hi @mcking65,

Just wanted to follow up on this issue and get some clarification/draw your attention to some potential future problems, especially concerning

In addition, as part of this proposed resolution, make it possible for admins to control the recommended number of days for candidate review by adding a workingMode object to property to /tests/support.json with a property for the length of candidate review in days

This presents a maintenance burden and potential gotcha down the line. Within our current architecture, we don't store config data in the ARIA-AT repo except for the tests. Introducing config data in this repo creates two sources of truth that any engineer engaging with this will need to know about, an additional source of complexity, and the configuration will need to be piped through the entire import system, including the database, and as mentioned it’s a deviation from our current architecture

There is already UI within the app to do this work, does that UI not meet your needs? As we build we want to ensure we're not adding redundancy as it'd be a shame if, considering the work we'd need to do to implement and maintain this, it's unused.

[lolaodelola]

Hi @mcking65,

Another proposal for you. How do you feel about expanding the scope of these changes so that the requirement that ALL open issues have been closed before the test plan can be advanced is relaxed? Alex and Howard have rightly identified that it seems conceivable that an issue could crop up that is minor but valid, and worth doing but non-blocking. For example, if a community member made an issue to suggest a way to collect the same data with fewer tests, we would want to keep the issue open but also we wouldn’t want to have to stop everything to address it. We also wouldn’t want to have to close it just to advance. What do you think? The estimated impact on the timeline would be minimal and this seems like a trivial thing to implement but could have a decent enough impact on the workflow.

[mcking65]

In addition, as part of this proposed resolution, make it possible for admins to control the recommended number of days for candidate review by adding a workingMode object to property to /tests/support.json with a property for the length of candidate review in days

This presents a maintenance burden and potential gotcha down the line. Within our current architecture, we don't store config data in the ARIA-AT repo except for the tests. Introducing config data in this repo creates two sources of truth that any engineer engaging with this will need to know about, an additional source of complexity, and the configuration will need to be piped through the entire import system, including the database, and as mentioned it’s a deviation from our current architecture

OK, then, if that is not a good approach, ignore this suggestion. I was assuming it would be straightforward to consolidate admin-configurable, test-related data in tests/support.json. I assumed then, that it would be an inexpensive approach because it would obviate the need for UI related to such parameters. I don't really want to build UI for ssetting the value of parameters that are not likely to change often.

There is already UI within the app to do this work, does that UI not meet your needs? As we build we want to ensure we're not adding redundancy as it'd be a shame if, considering the work we'd need to do to implement and maintain this, it's unused.

It's not clear which UI to which you are referring.

How do you feel about expanding the scope of these changes so that the requirement that ALL open issues have been closed before the test plan can be advanced is relaxed? Alex and Howard have rightly identified that it seems conceivable that an issue could crop up that is minor but valid, and worth doing but non-blocking. For example, if a community member made an issue to suggest a way to collect the same data with fewer tests, we would want to keep the issue open but also we wouldn’t want to have to stop everything to address it. We also wouldn’t want to have to close it just to advance. What do you think? The estimated impact on the timeline would be minimal and this seems like a trivial thing to implement but could have a decent enough impact on the workflow.

I think this is a good idea.

[mcking65]

Appears to be fixed in staging. This is difficult to test fully as it would require creating a wide variety of conditions that take quite a bit of time to create.