Can't update Form Status using API

[nabilasabita]

I have a problem when I try to update the Form status using API When I'm trying to update the form status it has error "ERROR_GLPI_UPDATE, You don't have permission to perform this action". It works correctly in the interface but I can't implement it in request. I was login using Super-Admin

The call URL was : apirest.php/PluginFormcreatorFormAnswer/$id body :{"input":{"status":"103"}}

I just upgrade my GLPI and Plugin from GLPI 9.3 to GLPI 9.5.7, and from FormCreator 2.6.5 to FormCreator 2.12. It was work perfectly fine when I used GLPI 9.3 and FormCreator 2.6.5 but then the error "You don't have permission to perform this action" shows after I update the versions to GLPI 9.5.7 and FormCreator plugin version 2.12 Any idea why is this happens?

[btry]

Hi

The itemtype PluginFormcreatorFormAnswer does not have any right name. In such case GLPI rejects any authorization to modify objects of this type.

This makes sense as the form answers are not designed to be edited by any user. You should not change the data of any object of type PluginFormcreatorFormAnswer because there is some kind of mirroring with a PluginFormcreatorIssue row in the DB.

[nabilasabita]

Hi @btry But I have successfully edited the status using API when my GLPI version is 9.3 and FormCreator 2.6.5

The idea is I want to approve Form using other platforms such as Telegram chatbot so I need to change the status using API. I was successfully created it using GLPI 9.3 and FormCreator 2.6.5 but then after I update the version of the GLPI and Plugin it showed error "ERROR_GLPI_UPDATE, You don't have permission to perform this action". maybe it has some changes on the plugin or the GLPI? but I can't find it where are the changes

[btry]

But I have successfully edited the status using API when my GLPI version is 9.3 and FormCreator 2.6.5

With version 2.6.5 PluginFotrmcreatorFormAnswer was inherited from CommonDbChild (the parent itemtype was PluginFormcreatorForm). This parent / child relationship has been removed later, and I think it it is the root cause of the behavior change you observed.

Back to 2.6.x API was not supported by Formcreator. Over time I take into account a possible API usage but this is still not officially supported, and should be considered experimental.

As i said earlier, it makes sense to not allow modification on PluginFormcreatorFormAnswer objects. This is even more true with the status column, which will be a complexe aggregation of the statuses of the targets (implemented recently and added in the incoming 2.13.0 version)

[btry]

To approve a formanswer from a chatbot you need to login to GLPI via the API, with the credentials or the API key of a user who is an approver of the form answer object.

Then you need to issue a 2nd API request to aprove / reject the form form answer.

You need to check carefully the method PluginFormcreatorFormAnwer::prepareInputForUpdate() to see how to build the input data, and which (security) checks are done.

https://github.com/pluginsGLPI/formcreator/blob/v2.12.5/inc/formanswer.class.php#L723

[btry]

Hi

If don't want or cannot login as the user able to approve / reject a form answer, the best bet would be to develop a feature in Formcreator to delegate approval to an other user. This other user should be dedicated to your chatbot.

You may request for a quote to develop this feature, if you have a valid subscription to GLPI Network https://services.glpi-network.com/#offers

[nabilasabita]

Hi @btry Yes every user on my chatbot must login with their GLPI account, which mean the approver should have access to their form(which they have on GLPI website but not with API) and also for the 2nd API request I use API request update to update the form status

Can I just use a direct query to the database to edit form status on the database instead of using API?

[btry]

Hi

Can I just use a direct query to the database to edit form status on the database instead of using API?

I strongly discourage this practice as this will break consistency in the DB : the status of form answers, issues and tickets are dependant each other. Changing one of them will (starting with version 2.13) trigger update on the others. The only good solution is to use the API to ensure that the business logic in the PHP code does its job.

If for some reason the API does not works well with this use case, or if it does not grants you this update, then a fix must be created.

[nabilasabita]

Hi @btry

I strongly discourage this practice as this will break consistency in the DB : the status of form answers, issues and tickets are dependant each other

what is the difference between the status of table form answers and issues?

[nabilasabita]

also, is it possible to create a form using API?

[btry]

Hi

what is the difference between the status of table form answers and issues?

formanswers have a status to handle the validation process defined in the form linnked to the formanswer. Issues are a mix of tickets generated by GLPI or Formcreator and formanswers. The status of issues reflects the status of the object it comes from. However a form may generate several tickets. In such case, the issue matching those tickets does not exists. Instead you will find an issue linked to a formanswer, and the status will reflect a complex aggregation of the tickets linked to the formanswer.

