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

Create custom fields that are computed based on referencing other data #4

Closed
jedelman8 opened this issue Feb 24, 2021 · 7 comments · Fixed by #577
Closed

Create custom fields that are computed based on referencing other data #4

jedelman8 opened this issue Feb 24, 2021 · 7 comments · Fixed by #577
Assignees
Labels
type: feature Introduction of substantial new functionality to the application
Milestone

Comments

@jedelman8
Copy link
Contributor

jedelman8 commented Feb 24, 2021

Proposed Functionality

Read-only computed custom fields using existing data already stored in the database. This will allow users to be able to build lightweight Jinja (or Python) templates to populate a read-only custom field value.

Use Case

As a user, I want to dynamically generate interface descriptions using device, neighboring device, circuit, or circuit ID. All data already stored in Nautobot, I should be able to use Jinja templating, similar to custom links, to build that string thus simplifying the network configuration templates that are used to generate full configurations. As a user, I should be able to auto-generate fields that are required by automation systems like Ansible, e.g. ansible_network_os being "{{ vendor }}.{{ os }}.{{ os }}".

Database Changes

Will require some sort of database record to define and store these templates. Probably a new model as the existing custom-fields model is not directly applicable.

External Dependencies

None.

@jedelman8 jedelman8 added this to the v1.1.0 milestone Feb 24, 2021
andy-wm-arthur pushed a commit to dolthub/nautobot that referenced this issue Mar 2, 2021
…contexts, export-templates, and custom-jobs.
@jifox
Copy link
Contributor

jifox commented Mar 16, 2021

Is there also a possibilty to add such functionality to interface templates?

For e.g. a stacked switch has 48 Ports that have a name that depends on chassis nr

Gi1/0/[1-48] for switch 1
Gi2/0/[1-48] for switch 2

so to define

Gi{% chassis_nr %}/0/[1-48]

@glennmatthews glennmatthews added the type: feature Introduction of substantial new functionality to the application label Mar 19, 2021
@jedelman8
Copy link
Contributor Author

@jifox Where would chassis_nr be defined in this example? Proposing to use a custom field to define the number and then use that in the template?

@jifox
Copy link
Contributor

jifox commented Mar 23, 2021

@jedelman8 It should reference the Position field of Members to Virtual Chassis

Virtual_Chassis_add_device

@jifox
Copy link
Contributor

jifox commented Mar 23, 2021

@jedelman8 with a default value of 1

@jfach
Copy link
Contributor

jfach commented May 18, 2021

I'll take this one!

@jedelman8 jedelman8 added this to the v1.1.0 milestone May 18, 2021
jfach added a commit to jfach/nautobot that referenced this issue Jun 15, 2021
jfach added a commit to jfach/nautobot that referenced this issue Jun 15, 2021
jfach added a commit to jfach/nautobot that referenced this issue Jun 15, 2021
glennmatthews added a commit that referenced this issue Jun 29, 2021
jathanism added a commit that referenced this issue Jul 2, 2021
This PR introduces an implementation for "Computed Fields" that are renderable on a ContentType based on a user-supplied Jinja2 template. It also introduces the ability for users to add custom jinja filters to the jinja rendering environment through plugins, similar to custom validators in implementation.

The concept of `opt_in_fields` is also introduced to serializers, allowing certain fields to be considered "opt-in only" when being consumed from the API. This feature is handled by the `OptInFieldsMixin` class.

Co-authored-by: Glenn Matthews <glenn.matthews@networktocode.com>
Co-authored-by: Jathan McCollum <jathan@gmail.com>
Co-authored-by: Ken Celenza <ken@celenza.org>
Co-authored-by: evdzande <82216020+evdzande@users.noreply.github.com>
Co-authored-by: tim-fiola <timothy.fiola@gmail.com>
@dgarros
Copy link
Contributor

dgarros commented Jul 13, 2021

I think we should be good to close this one

@glennmatthews
Copy link
Contributor

Fixed by #577

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Oct 12, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: feature Introduction of substantial new functionality to the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants