Repository: netbox-community/netbox
Pull request: Update export-templates.md
<!--
    Thank you for your interest in contributing to NetBox! Please note
    that our contribution policy requires that a feature request or bug
    report be opened for approval prior to filing a pull request. This
    helps avoid wasting time and effort on something that we might not
    be able to accept.

    Please indicate the relevant feature request or bug report below.
    IF YOUR PULL REQUEST DOES NOT REFERENCE AN ACCEPTED BUG REPORT OR
    FEATURE REQUEST, IT WILL BE MARKED AS INVALID AND CLOSED.
-->
### Fixes: https://github.com/netbox-community/netbox/issues/6052

Both export templates and config context data are extremely powerful and useful, but it isn't immediately clear how use the two together. This change adds details on how to use the two together.




Problem statement:
Accessing Fully Rendered Config Context Data is not Clear When Using Export Templates
### Change Type

Addition

### Area

- [ ] Installation instructions
- [ ] Configuration parameters
- [ ] Functionality/features
- [ ] REST API
- [ ] Administration/development
- [ ] Other

### Proposed Changes

The combination of export templates and config context data are extremely powerful, but use the two in combination isn't as intuitive as accessing ofter attributes within an object.  In order to access the fully rendered config context for an object, you need to use the function `get_config_context()` in the jinja template, which does not appear to be documented anywhere.

Hints from issue discussion:
I'd be happy to write the documentation myself, I just need the issue be accepted.

Commit message: Update export-templates.md

Patch to review:
diff --git a/docs/additional-features/export-templates.md b/docs/additional-features/export-templates.md
index 1e0611f0692..954aa850634 100644
--- a/docs/additional-features/export-templates.md
+++ b/docs/additional-features/export-templates.md
@@ -18,6 +18,14 @@ Height: {{ rack.u_height }}U
 
 To access custom fields of an object within a template, use the `cf` attribute. For example, `{{ obj.cf.color }}` will return the value (if any) for a custom field named `color` on `obj`.
 
+Since local_context_data is part of an object, it is immediately available to use in the export template, however if you need the fully rendered context config you'll need to use the function `get_config_context`. For example:
+```
+{% for server in queryset %}
+{% set data = server.get_config_context() %}
+{{data.syslog}}
+{% endfor %}
+```
+
 A MIME type and file extension can optionally be defined for each export template. The default MIME type is `text/plain`.
 
 ## Example


Code review comments:
diff_hunk: @@ -18,6 +18,14 @@ Height: {{ rack.u_height }}U
 
 To access custom fields of an object within a template, use the `cf` attribute. For example, `{{ obj.cf.color }}` will return the value (if any) for a custom field named `color` on `obj`.
 
+Since local_context_data is part of an object, it is immediately available to use in the export template, however if you need the fully rendered context config you'll need to use the function `get_config_context`. For example:
path: docs/additional-features/export-templates.md
text: @user1:
We should not encourage accessing `local_context_data` directly: `get_config_context()` should always be used to ensure the complete configuration data is returned.

@author:
I've updated the comment here to drop completely the reference to `local_context_data` and said to use the config_context data you should use the `get_config_context` function.