Provide stable URL for referencing dashboards

[eradman]

What type of PR is this?

• [x] Feature

Description

Dashboards may be referenced if their ID is known (/dashboards/{dashboard_id}-{slug}), but there was no easy method of linking one dashboard to another by name.

The route /dashboard/{slug} already exists, but was useless because the exact slug ID had to be supplied (slug, slug_1, slug_2, ...). This change improves this routes by finding the best match.

This enables dashboar

How is this tested?

• [x] Unit tests (pytest, jest)
• [x] Manually

Create several dashboards with the same name, archive the first and test redirects using /dashboard/{slug}

Example Use Case

[codecov[bot]]

Codecov Report

Merging #6490 (136adbf) into master (4a36abc) will increase coverage by 0.00%. Report is 1 commits behind head on master. The diff coverage is 100.00%.

@@           Coverage Diff           @@
##           master    #6490   +/-   ##
=======================================
  Coverage   61.08%   61.08%           
=======================================
  Files         158      158           
  Lines       12878    12879    +1     
  Branches     1753     1753           
=======================================
+ Hits         7866     7867    +1     
  Misses       4766     4766           
  Partials      246      246           

Files	Coverage Δ
redash/models/__init__.py	92.26% <100.00%> (+<0.01%)	:arrow_up:

[justinclift]

Cool, this looks useful. :smile:

@getredash/maintainers Anyone up for reviewing this? It's fairly simple Python backend code.

[eradman]

I see, so I took a route that exists but was supposed to be deprecated.

Slugs are named sequentially, in the order they were created, so it is difficult to reference them by exact name

redash=# select slug from dashboards order by slug;
...
 extension-analytics
 extension-analytics_1
 extension-analytics_2

This makes the legacy /dashboard/ route is useless because you cannot guess the exact slug name. Should we remove the legacy route and add a new one?

/dashboards/find/{slug}

[arikfr]

@eradman but why do you want to load them by slug and not id?

[eradman]

For context, my general workflow is this:

1. create a dashboard on a dev environtment
2. export the dashboard (add json defenition + sql files to git)
3. publish dashboard to S3
4. user installs dashboard from HTTP location

If there is a single instance of Redash then the dashboard ID can be hard coded, but this is never the case in the evironments I work in since I don't have access to our customer sites.

I don't even have access to the Redash instances that my colleges are using, so there is no case where a hard-coded ID would work.

[justinclift]

Interesting. That sounds like a pretty reasonable scenario @eradman. :smile:

[eradman]

@arikfr do you think it would be better to add a new route (redirect) to find a dashboard by name, or is it okay to repurpose the legacy route/dashboard/{slug}?

[arikfr]

It's probably better to add a more explicit route, just to make things less confusing. Also, maybe we add the option to set the slug via the API (along with the lookup by slug) so things are more predictable and stable?

[eradman]

Dashboard slugs are strange because the exact name is not determanistic:

def generate_slug(ctx):
    slug = utils.slugify(ctx.current_parameters["name"])
    tries = 1
    while Dashboard.query.filter(Dashboard.slug == slug).first() is not None:
        slug = utils.slugify(ctx.current_parameters["name"]) + "_" + str(tries)
        tries += 1
    return slug

Some ideas

1. Allow the user to define a custom slug
2. Add a redirect-route for searching by dashboard name
3. Erase slug when a dashboard is archived and make the slug unique

[guidopetri]

I'd find the dashboards-by-slug stuff useful. I'd be in favor of making slugs unique period - I don't think we should delete them when archived, since if someone archives dashboard 1, then creates an identically-slugged dashboard 2, and unarchives dashboard 1, we'd have a conflict. I can't really think of a use case where you'd want two identically-named dashboards.

That way, we can also provide the stable URL for referencing dashboards, as well, which is more useful than by ID imo.

[guidopetri]

#4932 seems like an issue that wants a similar outcome, but for queries.

[eradman]

Closing because this change is too narrow: we need a generic way of linking to dashboards and queries, and visualizations by name.