Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Limit tags to specific object types #11541

Closed
candlerb opened this issue Jan 20, 2023 · 4 comments
Closed

Limit tags to specific object types #11541

candlerb opened this issue Jan 20, 2023 · 4 comments
Assignees
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Milestone

Comments

@candlerb
Copy link
Contributor

NetBox version

v3.4.2

Feature type

Data model extension

Proposed functionality

Currently, once you've created a tag, it can be assigned to any object of any type.

I propose that tags can be optionally linked to a set of object types, in the same way that custom fields are linked to object types. Then, when editing a particular object, you'd only be able to select and add tags bound to that object's type.

Tags which are not bound to any object type would be continue to be applicable to all object types.

Use case

There are a wide range of uses for tags: classifying devices, interfaces, IP addresses etc. However, many tags are only meaningful to specific object types.

Being able to restrict them in this way would:

  • Reduce the size of drop-down menus for tag selection, making it quicker and easier for users to add tags
  • Prevent unsuitable tags being added to objects, in a way which is much easier to maintain and more transparent than custom validators

Database changes

There would need to be a new many-to-many join between tag and content type, just like custom fields:

class CustomField(CloningMixin, ExportTemplatesMixin, WebhooksMixin, ChangeLoggedModel):
    content_types = models.ManyToManyField(
        to=ContentType,
        related_name='custom_fields',
        limit_choices_to=FeatureQuery('custom_fields'),
        help_text=_('The object(s) to which this field applies.')
    )

External dependencies

None

@candlerb candlerb added the type: feature Introduction of new functionality to the application label Jan 20, 2023
@jeremystretch
Copy link
Member

I think this makes sense. With regard to associating tags to object types, we would need to employ validation to check for any existing assignments to objects of non-specified types, but that should be fairly straightforward.

@jeremystretch jeremystretch added the status: under review Further discussion is needed to determine this issue's scope and/or implementation label Jan 20, 2023
@candlerb
Copy link
Contributor Author

I'd be interested to know how custom fields deal with this case today: you create a custom field, link it to object type A, create some data on objects of that type, then unlink the custom field from that object type.

Experimentally: the custom field data is quietly deleted.

For tags, that might be a bit drastic, because you are going from the current open situation (allow this tag on all object types) to a more restricted option, and there's a risk of accidentally deleting tags.

I guess you could give the user a choice:

There are existing tags X on objects of type Y and Z. Do you want to:

  • Remove all tags X from Y and Z?
  • Allow objects of type Y and Z to use tag X?

Or maybe just do the second option (the safe thing) automatically. If the user wants to manually remove all the tags X from those objects, then remove those object types from the tag, they can do so.

@jsenecal
Copy link
Contributor

@candlerb unfortunately such functionality would require a wizard-like input. A validation error could be raised instead which would require a manual intervention to achieve either of the above...

What do you think?

@candlerb
Copy link
Contributor Author

A validation error would be fine, as long as it listed all the object types which had this tag but were not included in the set, and returned to the same populated form. Then the user could add them by hand to the set of enabled object types for that tag.

As for "wizard" I don't think it needs to be that complex:

  • There is a confirmation form shown in various situations already in Netbox, e.g. for certain types of bulk delete. So "Remove all tags X from objects of type Y and Z?" could be a confirmation form - it could also show the numbers of objects to be affected. This would be consistent with behaviour of custom fields (except you don't even get the confirmation)
  • By "doing the safe thing by default" I meant: whenever you edit a tag, the set of enabled object types automatically gets extended by the object types for which at least one object has that tag (unless the list is empty, which allows all objects anyway).

@jeremystretch jeremystretch added needs milestone Awaiting prioritization for inclusion with a future NetBox release and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Mar 16, 2023
@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed needs milestone Awaiting prioritization for inclusion with a future NetBox release labels May 5, 2023
@jeremystretch jeremystretch added this to the v3.6 milestone May 5, 2023
@jeremystretch jeremystretch self-assigned this May 31, 2023
jeremystretch added a commit that referenced this issue Jun 22, 2023
jeremystretch added a commit that referenced this issue Jun 23, 2023
jeremystretch added a commit that referenced this issue Jun 23, 2023
…12982)

* Initial work on #11541

* Merge migrations

* Limit tags by object type during assignment

* Add tests for object type validation

* Fix form field parameters
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 22, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

No branches or pull requests

3 participants