Trust_level default name?

[piffy]

I notice when I go to the flair dropdown, the default “trust_level_x” name is shown.

I understand how to override text and I’ve done so here :

Which is correctly applied here, on the groups page

Am I missing another text field to override?

[not-ethan (Ethan)]

I guess that the flairs are on the automatic trust_level_x groups. If so the flair name will be of the name of the group.

[piffy]

trust_level_0 shows up correctly as “Rookie”. Maybe I changed another setting for that group without realizing it. But assuming I didn’t, the behavior here seems inconsistent between the default groups

[piffy]

This still seems to be persistent. Any solutions?

[JammyDodger]

I’ve just had a quick go myself, and changed trust_level_0 to ‘Derek’. However, on the Groups page I notice it is still nestled in with trust_level_1, etc in alphabetical order which suggests that the name hasn’t changed, only the full name. It doesn’t appear that the name can be changed from the Group settings page in the same way as manually created groups.

I’ll have a search based on this, but it may be that this cannot be changed without breaking underlying things.

Hmm, but you did Trust_level_0 yourself. I’ll add that into the mix.

---

@piffy I can’t find anything so far in Search, nor through the UI. Before I dive deeper, I should check if you did ‘Rookie’ by using the rails console?

Extra info:

This topic seems to have achieved inconsistent results too:

Add Support for Handling Spaces in Custom-Named Trust Levels in Their Group Slugs

Hello again! First off, I want to say thank you to the Discourse team for a fantastic job improving the consistency of slug names versus full names in group titles. Now, I am experiencing a weird issue when attempting to replace the trust level names in my Discourse forum. I replaced all the names to the relevant titles in Jedi vernacular (Nerf herder, Youngling, Padawan, Jedi Knight, Jedi Master). (Well, almost all of the titles are relevant: we expect a lot of scruffy-looking, uncivilized smu…

I tried Rookie, and Padawan bit mine don’t change successfully. I wonder what I’m missing?

[piffy]

@JammyDodger

Before I dive deeper, I should check if you did ‘Rookie’ by using the rails console?

I can’t guarantee that I didn’t do that but I have no recollection of changing it from the console.

My forum was imported through a custom script. Maybe that’s a potential explanation? But I don’t believe I specified the name Rookie anywhere but the website UI

[JammyDodger]

Okay, I have had some luck. If I change a trust_level group name and then go to /sidekiq and run Jobs::EnsureDbConsistency that changes the slug for me.

I will continue testing it out to see if I can do it consistently.

---

Update:

I can do this consistently. And the new slugs show up in the Flair menu:

Does this work for you too? My initial confusion was obviously based on impatience. I think if I had left my changes in place until that sidekiq job had run as part of its regular schedule then it would have all happened automagically…

[piffy]

I really appreciate the thorough experimentation! Ill be sure to test this out on my site and let you know if it works

[piffy]

Sorry for the delayed response. It does not seem to have worked.

The problem is similar to the one mentioned here:

Add Support for Handling Spaces in Custom-Named Trust Levels in Their Group Slugs

Want to also tag @laurent.c because he reported a version of the same problem in: In reference to: Usernames and groupnames don’t support spaces, so you would have to use an underscore in its place (like the default ones): I make that change and the slug does not change: [image] It also will not change if I use a single word, which was successful for @Hifihedgehog.

The URL slug remains “trust_level_1”

For me, this issue is limited to trust level 1 and 2, the others seem fine. I tried resetting the name back to “trust_level_1” and back to Trainer with no success. Running Jobs::EnsureDbConsistency does seem to trigger the update on the actual group name but it does not change the slug name for me or the name in the dropdown.

[JammyDodger]

That’s interesting. I’ve been using this to consistently shuffle mine back and forth between all manner of names. I think the only one it struggled with was ‘modérateurs’ when I didn’t have unicode usernames enabled. Perhaps there’s another piece I’m missing.

Are these names being used anywhere else on your site? Pre-existing usernames, etc. Anything that could cause a conflict which the sidkiq job would gracefully ignore so as not to bork anything up?

[piffy]

@JammyDodger

Are these names being used anywhere else on your site? Deleted groups, etc. Anything that could cause a conflict which the sidkiq job would gracefully ignore so as not to bork anything up?

AHHA! I found the solution based on what you said here. It looks like there are users with the same username as the group name! Changing their names and running the sidekiq job fixes it.

Thanks so much. This was such a minor thing but it was bothering me for months now

[JammyDodger]

Hooray! I’ve given the solution post a little tweak to make me sound smarter contain the more useful example.

[Sherran]

Hi Jammy, I have the same problem and I don’t understand “go to /sidekiq and run Jobs::EnsureDbConsistency”.

What exactly shall I do? Thanks!

[JammyDodger]

Sidekiq is where you find all the background jobs that work their magic backstage. They normally all work on a schedule, but can be hurried-up by triggering them manually.

If you add /sidekiq/scheduler to the end of your site address (ie [YourSite]/sidekiq/scheduler) you should see a list of all the scheduled jobs.

There’s one in there called Jobs::EnsureDbConsistency which you can run early to speed up the changes to your default group names.

Instead of scrolling down looking for it, you can also use Ctrl+F or ‘Find in page’, etc and search for something like ‘ensure’ to find it quicker (I think there are only two jobs with ensure in, so it narrows it down a fair bit )

[Sherran]

Thanks! Have triggered the item and it works fine.