Implement customizable primary name field

[jonasnieberle]

Plugin Version

0.4.0

Proposed functionality

Implement a function to customize the primary name field. At the moment it's only possible to set one field as primary name field.

Implement a new field in the custom object to define the primary name field with a Jinja2 Expression, so it's possible to build every primary name field which you want. You can use the value of the fields with Jinja2 Expressions.

Example:

Custom Object: SFP Module

Fields:

• Serial
• Manufacturer
• Name

Primary Name Field: "{{Name}} - {{Manufacturer}}"

Object 1:

• Serial: 12345
• Manufacturer: Cisco
• Name: SFP-10G-LR

Final Primay Name: SFP-10G-LR - Cisco

Object 2:

• Serial: 122445
• Manufacturer: Arista
• Name: SFP-10G-LR

Final Primay Name: SFP-10G-LR - Arista

Use case

The primary name field than can be customized in more detail.

External dependencies

No response

[mrmrcoleman]

The primary key can be set to any Custom Object Field on the Custom Object Type. I think a better way to implement this would be to add OPs suggested Jinja approach but as an option for Custom Object Type Fields of type text.

Workflow:

• Add COTF name (for example) of type text
• Add the Jinja definition for generating the name
• Set the name field to Primary

[jonasnieberle]

Im not sure If this will be a good Idea, because you have to handle / think about the following topics:

• handle jinja2 statement, if you use a field which not anymore exist? Example:

Fields:

Serial
Manufacturer
Name
Primary Name Field: "{{Name}} - {{Manufacturer}}"

--> How do you handle if the field Name will be deleted. Or not exist

• The field isn't a write field in this "primary name field" context, because the value of the field will be created automatically via the jinja2 statement. If you use the normal text field you have to introduce this logic to handle if its a default text field or a text field with the jinja2 logic.

I think its easier if you add the logic to the custom object Types:

Add the following fields:
--> Primary Name Field Scope --> Choose between static Field or Jinja2 statement

Maybe the same logic like on the prefix scope:

--> If you chose static Field: You can choose one of the allready exisiting fields for the custom object type
--> If you chose Jinja2 statement: You can enter a Jinja2 String and use the values of the existing fields

Benefits:

• You dont have to change the exisiting fields (just remove the primary name field options)
• You can validate the Jinja2 statement in the save operation of the custom object type

Open point:

• Handling the jinja2 statement if an exisiting field will be removed?

[ed-ud]

This also brings up the common case where you need to have more than field make up a unique constraint, like the Interface model (device object + interface name need to be unique).