[Widget Params] Title edit fixes

[ranbena]

Some improvements to UI and fixes to functionality after feedback from @susodapop on #3332.

Changes

1. Limited title editing to 100 chars (arbitrary, lmk if should change)
2. Static value title editing disabled and a "hidden" icon appears with an explanation in tooltip.
3. The same for a mapped dashboard param, with a "link" icon.

[ranbena]

This is how a dashboard source is determined.

[ranbena]

Not ideal. @kravets-levko lmk if there's an alternative.

[kravets-levko]

Looks good, except of two things:

1. using Symbol API (see my comment) - please check and fix if needed;
2. side effect - but I also see no better way to implement this, so let's proceed with this.

[ranbena]

@kravets-levko did the required changes 👍

I do want to point out that there is one unexpected behavior that makes sense with how parameters work.

Title hijacking:

1. Add widgets w1 and then w2 to dashboard.
2. Both define their own dashboard params p_w1 and p_w2.
3. Set unique titles to each param .
4. Change p_w1 to point to p_w2.
5. p_w2 now has p_w1's title 😵

This happens cause dashboard params are determined according to chronological order and since w1 came before w2 - it became the source of p_w2.

I don't think this is a big deal as long as users can still re-edit the name.

Fixed

[kravets-levko]

Let it rock 🤘

[arikfr]

@ranbena ,
Sorry for joining late, but what I failed to understand is why the user can't edit the title when mapping to existing parameter? How exactly are they supposed to edit it? Hunt down the original one?

[ranbena]

Hunt down the original one?

Yes, it's not good UX, but it's better than the previous behavior which allowed editing but would "work" only if you were on the dashboard source. This is more of a fix than a feature.
From discussions with @kravets-levko, I understood that this limitation has to do with the virtual nature of the dashboard params.

[arikfr]

Why aren't we letting the user update it as they would expect, and just update the needed object ourselves?

[arikfr]

If we know that the current widget isn't the owner, it means we know which one is, right?

[ranbena]

If we know that the current widget isn't the owner, it means we know which one is, right?

Afraid not. That was my go to. But it's not built for that.

[kravets-levko]

@arikfr (cc @ranbena) It's possible to do this, if widget has access to other widgets on the same dashboard. We had a discussion with Ran, and we both stuck with ideas. But while reading you comment I realized that actually we have access to dashboard from widget! Not from model instance, but in a component - yes, and it's even passed to Edit Mapping dialog:

redash/client/app/components/dashboards/widget.js

Lines 81 to 85 in 23f5dde

	this.editParameterMappings = () => {
	EditParameterMappingsDialog.showModal({
	dashboard: this.dashboard,
	widget: this.widget,
	}).result.then(() => {

I missed this - my bad 😖 But how @ranbena could miss that working on that dialog - it's a mystery 😅

[kravets-levko]

@ranbena The idea is that having all widgets, you can find ones that are mapped to the same dashboard parameter, take corresponding mapping and update it's title when editing it. And save all widgets where parameter mapping title changed (yes, dirty check will be really important here).

[ranbena]

@kravets-levko It's not the reference to the dashboard that I was missing - it was a clear indication of which widget holds the parameter source. Also, I preferred not to alter the functionality so as not to risk breakage of code indicated as delicate.

[arikfr]

@kravets-levko does the dashboard hold any information about parameters or it's all derived in runtime from widgets?

[kravets-levko]

@arikfr - it's all derived in runtime from widgets

When we discussed that with @ranbena, we both concluded that there are two ways to implement this:

1. allow to edit only title of "origin" widgets parameter;
2. when editing title - update all widgets mapped to that parameter.

While #2 is a bit better from UX point, we decided that it's easier to implement #1. From my side, I was thinking that we don't have access to a dashboard in that dialog, and didn't want to add it (I'm trying to remember what was in my mind at that time, but cant 🤔). Also, #1 was much better in terms of making it working right. At the end, @ranbena implemented a good UI - if I were a user I would use it without any issues.

[kravets-levko]

@arikfr FYI #3417