Dashboard Title Slug does not support the mix of English and Chinese in 9.4.1

[alexandnpu]

What happened:
When I create a dashboard with one title consisting both English and Chinese，the dashboard slug after creation will ignore the Chinese part. This prevents making the second dashboard with the same English prefix.

e.g.
the first dashboard title is "aws测试", the second dashboard title is "aws生产".
The first dashboard will be created with no error, while the second one will cause a dashboard conflict warning.

What you expected to happen:
The second dashboard will be created with no error or warning.

I went through the code, and found the slug change
and this PR.

It seems that the slug change causes this unexpected behavior.

I did a test in TestSlugifyTitle, which is my input and expected result.

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• Grafana version: 9.4.1
• Data source type & version:
• OS Grafana is installed on: centos7
• User OS & Browser:
• Grafana plugins:
• Others:

[tonypowa]

thank you for creating this issue @alexandnpu

I am forwarding it to the dataviz squad for review ( PR was assigned to this squad)

[alexandnpu]

@tonypowa , thanks a lot! Will updates be put here?

[tonypowa]

@alexandnpu

yes, the team will review this issue, and inform you on the next steps
👍

[skyhotqin]

@alexandnpu

@tonypowa , thanks a lot! Will updates be put here?

I'm also in this trouble, how did you deal with this bug? have any solutions?
otherwise, I think this code will help to deal with it.

[alexandnpu]

@alexandnpu

@tonypowa , thanks a lot! Will updates be put here?

I'm also in this trouble, how did you deal with this bug? have any solutions? otherwise, I think this code will help to deal with it.

for users, I have no workaround right now. The suggestion for users is to avoid using the mixture of Chinese and English, use all Chinese instead.

I am still waiting for the fix of grafana team.

[Joey777210]

Same issue

[baosenle]

Same issue

[yatt]

I've encountered the similar issue in Japanese: importing the dashboard overwrite the existing one.

In the older version of Grafana, based on the migration data I examined, even when Japanese was used, Romaji and Chinese Pinyin was assigned, which functioned as a unique ID, at least.
For example, there was a dashboard titled 'システム監視(Prometheus)' in Japanese, and it had the slug 'shisutemujian-shi-prometheus' assigned to it.

As a workaround, I directly updated the slug value in the database record, allowing me to successfully import the dashboard.
I'm not sure about any other potential impacts caused by this.

$ sqlite3 grafana.db
sqlite> select id, title, slug from dashboard order by title;
...
94|PostgreSQL関係の統計値|postgresql
...
sqlite> update dashboard set slug = 'postgresql-related-stats' where id=94;

Environment:

Grafana version: 10.0.1
Data source type & version:
OS Grafana is installed on: Windows10 Pro
User OS & Browser:
Grafana plugins:
Others:

[sakjur]

@yatt 🙏 Thank you for bringing that up too, we've tracked down that issue to a function using the slug rather than title to look for whether the dashboard already exists when updating it. That should be fixed by #70723.

I'll try to summarize a little bit of what's been happening with the slugs (mostly for developers working on permutations of this issue, but also for anyone interested):

• Slugs originally had a much more prominent role, Grafana v5.0.0 changed that with the introduction of folders, and suddenly the folder+dashboard title combination was the important unique index backend for new url structure. #10694.
• Slugify: Replace gosimple/slug with a simple function  #59517 removed the slug library that we've been using for a very long time. A number of semi-hidden (and incorrect, particularly after the v5.0.0 change) assumptions about slugs broke at the time. I'd categorize the broken assumptions I know of as of today as:
  1. Slug generation do not change for a given dashboard title (even if we'd stuck with the library, being able to change how slug generation is done would be a reasonable thing).
  2. Slugs either consists of the URL safe latin (a-z) or non-latin characters, not a combination of both.
  3. Slugs can be used to uniquely identify a dashboard.
• When we discovered what Slugify: Replace gosimple/slug with a simple function  #59517 had broken, changing it back would trigger the some of the same issues for our users. The hanzi to pinyin transliteration would start working again, so that'd be an improvement, but we'd risk running into other problems where the first and third assumption listed above are in effect.
• Dashboards: Evaluate provisioned dashboard titles in a backwards compatible way #65184 changed provisioning to stop assuming that a slug can be used to uniquely identify a dashboard and instead uses the folder/title combination. The first and third assumption are removed for provisioning at this point.
• Fix: Change getExistingDashboardByTitleAndFolder to get dashboard by title, not slug #70723 fixes another instance of assumptions 1+3 being made, this time related to updating dashboards using the API when no ID or UID is given.
• Slug: Use urlencoding to support non-ASCII characters #70691 is approaching the second assumption and allows generation of slugs when the characters are mixed URL safe and non-URL safe characters.

(cc @yangkb09 @zserge)