Just a heads up. I hope those duplication instructions are sufficient - this is a very weird one.

Also having this issue on our install on all projects with characters like (, ), and *

Solution was to change them in the database, changing in UI didn't seem to save but threw no errors

• D15045 fixes the problem with "Additional Hashtags" getting smushed.
• D15048 fixes a problem where removing old, invalid "Additional Hashtags" could fail.
• D15047 should fix old hashtags 404'ing.

On Oct 12, we made the rules around hashtag generation more strict (see T9551 for discussion). In particular, Projects previously readily generated hashtags which were not usable in URIs, remarkup, and/or arc diff text. After Oct 12, projects no longer generate these hashtags.

However, they continued to work in some contexts until Dec 27 (D14888), which made querying stricter as well, as a side effect of centralizing query code.

D15047 relaxes the change made by D14888, so these hashtags should continue to work.

I mistakenly believed very few projects were affected by T9551 and that they almost all were broken anyway (e.g., projects with commas in their names, which would never have worked in Reviewers:), and failed to anticipate the impact of the change made by D14888. Although I'd still like installs to eventually move away from hashtags full of characters like ,*[], etc., I'll provide a more gradual pathway forward in the future.

I believe things should be back to normal at HEAD, after D15047.

In an attempt to fix it, I renamed the project to BSS and back to BSS [Team], and now clicking the tag goes to the equally invalid URL https://XXX/tag/bss_team/.
Solution was to change them in the database, changing in UI didn't seem to save but threw no errors

I think I can't reproduce either of these issues. When I make changes to project names, they are reflected in the UI and the new (valid, reduced-character-range) hashtags work properly.

When I rename a project to x, then to x [y], it generates the (fully functional) slug x_y which works correctly. Since Oct 12, it is expected that the natural hashtag for a project named x [y] is x_y.

(I can reproduce deletions of now-invalid "Additional Hashtags" not taking effect, but D15048 should resolve that.)

I don't mind DCing use of [] in the title, if that's what you were saying we should do...forgive me if I misunderstood. If so, I need something to use as a replacement. We have projects that are Teams, Projects, Departments, and Groups, all which need to be easily queried, and all of which need to be obvious where they belong. Right now, I'm saying "IMF [Team]", "PawLIB [Project]", and so forth. Just saying "IMF Team" or "PawLIB Project" looks entirely too messy and disorganized for our use.

I know I'm not the only person thinking along those lines. If we don't use punctuation symbols in titles, what do you propose we use for separators in that use case?

By the way, I'm more than pleased to never have punctuation in a hashtag, aside from _. I hated the auto-generated hashtags off of those titles anyway.

Once again, if you're not saying we should DC use in project names, then nevermind this whole question. :)

To clarify, you can put anything you want in a project name. Only hashtags have character restrictions. ??? Whales! ??? ~(BIG WHALES)~ is a completely legitimate project name, and will be forever.

Was that unclear, or do you find the new hashtag rules too restrictive?

Parens?

Ah, I just edited because I realized the difference b/w hashtag and title. I don't like punctuation in hashtags anyway, so all's well. :)

Just a heads up, this looks to be resolved. I've changed all the projects to only have future-valid hashtags, which usually involves my renaming the project to remove the [ ], and then, renaming it back, thereby forcing the automatic hashtag to regenerate properly.

All the same, looks great!