Questions on proposed database changes to better support #518 #632
Comments
howard-e
added
documentation
|
cc @mcking65 |
This question from the notes and questions section is also being discussed in #634 and w3c/aria-at#950. |
|
Thank you again for the excellent data model documentation. The formatting you did withheadings, tables , and lists makes it easy to read with a screen reader. I've now spent enough time with it to make some recommendations for better aligning the data model with the working mode, but first I will try to address the questions.
Note that a specific version of a test plan is in a phase of the working mode, not the test plan itself. Phase should be on testPlanVersion. That would reflect the working mode process. A test plan can have a version in each phase of the working mode. V1 could be recommended while V2 is in candidate review, V3 is in draft review, and V4 is in R&D Complete.
Note that a report is not "introduced to the test queue." A test plan run is added to the test queue. A test plan run is for a specific version of a test plan, an AT, and a browser. The test plan run generates a report. That report is associated with the test plan version, not the test plan. It is possible for the test queue to have runs for two different versions of the same test plan in it. Such a scenario could be:
When a new test plan version is merged to master in aria-at, it's working mode phase is R&D complete. It does not have any reports. Let's consider a specific scenario in detail.
The bottom line is that reports are tied to a specific version of a test plan.
Let's say V2 of test radio plan is in candidate review and if has a report for JAWS/Chrome generated using JAWS V2023.4. Now, let's say V2023.7 of JAWS is released and Vispero wants to see the report updated.
If V1 of a plan is recommended, when V2 is advanced from candidate to recommended, V1 is sunset. It will still be in the system and accessible from the page that shows all data for a test plan.
I think this is answered above.
Correct, there is potential for that type of problem if phase is a property of the test plan, but it is not. It needs to be a property of a testPlanVersion. Note, however, that reports do not have a phase. The stakeholders look at report to data when reviewing a plan, but they are not providing approval of the data, they provide approval of the plan. If a plan is approved, that means it can be used with any version of any browser and any AT to generate accurate data. The data that is generated by tomorrow's version of an AT may be very different from today's version of an AT. If the plan is good, the data is accurate. If the data from tomorrow's version of an AT contains more failures, by providing approval of the plan, an AT vendor has essentially stated that the new failures are AT bugs.
Yes that would be a problem. A test plan version cannot move backward through the process. The test plan itself does not move through the process, a specific version of the test plan moves through the process.
The array should be associated with a version of the test plan, not the test plan.
No.
Definitely agree that an events table could be very useful. We would probably need a separate table defining the types of events, e.g., eventTypes.
Possibly. However, it seems like we have all needed entities. The primary issue is that some of the relationships are not aligned with the working mode. We probably need to correct those issues. Here are some thoughts. Test Plan GroupIt appears to me that the data in this table belong in the test plan version table. Moving the following data to the TestPlanVersion entity would eliminate the need for the TestPlanGroup entity.
TestPlanVersionIn addition to the data that is in TestPlanGroup,there are some other essential data elements missing:
I believe this table should be updated to have the following columns.
TestPlanReportAs mentioned above, some of the columns in this table are not properties of a test plan report. One property that appears to be missing is the status of the report. It is either in-progress or complete. A report can't be visible on the reports page or candidate review page unless the admin has marked it complete. Rather than a status column, we might want a completeAt column. If the timestamp is null, the report is in progress.
|
|
@mcking65 Thanks so much for the details and clarifications. And the scenarios were quite appreciated! Given that w3c/aria-at#950 (and also #648) was implemented after this issue, a lot the recommended changes and concerns based on assumptions have been addressed in a revised database proposal, which I have now described here. It's based on internal discussions as well as follow up discussions we've had around #648, so it is already being used with in-progress work to implement #648. And I can say it does seem to map very well with your recommendations, and scenarios described in this issue, which is great!
Noted. Will create a follow up issue to track the implementation of this feature.
Agreed on this thought. We also arrived at the same conclusion that
Additionally, we also added:
Also, with w3c/aria-at#950 describing a clear separation of test plan versions, we also concluded that the
The proposed implementation on this hasn't been finalized as but having it as part of the metadata has been considered I believe, and more details should follow in the coming days, with your future functionality thought also considered.
This has been added as
This has been added as
This has been added as
I have a follow up here for my own clarification, but it may also be due to a consequence of terms defined in the application being different when compared with the WM. Isn't the vendor review done against the individual pairing of an AT to a collection of test plan run results (which the app's But this recommendation seems to imply that the entire Alert V2 (covering all ATs) could be reviewed at once. Is that intentional? Is there a change to the vendor review process or have I misunderstood this recommendation?
I agree with this name change being more appropriate.
This was added as
This was added as
This was added as
Yes, that's correct.
Yes, that's correct.
Indeed! We arrived at the same conclusion so this column has been removed (as well the resulting table relationship)
We added a column called Thanks again for this detailed review and comments. I also don't think the answers to any of my questions should cause any major blockers for us to continue current implementation efforts of #648, as we already seem closely aligned! |
|
@mcking65 wrote:
@howard-e wrote:
The vendor is reviewing and approving the plan, not the results. We provide the results to the vendor as part of the plan review because it is much easier for the vendor to review a plan if they know what results the plan produces when run with their product. It helps make sure they understand the meaning of the words in the plan.
Yes, but more specifically, When the JAWS rep reviews alert V2, they are saying they agree with the alert V2 plan. That means they agree with:
The tests are the same for all vendors. We are seeking consensus/approval on the tests as written in the Alert V2 test plan. Similarly, we want the NVDA rep to approve the tests and the NVDA implementation of those tests. If we made a change to the NVDA implementation that did not impact the test itself, e.g., we added or removed a command, we would not need to seek approval from other vendors for that change. When we have approval from a sufficient number of AT vendors and no objections, we advance the test plan to recommended, which means it represents industry expectations for screen reader behaviors for that pattern. This means that we can use Alert V2 plan to generate reports for future versions of JAWS, and Vispero trusts that the resulting reports will accurately reflect the support level provided by those versions. So, if a future report shows more failures, those failures would represent JAWS bugs. Vispero will not "approve" any of the reports -- they approved the plan that generates them. Essentially, the plan is like a spec, and the vendors approve a version of the spec and the way we mapped the spec requirements to the functions of their products. The entire spec moves through the process. We don't separately move vendor-specific pieces of the spec through the process. This is because the goal is to build a single spec for each pattern that represents consensus across the industry.
Understandable, but the relationship we want is between AT vendor review events and the test plan version. Note that:
Net: Phases, reviews, and and approvals apply to test plan versions. A test plan version should be associated with an array of "AT vendor review events" that represent all the review activity for that version of the test plan. Whether a report is rendered with the warning "Unapproved" or the notice "Approved" depends on the current phase of the test plan version from which it was generated. When a test plan version moves from candidate to recommended, all reports generated from that version of the plan that were previously rendered with the "Unapproved" warning will need to be rendered with the "Approved" notice text. In addition, all new reports generated from that version of the test plan will be rendered with the "Approved" notice text. For example, the button support table in APG is currently rendered with the "Unapproved report" warning. It has data for Chrome, Firefox, and Safari. Soon it will advance to recommended and the warning will be replaced with the notice that explains the report is "Approved", i.e., recommended. When we later add reports for Microsoft Edge, those will also have the "Approved" notice text because that version of the test plan is recommended. @howard-e asked:
It has always been the case that when the Alert V2 plan advances to recommended, it is The entire V2 plan, covering all at in the plan. It doesn't advance until we have approvals from enough vendors to represent industry consensus (in the judgment of the community group). Even though each vendor is reviewing the entire V2 plan, they probably don't care that much about how the commands of other vendor's products are mapped to assertions. That said, they do sometimes look at how the other products are tested, and if they observe inconsistencies, vendor A could question how the plan specifies that vendor B's product should be tested. @mcking65 wrote:
@howard-e asked:
Thinking about this further, I think the term we should use in the working mode is "deprecated" or "superseded". This would more accurately reflect what is happening, V2 causes V1 to be deprecated. If we want to temporarily understand that the data model word for "deprecated" is "archived", that is OK. However, we should have an issue that tracks updating that data element name to avoid confusion and future programming errors. I will comment on w3c/aria-at#950 to record a preference for deprecated over sunset. @mcking65 wrote:
@howard-e asked:
Yes, I believe a deprecated phase is important. We could figure out the sequence because if a plan version is deprecated when in draft, it will not have a candidate phase start date, but it will have a deprecated date. @mcking65 wrote:
@howard-e wrote:
I am good with "CompleteAt". Note however, in the discussion of UI in 709 we discussed marking the report final. I believe @jugglinmike had cautioned against using "complete" for this purpose as it may be confused with complete in another context; I don't recall the context. I don't know how critical it is for the word used in the UI and the word used in the data model to be aligned in this case. I am fine with either direction if the team decides alignment is important:
A decision should be made as this term might also need to be defined in the working mode glossary. |
|
I was just thinking of another way to explain of how reports are not related to candidate phase. We could have designed the candidate test review page without any reports. We could have said to the AT vendors, "here is a plan for how we will test to see which screen readers support the button pattern. Tell us if it is a good plan." We could have showed them the list of tests, the assertions for each test, and the screen reader commands we would use when running each test. We would tell them that these tests apply to any browser. Pretend for a moment that all screen readers have exactly the same set of commands. It would be kind of like a group of JavaScript engines that all support the same methods. Several vendors look at the same plan and tell us that we have specified the correct set of behaviors and ways of testing those behaviors. They are not looking at any reports; they are just looking at what we test and how we test. Once enough vendors approve, we know we have a good plan. Now, we move to the recommended phase and start generating reports. Those reports are "approved" as accurate because the test plan was "approved". Hopefully this helps. Looking at V2 of the proposal, this is the only place where I see a problem with how the model represents the process. I am inclined to suggest that there be a table called candidateReview with columns for:
Event could be enumeration including:
Note that if there are multiple reps, one might start the review and another could finish or approve. Any could raise issues. Vispero currently has two reps with access. This would allow for other types of events in the future. The URI could capture the URI of issues raised. |
* initial model, migration, and seeder * seeders test plan ids * test plan service * fixing migration * updating migrations to have foreign keys * Implementing Howard's feedback * Start to migrations and functions to support the DB change for further support of 648 * Update migrations and resolvers to update the individual test plan reports so they can be a part of the same testplanversion going through the candidate phase * Add phase to TestPlanVersion * Update resolver and logic for providing content on the reports page * Update query and resolvers for single report pages * Update query and resolvers for test plan version mutations * Support for CandidateTests functionality and returned other basic functionality which will be removed in the future such as individual test plan report updating * Restored viewing of CandidateTestPlanRun * Fix graphql.schema * Update migrations * Remove unused references * Update tests * Rename TestPlanVersion date fields with 'status' in name to 'phase' * Add approvedAt column to TestPlanReport * Rename candidateStatusReachedAt to approvedAt * Update migration to not use server specific function * Update migration to be more clear and help in functional priority of following migrations * Start draft of new Data Management page * Add links to single-page view of the plans * Update migration to prevent testPlanVersions not in the DRAFT phase having a draftPhaseReachedAt value * Update migration to prevent testPlanVersions not in the DRAFT phase having a draftPhaseReachedAt value and set the phase to RD if not * Update content of cells * Show remaining data content for the Data Management Row * Update the updatePhaseResolver * Added checks to account for how the phase promotions will be done * Making changes to account for using data from earlier runs when promoting a test plan version * Implementation of preserving data with earlier version of test plan when the runs for a target doesn't exist * Cleanup, comments and refactoring * Sunset earlier test plan version during phase update * Update TestManagement references to DataManagement * Update Test Plan, Covered At and Overall Status columns based on latest mockups * Implemented P0 styling items from latest mockups * Styling updates * Remove old version of test management content * Add proptypes check * Update Data Management page to allow access without being an admin * Hide admin actions on data management page * Adjust column sizes * Update tests * Update condition for when 'Advance to Recommended' button is shown * Restrict condition for phase transition * Editorial changes * Editorial changes * Cleanup TODOs * Address rare error condition * Add confirmation dialog when advancing test plan version; reduce values being requested * Unique test plan report combinations shown in advance confirmation dialog * Update test * Update tests * Update focus points when advancing phases * Update migration to make purpose clearer * Add validation for candidate phase * Set default sorting for data management table * Create /test-review endpoint for displaying what's available at aria-at.netlify in-app * Update Data Management VERSION_STRING link to point to template generated at /test-review * Fix sorting related bug with ManageTestQueue component * Remove required reports logic from updatePhaseResolver; needs to be moved to its own PR * Update test * Stop checks to see if testPlanReports exist which use an AT. Instead, show all currently known ats in this Covered ATs column * Reverse logic for showing the latest versions for a test plan * Re-evaluate sorting logic for DataManagement default phase sorting and applicable Test Plan Versions shown for ManageTestQueue component * Fix issue where latest version not being shown in row * Update mock data * Add note to docs * Move Candidate Phase Start Date and Target Completion Date into dedicated columns on Candidate Tests page (#730) * Move Candidate Phase Start Date and Target Completion Date into dedicated columns on Candidate Tests page * Change page title from Candidate Tests to Candidate Review * Update URL from '/candidate-tests' to `/candidate-review' * Rename relevant variables and components * Rename client/components/CandidateTests/ to client/components/CandidateReview * Add version string to candidate tests page (#729) * Start to revised Test Queue page * Do checks for isApproved testPlanReports * Removed 'Mark as ...' and 'Change Target Date' buttons from Candidate Test Plans * Update .status references * Update Sequelize model tests * Update embed.js to check for 'TestPlanVersion.phase' instead of 'TestPlanReport.status' * When setting to DRAFT, set the attached TestPlanReports approvedAt to null (this functionality may not be specified as yet but just in case) * Update Test Queue Run and Candidate Test Run to remove references to testPlanReport.status * Add visual detail when representing candidate phase start and completion dates * Show time to target date on Data Management Row * Added functionality for changing the recommended phase target date on data management page * Make recommended phase target date modal admin specific * Update tests * Update TestPlanReportService.test.js * Update TestPlanVersionService.test.js * Make 'can be finalized' test more predictable * Cleanup * Update migrations to support future migrations when migrating from this as the initial point * Update TestQueue/queries.js to only check for reports which don't have an approvedAt date * Addressing minor feedback comments * Cleanup * Update tests * Add checks when updating a TestPlanVersion phase which has no TestPlanReports which have been marked as final; also check if TestPlanVersions which do not have final reports aren't shown on /reports * Update tests * Re-use hashTests util * Partially address #723 * Address feedback comments * Update markAsFinalResolver.js to check if report can be finalized * Add check for conflicts when marking report as final * Rename approvedAt to markedFinalAt for consistency based on #632 comment * Update test * Add unmarkAsFinalResolver.js * Update CandidateReview after rebase * Resolve #740 * Remove unnecessary console.log * Cleanup files after merge --------- Co-authored-by: Erika Miguel <[email protected]> Co-authored-by: Paul Clue <[email protected]> Co-authored-by: alflennik <[email protected]> Co-authored-by: Stalgia Grigg <[email protected]>
* Start draft of new Data Management page * Add links to single-page view of the plans * Update migration to prevent testPlanVersions not in the DRAFT phase having a draftPhaseReachedAt value * Update migration to prevent testPlanVersions not in the DRAFT phase having a draftPhaseReachedAt value and set the phase to RD if not * Update content of cells * Show remaining data content for the Data Management Row * Update the updatePhaseResolver * Added checks to account for how the phase promotions will be done * Making changes to account for using data from earlier runs when promoting a test plan version * Implementation of preserving data with earlier version of test plan when the runs for a target doesn't exist * Cleanup, comments and refactoring * Sunset earlier test plan version during phase update * Update TestManagement references to DataManagement * Update Test Plan, Covered At and Overall Status columns based on latest mockups * Implemented P0 styling items from latest mockups * Styling updates * Remove old version of test management content * Add proptypes check * Update Data Management page to allow access without being an admin * Hide admin actions on data management page * Adjust column sizes * Update tests * Update condition for when 'Advance to Recommended' button is shown * Restrict condition for phase transition * Editorial changes * Editorial changes * Cleanup TODOs * Add confirmation dialog when advancing test plan version; reduce values being requested * Unique test plan report combinations shown in advance confirmation dialog * Update test * Update tests * Update focus points when advancing phases * Update migration to make purpose clearer * Add validation for candidate phase * Set default sorting for data management table * Create /test-review endpoint for displaying what's available at aria-at.netlify in-app * Update Data Management VERSION_STRING link to point to template generated at /test-review * Fix sorting related bug with ManageTestQueue component * Remove required reports logic from updatePhaseResolver; needs to be moved to its own PR * Update test * Stop checks to see if testPlanReports exist which use an AT. Instead, show all currently known ats in this Covered ATs column * Reverse logic for showing the latest versions for a test plan * Re-evaluate sorting logic for DataManagement default phase sorting and applicable Test Plan Versions shown for ManageTestQueue component * Fix issue where latest version not being shown in row * Update mock data * Add note to docs * Move Candidate Phase Start Date and Target Completion Date into dedicated columns on Candidate Tests page (#730) * Move Candidate Phase Start Date and Target Completion Date into dedicated columns on Candidate Tests page * Change page title from Candidate Tests to Candidate Review * Update URL from '/candidate-tests' to `/candidate-review' * Rename relevant variables and components * Rename client/components/CandidateTests/ to client/components/CandidateReview * Add version string to candidate tests page (#729) * Verify that the criteria for advancing the phase for test plans has been met by referencing required reports for a phase (#722) * initial model, migration, and seeder * seeders test plan ids * test plan service * fixing migration * updating migrations to have foreign keys * Implementing Howard's feedback * Start to migrations and functions to support the DB change for further support of 648 * Update migrations and resolvers to update the individual test plan reports so they can be a part of the same testplanversion going through the candidate phase * Add phase to TestPlanVersion * Update resolver and logic for providing content on the reports page * Update query and resolvers for single report pages * Update query and resolvers for test plan version mutations * Support for CandidateTests functionality and returned other basic functionality which will be removed in the future such as individual test plan report updating * Restored viewing of CandidateTestPlanRun * Fix graphql.schema * Update migrations * Remove unused references * Update tests * Rename TestPlanVersion date fields with 'status' in name to 'phase' * Add approvedAt column to TestPlanReport * Rename candidateStatusReachedAt to approvedAt * Update migration to not use server specific function * Update migration to be more clear and help in functional priority of following migrations * Start draft of new Data Management page * Add links to single-page view of the plans * Update migration to prevent testPlanVersions not in the DRAFT phase having a draftPhaseReachedAt value * Update migration to prevent testPlanVersions not in the DRAFT phase having a draftPhaseReachedAt value and set the phase to RD if not * Update content of cells * Show remaining data content for the Data Management Row * Update the updatePhaseResolver * Added checks to account for how the phase promotions will be done * Making changes to account for using data from earlier runs when promoting a test plan version * Implementation of preserving data with earlier version of test plan when the runs for a target doesn't exist * Cleanup, comments and refactoring * Sunset earlier test plan version during phase update * Update TestManagement references to DataManagement * Update Test Plan, Covered At and Overall Status columns based on latest mockups * Implemented P0 styling items from latest mockups * Styling updates * Remove old version of test management content * Add proptypes check * Update Data Management page to allow access without being an admin * Hide admin actions on data management page * Adjust column sizes * Update tests * Update condition for when 'Advance to Recommended' button is shown * Restrict condition for phase transition * Editorial changes * Editorial changes * Cleanup TODOs * Address rare error condition * Add confirmation dialog when advancing test plan version; reduce values being requested * Unique test plan report combinations shown in advance confirmation dialog * Update test * Update tests * Update focus points when advancing phases * Update migration to make purpose clearer * Add validation for candidate phase * Set default sorting for data management table * Add beginning of validation for Recomended phase * Create /test-review endpoint for displaying what's available at aria-at.netlify in-app * Update Data Management VERSION_STRING link to point to template generated at /test-review * Fix sorting related bug with ManageTestQueue component * Remove required reports logic from updatePhaseResolver; needs to be moved to its own PR * Update test * Stop checks to see if testPlanReports exist which use an AT. Instead, show all currently known ats in this Covered ATs column * Reverse logic for showing the latest versions for a test plan * Re-evaluate sorting logic for DataManagement default phase sorting and applicable Test Plan Versions shown for ManageTestQueue component * Finish verification for recommended phase * Fix failing tests except the datamanagement tests * Add beginning of validation for Recomended phase * Finish verification for recommended phase * Fix failing tests except the datamanagement tests * Update AtBrowsers and everything that has to do with it * Correcting merge conflict lines * Fix updatePhaseResolver * Fix failing tests * Remove comment * Fix function signiture --------- Co-authored-by: Erika Miguel <[email protected]> Co-authored-by: Howard Edwards <[email protected]> * Updated Test Queue and Candidate Tests Page (#715) * initial model, migration, and seeder * seeders test plan ids * test plan service * fixing migration * updating migrations to have foreign keys * Implementing Howard's feedback * Start to migrations and functions to support the DB change for further support of 648 * Update migrations and resolvers to update the individual test plan reports so they can be a part of the same testplanversion going through the candidate phase * Add phase to TestPlanVersion * Update resolver and logic for providing content on the reports page * Update query and resolvers for single report pages * Update query and resolvers for test plan version mutations * Support for CandidateTests functionality and returned other basic functionality which will be removed in the future such as individual test plan report updating * Restored viewing of CandidateTestPlanRun * Fix graphql.schema * Update migrations * Remove unused references * Update tests * Rename TestPlanVersion date fields with 'status' in name to 'phase' * Add approvedAt column to TestPlanReport * Rename candidateStatusReachedAt to approvedAt * Update migration to not use server specific function * Update migration to be more clear and help in functional priority of following migrations * Start draft of new Data Management page * Add links to single-page view of the plans * Update migration to prevent testPlanVersions not in the DRAFT phase having a draftPhaseReachedAt value * Update migration to prevent testPlanVersions not in the DRAFT phase having a draftPhaseReachedAt value and set the phase to RD if not * Update content of cells * Show remaining data content for the Data Management Row * Update the updatePhaseResolver * Added checks to account for how the phase promotions will be done * Making changes to account for using data from earlier runs when promoting a test plan version * Implementation of preserving data with earlier version of test plan when the runs for a target doesn't exist * Cleanup, comments and refactoring * Sunset earlier test plan version during phase update * Update TestManagement references to DataManagement * Update Test Plan, Covered At and Overall Status columns based on latest mockups * Implemented P0 styling items from latest mockups * Styling updates * Remove old version of test management content * Add proptypes check * Update Data Management page to allow access without being an admin * Hide admin actions on data management page * Adjust column sizes * Update tests * Update condition for when 'Advance to Recommended' button is shown * Restrict condition for phase transition * Editorial changes * Editorial changes * Cleanup TODOs * Address rare error condition * Add confirmation dialog when advancing test plan version; reduce values being requested * Unique test plan report combinations shown in advance confirmation dialog * Update test * Update tests * Update focus points when advancing phases * Update migration to make purpose clearer * Add validation for candidate phase * Set default sorting for data management table * Create /test-review endpoint for displaying what's available at aria-at.netlify in-app * Update Data Management VERSION_STRING link to point to template generated at /test-review * Fix sorting related bug with ManageTestQueue component * Remove required reports logic from updatePhaseResolver; needs to be moved to its own PR * Update test * Stop checks to see if testPlanReports exist which use an AT. Instead, show all currently known ats in this Covered ATs column * Reverse logic for showing the latest versions for a test plan * Re-evaluate sorting logic for DataManagement default phase sorting and applicable Test Plan Versions shown for ManageTestQueue component * Fix issue where latest version not being shown in row * Update mock data * Add note to docs * Move Candidate Phase Start Date and Target Completion Date into dedicated columns on Candidate Tests page (#730) * Move Candidate Phase Start Date and Target Completion Date into dedicated columns on Candidate Tests page * Change page title from Candidate Tests to Candidate Review * Update URL from '/candidate-tests' to `/candidate-review' * Rename relevant variables and components * Rename client/components/CandidateTests/ to client/components/CandidateReview * Add version string to candidate tests page (#729) * Start to revised Test Queue page * Do checks for isApproved testPlanReports * Removed 'Mark as ...' and 'Change Target Date' buttons from Candidate Test Plans * Update .status references * Update Sequelize model tests * Update embed.js to check for 'TestPlanVersion.phase' instead of 'TestPlanReport.status' * When setting to DRAFT, set the attached TestPlanReports approvedAt to null (this functionality may not be specified as yet but just in case) * Update Test Queue Run and Candidate Test Run to remove references to testPlanReport.status * Add visual detail when representing candidate phase start and completion dates * Show time to target date on Data Management Row * Added functionality for changing the recommended phase target date on data management page * Make recommended phase target date modal admin specific * Update tests * Update TestPlanReportService.test.js * Update TestPlanVersionService.test.js * Make 'can be finalized' test more predictable * Cleanup * Update migrations to support future migrations when migrating from this as the initial point * Update TestQueue/queries.js to only check for reports which don't have an approvedAt date * Addressing minor feedback comments * Cleanup * Update tests * Add checks when updating a TestPlanVersion phase which has no TestPlanReports which have been marked as final; also check if TestPlanVersions which do not have final reports aren't shown on /reports * Update tests * Re-use hashTests util * Partially address #723 * Address feedback comments * Update markAsFinalResolver.js to check if report can be finalized * Add check for conflicts when marking report as final * Rename approvedAt to markedFinalAt for consistency based on #632 comment * Update test * Add unmarkAsFinalResolver.js * Update CandidateReview after rebase * Resolve #740 * Remove unnecessary console.log * Cleanup files after merge --------- Co-authored-by: Erika Miguel <[email protected]> Co-authored-by: Paul Clue <[email protected]> Co-authored-by: alflennik <[email protected]> Co-authored-by: Stalgia Grigg <[email protected]> --------- Co-authored-by: Paul Clue <[email protected]> Co-authored-by: alflennik <[email protected]> Co-authored-by: Stalgia Grigg <[email protected]> Co-authored-by: Erika Miguel <[email protected]>
…abase Implementation to support #648 (#688) Changes added to primarily support #648, but also #518 and w3c/aria-at#950. This includes functional changes to the Data Management, the Test Queue and the Candidate Review pages. It also includes changes to the database structure, described in #632. * feature: updates functionality of Data Management page (#713) * feature: updates functionality of Test Queue page (#715) * feature: updates functionality of Candidate Review page (#715) * feature: include functionality to support the concept of required reports (#722) * feature: adds Test Plan Report Status dialog (#728) * enhancement: move Candidate Phase Start Date and Target Completion Date into dedicated columns on Candidate Review page (#730) * feature: adds Test Plan Version page (#747) * enhancement: explicitly support ‘DEPRECATED’ phase status for TestPlanVersions (#749) * feature: adds filter and sorting functionality by columns headers on Data Management page (#750) * bugfix: update semantic structure of cells with multiple list items on Data Management page (#752) * enhancement: include GitHub issues on Test Plan Version page (#753) * bugfix: revision of the required reports conditions for updating to CANDIDATE and RECOMMENDED phases (#764) * bugfix: removes superfluous header from Test Plan Report Status dialog (#766) * bugfix: update and revise sorts, headings and descriptions of elements on Test Plan Version page (#767) * bugfix: account for several other update phase scenarios that could prevent the update from happening if there is an older TestPlanVersion that exists with results (#771) * bugfix: update headings and revise deprecated dates shown on Test Plan Version page (#773) * enhancement: allow updating of GitHub issues being presented in the app to be more easily understood (#775) * bugfix: correct deprecatedAt date to be relative to when the ‘next’ TestPlanVersion was added (#780) * enhancement: update the text shown when deprecation occurs during a phase on Test Plan Version page (#781) * bugfix: fix inverted sort descriptions and pin sort of of Test Plan name columns on Data Management page (#790) --------- Co-authored-by: Erika Miguel <[email protected]> Co-authored-by: Paul Clue <[email protected]> Co-authored-by: alflennik <[email protected]> Co-authored-by: Stalgia Grigg <[email protected]> Co-authored-by: Howard Edwards <[email protected]>
There appears to be a need to augment the database's structure slightly, to better support what's being discussed in #518. Particularly around the proposed
Test (now Data) Managementpage and its related features, once approved.2 pages have been drafted to describe the current state of the database and the proposed changes:
I'd like to particularly raise focus on some questions posed under the first point of the Notes and Questions section of the proposal doc as they could assist with the final design proposed.
Edit on Jul 11, 2023: Added updated proposal doc.
The text was updated successfully, but these errors were encountered: