Sastre restore should omit editedTemplateDefinition from feature-template create/update payloads

[bdutia-cisco]

Sastre feature-template backup payloads include both templateDefinition and
editedTemplateDefinition, matching the vManage GET response shape. During restore, Sastre appears
to reuse those exported payloads when calling /dataservice/template/feature POST/PUT.

editedTemplateDefinition is not expected as an input field for feature-template create/update. The
vManage UI does not send it in POST/PUT requests; vManage backend derives and persists
editedTemplateDefinition from templateDefinition.

Recent vManage template/policy hardening validates control characters and line separators in
incoming request payloads. Legitimate multiline CLI/banner content is allowed under the effective
templateDefinition paths, but Sastre also sends the copied multiline content under
editedTemplateDefinition. That extra returned field can cause restore failures even though vManage
would not use incoming editedTemplateDefinition for persistence.

Expected Behavior
Sastre should restore feature templates successfully by sending only create/update input fields
to /dataservice/template/feature POST/PUT. Returned/persisted fields such as
editedTemplateDefinition should be omitted from restore create/update requests.

Actual Behavior
Sastre restore sends feature-template payloads that include editedTemplateDefinition. For CLI-
template and banner templates, the copied multiline values under editedTemplateDefinition can be
rejected by vManage hardening with errors such as invalid control or line separator character at:
$.editedTemplateDefinition.config.vipValue
$.editedTemplateDefinition.login.vipValue
$.editedTemplateDefinition.motd.vipValue

Affected Version
Sastre Version 1.26
Catalog: 95 configuration items, 33 operational items

Steps to Reproduce

1. Back up vManage feature templates using Sastre.
2. Restore the backup to another vManage.
3. Observe feature-template restore failures when exported payloads include
   editedTemplateDefinition with multiline CLI/banner values.

Fix Direction
Before invoking /dataservice/template/feature POST/PUT, strip editedTemplateDefinition from
feature-template restore payloads. Keep templateDefinition unchanged, since it is the effective
input used by vManage create/update.

[reismarcelo]

Thank you for opening this issue. I'm making the change, which will go in the next release Sastre 1.28 (planned to be released in the next few days).

[reismarcelo]

I added the fix to the dev-1.28 branch. Could you validate? I couldn't recreate the original problem in 20.18.2.2. Assuming you're seeing it in a later Manager release?

To install from the dev-1.28 branch:
pip install git+https://github.com/CiscoDevNet/sastre.git@dev-1.28

Once installed you should see version 1.28.dev10:
% sdwan --version
Sastre Version 1.28.dev10. Catalog: 99 configuration items, 35 operational items.

[usurabhi-cisco]

I added the fix to the dev-1.28 branch. Could you validate? I couldn't recreate the original problem in 20.18.2.2. Assuming you're seeing it in a later Manager release?

To install from the dev-1.28 branch: pip install git+https://github.com/CiscoDevNet/sastre.git@dev-1.28

Once installed you should see version 1.28.dev10: % sdwan --version Sastre Version 1.28.dev10. Catalog: 99 configuration items, 35 operational items.

Thanks for the quick fix on the reported issue.
We are working on validating the fix now and will let you know once verification is complete and everything looks good.