feat: Drop old inaccuracy reports, add new feedback category

[DafyddLlyr]

What does this PR do?

• Context - https://opensystemslab.slack.com/archives/C5Q59R3HB/p1708018023353589 (OSL Slack)
• Drop old FeedbackInput component
• Add new feedback_types enum value inaccuracy
• Add additional "Inaccuracy" option when gathering feedback

What's not in the PR?

• Even though it could no longer be populated, I'm not touching the BOPS payload generation to strip this out - this will just be taken out wholesale shortly
• Tests (sorry)! There's a task on https://trello.com/c/8pmX6wmZ/2545-design-implement-in-house-feedback-feature-retire-feedback-fish to set these up so I've slightly sidestepped this for now as I'm not sure of it's current status. Very happy to add them for new component if there's another PR in the works! 👍

Next steps

If approved, I'll update the testing notes for the feedback tool once merged.

[DafyddLlyr]

We could conditionally display this if the node type matches the previous places we used to show this option, but that seems a little inconsistent for users potentially? I've opted against it here to very much open to thoughts.

[jessicamcinchak]

I think this is right - easy to imagine someone wanting to report "inaccurate" help text, etc 👍

[DafyddLlyr]

Yep - agreed!

[Mike-Heneghan]

I think that's a very good point about the consistency although I think 4 options is quite a lot to choose from and maybe makes it a little overwhelming for users?

Rather than rendering it conditionally in the triage the "Report an inaccuracy" could potentially be directly opened the same way that "Report an issue with this page" does?

So rather than select "feedback" link in the footer text they see the "inaccuracy" link and it renders this form? I don't think it would be too jarring as it's the same style and it would also scope inaccuracy reports to the places we were recording it before?

[DafyddLlyr]

Hey sorry for the very slow response here! Kept on de-prioritising this one.

I think in this instance I'm in favour of keeping the fourth option everywhere, over conditionally showing a form in certain places.

The main motivation behind this is that we can't necessarily know which places may contain inaccurate data.

I'll make sure though that this issue is explicitly raised at PO testing just so we have another pair of eyes on this.

[DafyddLlyr]

Integrate the "Report an inaccuracy" type feedback into new feedback tool

[github-actions]

Removed vultr server and associated DNS entries

[Mike-Heneghan]

Quick comment about a potential wee UI trap.

[Mike-Heneghan]

I think that's a very good point about the consistency although I think 4 options is quite a lot to choose from and maybe makes it a little overwhelming for users?

Rather than rendering it conditionally in the triage the "Report an inaccuracy" could potentially be directly opened the same way that "Report an issue with this page" does?

So rather than select "feedback" link in the footer text they see the "inaccuracy" link and it renders this form? I don't think it would be too jarring as it's the same style and it would also scope inaccuracy reports to the places we were recording it before?

[Mike-Heneghan]

I just noticed that on a successful submit of an inaccuracy report the UI doesn't update to the "thanks for feedback"

Update: I just realised there was an error rather than the submit being successful:

{
    "errors": [
        {
            "message": "expected one of the values ['comment', 'helpful', 'idea', 'issue', 'unhelpful'] for type 'feedback_type_enum_enum', but found 'inaccuracy'",
            "extensions": {
                "path": "$.selectionSet.insert_feedback.args.objects[0].feedback_type",
                "code": "validation-failed"
            }
        }
    ]
}

I have the migration to add the new type but maybe something is out of sync, I'll test again on the pizza rather than locally.

Screen.Recording.2024-03-27.at.11.27.25.mov

[DafyddLlyr]

Thanks @Mike-Heneghan - taking a look just now!

[Mike-Heneghan]

nit:

It would be ace to get some tests for the new option if you have the chance.

[DafyddLlyr]

Good spot thanks! See 76040f8

I think this was initially missed as there was a ticket for tests still in "To do this sprint" when I opened the PR 😅

[Mike-Heneghan]

Ahahahaha yeah it did take me a while to get the testing setup 😅

It would also be good to get an accompanying accessibility test along the lines of

  test("Inaccuracy form should have no accessibility violations", async () => {
    const { container, getByText, getByRole, user } = setup(<Feedback />);

    await user.click(getByText("feedback"));

    await waitFor(() => {
      expect(getByRole("button", { name: "Inaccuracy" })).toBeInTheDocument();
    });

    await user.click(getByRole("button", { name: "Inaccuracy" }));

    await waitFor(() => {
      expect(getByText("Report an inaccuracy")).toBeInTheDocument();
    });

    const results = await axe(container);
    expect(results).toHaveNoViolations();
  });

Not that these tests have been particularly useful when it came to the accessibility report 😓

[DafyddLlyr]

I just noticed that on a successful submit of an inaccuracy report the UI doesn't update to the "thanks for feedback"

Screen.Recording.2024-03-27.at.11.27.25.mov

I can't recreate this locally or on the Pizza. Which environment was this recording taken in?

[Mike-Heneghan]

Thanks @Mike-Heneghan - taking a look just now!

I just retested on the pizza and it was a local issue for me. Sorry for the false alarm!

I ran the migration in the CLI but I think that wasn't picked up by Hasura for the mutation.

When I reloaded the metadata for feedback_type_enum in Hasura the error was resolved 🥳

[Mike-Heneghan]

Looks good 👍