Add custom filter to parse default value from dict to json

[gXkch]

I have the issue that I have a dict as the value in the admin spec of the instance. It looks like json in the web UI but in reality it is a dict. When populating the survey field of the day 2 operation (update) with that value using {{ instance.spec.dictItem }}, I get a dict when I would actually like a JSON since I am also requesting a JSON value on the creation operation. This adds another custom filter "to_json" to parse the dict as valid json. I have tested this in my environment and it is working.

{{ instance.spec.dictItem | to_json }} will now display a json value in the survey field when the requestor is creating a day 2 operation

[Sispheor]

Hi @gXkch.
Thanks for your PR.
Form what I understand you store a json value into one of the key of the instance spec.
Why not having transformed the json to dict before pushing to Squest and then on the other side transforming back to json in your target playbook when needed?
I'm just wondering if this should be done at Squest level as it could be handled by backend playbooks, isn't it?

[gXkch]

@Sispheor Let me explain: I require a user to provide a JSON input on a creation operation in a survey field. I load this json in the ansible playbook and use it there. All good. This case is a bit more about aesthethics and usability rather than how it should be handled in the ansible playbook. How it is handled in ansible is no issue at all. I could live with whatever input comes from the survey.

The main issue, however, is when the user wants to do an update operation, they will need to provide a JSON again. It might be the same or they might have changed some values in the JSON or they are happy with the default value provided from the spec of the instance.
I would like the field to be preloaded with the default value I set in the spec as JSON and not a dict as it currently is the case. There are some reasons as to why this is kind of dumb:

When using a field validator that checks if the default input in the field is JSON, it fails. I do not expect the user to take the dict output and convert it to JSON themselves. Also, it might not immediately visible for the user what the validation problem is because dict and JSON look similar at first. Furthermore, it looks inconsistent that on day 1 you provide a valid JSON and on day 2 you request something and you see a python dict as the default in the survey.

If you do not want to merge this, I would understand. I am probably the only one that has this problem. I am capable of just mounting the file with my changes as a file in the container and be happy with that.

[Sispheor]

Did you try with native jinja filters? Seems that tojson exists.

[gXkch]

Yes, I tried. It just returns nothing whereas with my to_json filter it works.
tojson() returns markupsafe.Markup instead of str as is the case with many other filters.

[Sispheor]

We just tried on our side.
We've set this into the default of the field: {{ instance.user_spec.auth.kubeconfig | default({}) | tojson() }}

Then in form we do see our dict as json:

Could you share an example of instance spec + the survey field config (default value)

[gXkch]

Amazing! Thanks for sharing because I thought the usage of tojson() was to put the dict in the brackets instead of using it with "|". I was basically doing {{ tojson(instance.user_spec.auth.kubeconfig) }} instead of your way because I could not find any examples of the filter being used in jinja2. You may close the PR as this solves my issue.

[Sispheor]

Glad to know it works for you now !
I'm pretty sure this discussion will help somebody else in the futur anyway 😉.

[gXkch]

@Sispheor just as a sidenote: When applying the tojson() filter in the survey, the review task will throw an error "Object of type Undefined is not JSON serializable". I can request a day 2 operation and it prefills the values just fine but then wanting to review it, I think it tries to apply the filter again on the review screen but this time to the json string of the survey field. Can you verify this on your end?

[gXkch]

@Sispheor I am retarded i did not do default({}) like in your example and this seemed to fix the issue