starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Add tag field for asset import and export #2972

New Issue
Closed
opened 2025-12-29 18:24:15 +01:00 by adam · 8 comments
adam commented 2025-12-29 18:24:15 +01:00
Owner
Copy Link

Originally created by @bellwood on GitHub (Oct 24, 2019).

Environment

  • Python version: 3.6.9
  • NetBox version: 2.6.6

Proposed Functionality

When manually entering most items in Netbox, we can assign tags however we cannot assign tags to items when bulk importing and cannot see tags when exporting.

Use Case

Import and export of assets should include tags, which in our case, are extremely useful and would be immensely easier to deal with en-mass vs. manually adding tags after import - which is often similar data.

Database Changes

No schema changes would be required, tags are an existing feature.

External Dependencies

No external dependancies or packages would be required

Suggested Implementation

On the import side, data could be entered as json:

an_import_field,{'tag1','tag2','etc'},yet_another_import_field

On the export side, it's simply another field/relationship to pull for the export query.

Originally created by @bellwood on GitHub (Oct 24, 2019). ### Environment * Python version: 3.6.9 * NetBox version: 2.6.6 ### Proposed Functionality When manually entering most items in Netbox, we can assign tags however we cannot assign tags to items when bulk importing and cannot see tags when exporting. ### Use Case Import and export of assets should include tags, which in our case, are extremely useful and would be immensely easier to deal with en-mass vs. manually adding tags after import - which is often similar data. ### Database Changes No schema changes would be required, tags are an existing feature. ### External Dependencies No external dependancies or packages would be required ### Suggested Implementation On the import side, data could be entered as json: `an_import_field,{'tag1','tag2','etc'},yet_another_import_field` On the export side, it's simply another field/relationship to pull for the export query.
adam added the type: featurestatus: needs ownerpending closure labels 2025-12-29 18:24:15 +01:00
adam closed this issue 2025-12-29 18:24:15 +01:00
adam commented 2025-12-29 18:24:15 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 25, 2019):

an_import_field,{'tag1','tag2','etc'},yet_another_import_field

This would be interpreted by the CSV parser as:

["an_import_field", "{'tag1'", "'tag2'", "'etc'}", "yet_another_import_field"]

A different deliminator would be needed to preserve the list of tags as a single unit for later processing by a multiple-value field. That field would also need to be created.

@jeremystretch commented on GitHub (Oct 25, 2019): > `an_import_field,{'tag1','tag2','etc'},yet_another_import_field` This would be interpreted by the CSV parser as: ``` ["an_import_field", "{'tag1'", "'tag2'", "'etc'}", "yet_another_import_field"] ``` A different deliminator would be needed to preserve the list of tags as a single unit for later processing by a multiple-value field. That field would also need to be created.
adam commented 2025-12-29 18:24:15 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Oct 25, 2019):

What if csv_format checked value for JSON before wrapping the commas with double quotes:

def is_json(value):
    try:
        json_object = json.loads(value)
    except ValueError as e:
        return False
    return True

That way we can keep the import format something native (JSON).

Would definitely need some testing but rather than come up with an alternative delimiter and write a parser for that, keep it simple?

@bellwood commented on GitHub (Oct 25, 2019): What if csv_format checked `value` for JSON before wrapping the commas with double quotes: ``` def is_json(value): try: json_object = json.loads(value) except ValueError as e: return False return True ``` That way we can keep the import format something native (JSON). Would definitely need some testing but rather than come up with an alternative delimiter and write a parser for that, keep it simple?
adam commented 2025-12-29 18:24:16 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 25, 2019):

CSV parsing needs to happen first so that values get assigned to their respective fields. Just need a different delimiter (e.g. pipe or whatever) to separate values within a field. (JSON is overkill.)

@jeremystretch commented on GitHub (Oct 25, 2019): CSV parsing needs to happen first so that values get assigned to their respective fields. Just need a different delimiter (e.g. pipe or whatever) to separate values within a field. (JSON is overkill.)
adam commented 2025-12-29 18:24:16 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 25, 2019):

Actually, I suppose the canonical approach would be to wrap the tags list in double quotes, e.g. an_import_field,"tag1,tag2,etc",yet_another_import_field.

@jeremystretch commented on GitHub (Oct 25, 2019): Actually, I suppose the canonical approach would be to wrap the tags list in double quotes, e.g. `an_import_field,"tag1,tag2,etc",yet_another_import_field`.
adam commented 2025-12-29 18:24:16 +01:00
Author
Owner
Copy Link

@bellwood commented on GitHub (Oct 25, 2019):

That would render:
["an_import_field","tag1","tag2","etc","yet_another_import_field"]

So, I suppose a pipe would be a suitable alternative delimiter:
["an_import_field","tag1|tag2|etc","yet_another_import_field"]

Provided tags can't/don't contain commas that could work

@bellwood commented on GitHub (Oct 25, 2019): That would render: `["an_import_field","tag1","tag2","etc","yet_another_import_field"]` So, I suppose a pipe would be a suitable alternative delimiter: `["an_import_field","tag1|tag2|etc","yet_another_import_field"]` Provided tags can't/don't contain commas that could work
adam commented 2025-12-29 18:24:16 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (Oct 25, 2019):

an_import_field,"tag1,tag2,etc",yet_another_import_field will render correctly. This is the same approach we use to handle commas and line break in comment fields.

@jeremystretch commented on GitHub (Oct 25, 2019): `an_import_field,"tag1,tag2,etc",yet_another_import_field` will render correctly. This is the same approach we use to handle commas and line break in comment fields.
adam commented 2025-12-29 18:24:17 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Dec 6, 2019):

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our contributing guide.

@stale[bot] commented on GitHub (Dec 6, 2019): This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. NetBox is governed by a small group of core maintainers which means not all opened issues may receive direct feedback. Please see our [contributing guide](https://github.com/netbox-community/netbox/blob/develop/CONTRIBUTING.md).
adam commented 2025-12-29 18:24:17 +01:00
Author
Owner
Copy Link

@stale[bot] commented on GitHub (Dec 13, 2019):

This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.

@stale[bot] commented on GitHub (Dec 13, 2019): This issue has been automatically closed due to lack of activity. In an effort to reduce noise, please do not comment any further. Note that the core maintainers may elect to reopen this issue at a later date if deemed necessary.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label pending closure status: needs owner type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#2972
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?