Embedding Dashboard with Locked parameters does not allow numeric values

[nemanjaglumac]

Describe the bug
This is the repetition of #20845, but for the dashboard scenario.

To Reproduce
Steps to reproduce the behavior:

1. Native Question > Sample > select count(*) from orders where true [[AND quantity={{qty_locked}}]] - set variable as Number
2. Add question to dashboard
3. Add filter to the dashboard (Number > Equal to) and connect it to the card/question on qty_locked
   
4. Save the dashboard
5. Enable embedding and set the dashboard filter "Equal to" to locked

Note
From this point on it is not possible to reproduce this issue merely using the UI. You have to generate the JWT token with the numeric value. Frontend is passing a string, even though the filter is numeric.

{
  resource: { dashboard: dashboard_id },
  params: {
    equal_to: 15 // IMPORTANT: integer
  },
}

If we now visit the embedded dashboard URL, it will error with "There was a problem displaying this chart":

As with the previous issue, backend error is not helpful, either:
Don't know how to create ISeq from: java.lang.Integer

Expected behavior
Allow numeric parameters.
While we're at it, would be nice if we allowed the resource as string, since I see that as a common mistake as well.

Information about your Metabase Installation:
local dev, master, 9335035, H2, Sample Database

[flamber]

While we're at it, let's make sure that we allow resources to be strings too.
The logic is currently that resources has to be numeric, while the params has to be string, which seems off.

resource: { dashboard: 123 }, //works
resource: { dashboard: "123" }, //fails

[nemanjaglumac]

While we're at it, let's make sure that we allow resources to be strings too. The logic is currently that resources has to be numeric, while the params has to be string, which seems off.

resource: { dashboard: 123 }, //works
resource: { dashboard: "123" }, //fails

Yeah, added that to the "Expected behavior", or rather copied it over from your original issue.
The repro is checking for both strings and integers.

[laura-radaelli]

Hi guys, thanks for adding this issue, I will follow the progress. I am not sure whether it is useful, but I wanted to add another 2 scenarios where this happens for me:

scenario 1:
1.-4. same as you described
5. Enable embedding and set the dashboard filter to editable

scenario 2:

1. Query builder > from a table that has a Numeric field
2. -5. same as you described

Both of those lead me to the same "There was a problem displaying this chart" and same backend error.

[dpsutton]

While we're at it, let's make sure that we allow resources to be strings too. The logic is currently that resources has to be numeric, while the params has to be string, which seems off.

   resource: { dashboard: 123 }, //works
   resource: { dashboard: "123" }, //fails

I'm not sure I follow what's going on here and why we would expect string ids to work? Dashboards have numeric ids (eg. 123). I don't see why we would expect a string key to work here. It seems like we should be more careful with what values we put into tokens and the expectations when we take it from the jwt, not that we should loosen our parsing.