#3144 Tag renaming is not covered by history
Opened 2 years ago by tkopecek. Modified 2 years ago

As the name is not part of tag_config rename events are lost. We probably should track it for auditing reasons.


This is a pretty significant db change, and it would impact a large number of hub queries.

If we do this, then for consistency we'd want to do the same for other names for versioned data that can be renamed, e.g. targets, channels, external_repos, maybe even users. Furthermore there are other names of versioned items that the api doesn't offer rename for, but might be wanted for consistency: hostnames, content generators. Otoh, I'd probably avoid packages and groups.

Doing this would likely have the side effect of allowing new tags to assume the names of deleted ones (since the uniqueness condition would necessarily be limited to active entries). This might be a good thing, but it's also a big change and something that could have surprising side effects.

This feels like a can of worms

Metadata Update from @mikem:
- Custom field Size adjusted to None

2 years ago

Metadata Update from @mikem:
- Issue tagged with: discussion

2 years ago

I was thinking about some "lightweight" version. Like not changing db schema but only adding some new tag_config record with name update. It would "only" add "name" record to the tag_config which will be only consulted in audit/history calls. Maybe it is too hackish and we should drop this idea.

Login to comment on this ticket.

Metadata