Fix regex pattern for character conversion

[mabezi]

Related Issue

#1404

New Behavior

Correct replacement of dashes and dots in slugs.

Contrast to Current Behavior

Incorrect replacement leads to errors when using slugs with multiple consecutive dashes.

Discussion: Benefits and Drawbacks

This would make it possible to use tags like customer--123 without errors.
There are also open source projects (e.g. Yaook) that frequently use multiple consecutive dashes in Netbox tags (yaook--default-gateway).

At this point, however, I would like to question why dashes are replaced in slugs at all, since dashes are valid characters in slugs.

Changes to the Documentation

not needed

Proposed Release Note Entry

Fixed regex pattern for character conversion when using slug parameter in multiple modules

Double Check

• I have read the comments and followed the CONTRIBUTING.md.
• I have explained my PR according to the information in the comments or in a linked issue.
• My PR targets the devel branch.

[sc68cal]

At this point, however, I would like to question why dashes are replaced in slugs at all, since dashes are valid characters in slugs.

So, it may be that the issue of Ansible disallowing hyphens for group names, may have accidentally been applied to slugs as well. I agree, the documentation for slug fields explicitly permits hyphens.

So really, I have to wonder what exactly this was trying to prevent? Was it meant to just protect people from adding too many hyphens? I wonder if we shouldn't just remove this part completely?

Should it just be

        return re.sub(r"[^\-\.\w\s]", "", value)

?

[mabezi]

Are you sure that this would cover all valid cases?

I hadn't thought about it before, but the regex allows periods, which should actually be prohibited.
It also doesn't accept underscores, which are definitely allowed.

A slug is a short label for something, containing only letters, numbers, underscores or hyphens.

[sc68cal]

I wasn't sure, so I went and looked. I think we need to update this function to be more aligned with what NetBox does in their code, see my comment

[mabezi]

So, should we just copy the regular expressions from the Netbox project?

My honest opinion:
Depending on the use case, I can also imagine not running any filter at all. Worst case no result is returned by the API.

Detailed input validation is not always necessary in my opinion, because things like regular expressions can diverge after some time.
Especially when it comes to tasks where I just assign a tag, the developer should learn to make correct inputs.

But I can also simply adjust the regular expressions :)

[sc68cal]

I'm digging into this a bit more, I used git blame to look up #101 which references #95, where they have a comment where they look at how the Netbox frontend javascript handles creating slugs.

The code has obviously changed since then, but doing a search I came across https://github.com/netbox-community/netbox/blob/f0507d00bfd077755619b420eae8a5d8dc979d94/netbox/project-static/src/buttons/reslug.ts#L10 which has the code, but also does not appear to trim the number of hyphens.

So, I think we should take the opportunity to make _to_slug reflect what NetBox does, which I believe can be done per the suggestion I put inline.