also, is it possible to create a form using API?

Support of the API in this plugin is experimental. Creating, reading, updating, deleting, purging any object of Formcreator should globally work, but it is possible a few things will fail. Feel free to try and reports issues. Very few use the API with this plugin, as far s I know, and there is no automated tests for now.

EDIT: As I recommend you to use the API to work with the plugin instead of direct DB access, you should really try the API on a testing instance. Problems using the API should be globally easy to fix or enhance.

[nabilasabita]

Hi @btry

Support of the API in this plugin is experimental. Creating, reading, updating, deleting, purging any object of Formcreator should globally work, but it is possible a few things will fail. Feel free to try and reports issues. Very few use the API with this plugin, as far s I know, and there is no automated tests for now.

EDIT: As I recommend you to use the API to work with the plugin instead of direct DB access, you should really try the API on a testing instance. Problems using the API should be globally easy to fix or enhance.

If I want to create a form (Submit form) using API, in what sequence? I am confused about what data should I PUT first? because the content of this plugin is separate in many tables.

The main data, question data, answer data, and section data are in a different table, these data have their own table. so if I want to put it either using API or direct DB, what data should I PUT first?

[btry]

Hi

You need 2 API requests.

The fisrt must request the class PluginFormcreatorForm with the ID of the form you want to use. The response will contain all data of the form, sections, questions and conditions. This request is useful to have everything required to display the form property. Assuming you don't plan to build code to display any form from your glpi instance, you need at least to know the question IDs and the form ID.

The second request submits the inputs to generate a answer to the form. Create a PluginFormcreatorFormAnswer having the following properties

• a foreign key to PluginFormcreatorForm set to the ID of the form,
• formcreator_field_X . X is the ID of the question. You need probably as many properties as questions available in the form. If you have questions of type radios, check boxes or drop downs then you should check the code to find the appropriate data structure for their answers. Have a look in Inc/field/*. class.php. there are methods serialise data. They prepare them for the database.

[nabilasabita]

Hi @btry

The second request submits the inputs to generate a answer to the form. Create a PluginFormcreatorFormAnswer having the following properties

I don't quite understand, PluginFormcreatorFormAnswer doesn't have any information about answer , section and question right? so how am I generate the answer to the form?

[btry]

When a requester submits his answers, he actually creates a new PluginFormcreatorFormAnswer in DB. It modelizes the relation between the input for each question (PluginFormcreatorAnwer) and the form (PluginFormcreatorForm)

[nabilasabita]

When a requester submits his answers, he actually creates a new PluginFormcreatorFormAnswer in DB. It modelizes the relation between the input for each question (PluginFormcreatorAnwer) and the form (PluginFormcreatorForm)

but if i submit it from chatbot using API, how the system got the answer if im not PUT it to PluginFormcreatorFormAnswer?

[nabilasabita]

Hi @btry

The second request submits the inputs to generate a answer to the form. Create a PluginFormcreatorFormAnswer having the following properties

• a foreign key to PluginFormcreatorForm set to the ID of the form,
• formcreator_field_X . X is the ID of the question. You need probably as many properties as questions available in the form. If you have questions of type radios, check boxes or drop downs then you should check the code to find the appropriate data structure for their answers. Have a look in Inc/field/*. class.php. there are methods serialise data. They prepare them for the database.

So to submit a form from API i need to request GET to PluginFormcreatorForm with the ID of the form to get the Question id? and then i need to request PUT into PluginFormcreatorFormAnswer only? or into PluginFormcreatorAnwer also? and also do you have the example of JSON format to be inputed using API?

[btry]

i need to request GET to PluginFormcreatorForm with the ID of the form to get the Question id

yes

then i need to request PUT into PluginFormcreatorFormAnswer only?

yes. The value of all inputs from the user are sent in this request andFormcreator will do its job.

also do you have the example of JSON format to be inputed using API

Unfortunately not : there is no documentation specific to the API with Formcreator. You should rely on documentation provided by GLPI for generic API usage, and read the code of Formcreator to know its specificities. Most information are in prepareInputForAdd, prepareInputForUpdate methods of objects you're manipulating. To know the format of answers to pass to PluginFormcreatorFormAnswer you need to read the code of each field you have in your form (in inc/field/)