Hi, I would like to be learned how to use staff tags…
As an admin, I created staff tag:
Then I tried to create another tag with the similar name and it does not show me matches:
Next, I created a tag community, then go to the main page, refresh it and open composer. There is no community tag in the field tag until it was used at least once:
Questions:
It allows me to set name with a space which is not allowed in composer. Should be the same behavior, isn’t it? Discourse automatically replaced space into minus, but did not do that on admin page.
What tags are matched during tag creation? Why I don’t see any variants?
As a staff (I use the same user, both admin and moderator), I cannot see just created tag until it was used at least once?
I can repro this. The staff tags site setting does allow spaces. The composer also allows tags with spaces, but automatically replaces spaces with - on topic creation. However, if help wanted is added to staff tags, users can create a topic with help-wanted as the tag, just not help wanted. These seem to be bugs with the tag chooser, not staff tags itself cc @joffreyjaffeux
Not sure what is being asked here…
Correct - that is the standard behavior of tags. They don’t appear until they are used.
Sorry for poor explain. This is a misunderstanding point. For instance, as moderator, I have to exactly know the name of new tag created by admins, if that tag haven’t used yet. Example: admin told that they created a new staff tag ‘sun-of-the-beach’. Moderator could recognize it as ‘son-of-the-b#$@h’. If moderator will make a typo in staff tag, which not used yet, that tag will be created as new public tag.
Your example is correct. Until the tag is used on a topic (could be a topic in #staff that no one can see) it will not appear in the tag chooser dropdown. Also, keep in mind that staff tags aren’t “hidden”, anyone can see them, it’s just their usage that is restricted to staff. If your goal is to hide tags, see Set tags as private.
Yeah, I feel the difference between hidden and staff tags, it is ok. I don’t need to hide tags. I just claimed that it is rather difficult to use new tags. When my team implemented Discourse in our community, I created empty staff topic with all tags, so that everybody can see available tags in composer.
@jomaxro ok I will need some details here. Because AFAIK, it has always been working this way. Site settings fields are basic input list and don’t make ajax calls, so technically “staff tags” is not a tag chooser but a “list-setting” and as such can’t query for matching tags. So you have to manually remember the name of the tags you want to add and do it. Agreed it’s not perfect, but it would require changes to how inputs for site settings work.
It’s not clear what kind of search it does. Having tag help wanted, I expect that matching helper will assist in creation of similar tags. I type help but it actually does not search matches. That was the question №2 from the topic.
Looking at composer, it makes some search after clicking tag field, perhaps it is a query for available tags which are cut by setting max tags in filter list:
I’m not saying it’s perfect. I’m saying I think it has always been this way, and I can’t fix it very easily. So basically I’m saying I don’t think it’s a bug nor a regression, not, that we shouldn’t improve it.
Sorry for the lack of details. Understanding that site settings don’t make ajax calls, I called it a bug becuase the site setting allows “invalid” input. I don’t expect site settings to query the existing set of tags, simply to not allow invalid characters to be saved in tags like spaces.
I agree that this is how it always worked, and I’m not suggested that this be changed.
With that in mind, can “search” be easily suppressed? Given that it is an list setting with no choices, and isn’t querying anything, ideally we should just hide “No matches found”.
I moved “staff tags” to the tag group settings today. Your staff tags have been moved into a new group called… “staff tags” with the equivalent permissions. The tags input field will now know which tags already exist, and allows you to create new tags for future use.
Nice work, Neil. Before I update, can you confirm that basically any tag group can be configured to be a staff tag group? I already have a handful for handling tickets, eg ticket priority and status. These I want to continue using in the same way if possible.
Will they be moved into a new staff tags group like in your screenshot and I can just set them up again according to my needs?
Yes all existing tag groups will be migrated to have the same permissions that they currently have. Also any group can choose the option “Tags are visible to everyone, but only staff can use them”.
Nothing in a tag group will be moved. Only the staff tags list will be moved into a new tag group.
Thanks Neil. Not sure about this part though. I have staff tags that are already in tag groups. Will it be possible for them to stay there and be visible and useable only by staff?
I will try the update and see what happens, so I can understand it better.
This is all looking great, thanks. I deleted the new tag group for staff tags created with the update because I already had one. Weirdly, there were two tag groups containing the same tags, with different rules. I think I am in good shape now and will keep an eye on it.
