Introduce the "auto config" feature on form destinations:
When a destination is created, all its fields are set as "auto configurated".
This mean that GLPI will pick the best value for each fields without the need for the user to manually edit them.
The goal here is that 95% of users will never need to change anything on this tab and thus can use forms destinations with little efforts.
The 5% remaining "power users" can still override the auto value and set their own values for super complex forms.
Right now we only have two fields but there will be a lot more in the final version (ticket category, location, urgency, linked items, ...).
To compare with formcreator, this feature did not exist which meant heavy configuration was needed for all forms.
For exemple if you added an "Urgency" question to your form, it would not be used in the created ticket unless you specified manually that the urgency must be set from the answer to a given question.
On native forms the auto config will do that by itself (once we have the urgency setting as it does not exist yet as mentioned before) .
This will be the same for every "not yet implemented" configuration fields that you can think of (ticket category, location, linked items, ...).
Another benefit is related to the Content field which can be "incrementally edited".
On formcreator you had a special ##fullform## tag which was an "all or nothing" solution: either you rely on fullform to generate your ticket description or you had to write the whole description from zero.
On native forms you can see exactly the generated content with the questions and answers, which mean you can directly edit it to make some small changes like hiding a special question or adding a different formatting for a given answer.
Introduce the "auto config" feature on form destinations:
When a destination is created, all its fields are set as "auto configurated". This mean that GLPI will pick the best value for each fields without the need for the user to manually edit them.
The goal here is that 95% of users will never need to change anything on this tab and thus can use forms destinations with little efforts. The 5% remaining "power users" can still override the auto value and set their own values for super complex forms.
Right now we only have two fields but there will be a lot more in the final version (ticket category, location, urgency, linked items, ...).
To compare with formcreator, this feature did not exist which meant heavy configuration was needed for all forms. For exemple if you added an "Urgency" question to your form, it would not be used in the created ticket unless you specified manually that the urgency must be set from the answer to a given question.
On native forms the auto config will do that by itself (once we have the urgency setting as it does not exist yet as mentioned before) .
This will be the same for every "not yet implemented" configuration fields that you can think of (ticket category, location, linked items, ...).
Another benefit is related to the
Contentfield which can be "incrementally edited".On formcreator you had a special
##fullform##tag which was an "all or nothing" solution: either you rely onfullformto generate your ticket description or you had to write the whole description from zero.On native forms you can see exactly the generated content with the questions and answers, which mean you can directly edit it to make some small changes like hiding a special question or adding a different formatting for a given answer.