[FR] REST API v2.1.0: first cases endpoints

[c8y3]

This issue is about the implementation of the first cases endpoints:

• POST /api/v2/cases
• GET /api/v2/cases/{identifier}
• DEL /api/v2/cases/{identifier}

For each endpoint, the tasks are the following:

• document the new API in the openapi documentation
• implement automatic tests+code
• deprecate the previous endpoints both in the code and in the documentation
• replace the previous endpoints with the new ones in the web interface

These are the previous endpoints which will be deprecated by these:

• POST /manage/cases/add => POST /api/v2/cases
• GET /manage/cases/{identifier} => GET /api/v2/cases/{identifier}
• GET /case/exists => GET /api/v2/cases/{identifier}
• DEL /manage/cases/delete/{identifier} => DEL /api/v2/cases/{identifier}

Notes :

• for GET /case/exists, if we want to optimize/or make the API more usable, we could use HEAD
• url GET /case/export is not deprecated yet. It will have to be discussed first

In the web interface:

• GET /case/exists in common.js
• DEL /manage/cases/delete in manage.cases.common.js

[c8y3]

It seems that the endpoints to be deprecated are used in the following files for the IHM:

• /manage/cases/add app/static/assets/js/iris/common.js
• /case/exists in app/static/assets/js/iris/common.js
• /case/summary/fetch in app/static/assets/js/iris/case.summary.js
• /manage/cases/delete/{identifier} in app/static/assets/js/iris/manage.cases.common.js

[c8y3]

Some questions about case creation.
Do we want the rename the fields?

• case_name => name
• case_description => description
• case_customer => customer
• case_soc_id => soc_identifier

Are we happy with short names and acronyms such as id, soc?
Should the case_description and case_soc_id be optional fields?

[c8y3]

Some implementation notes:

• added app.blueprints.rest.endpoints.response_created
• added app.blueprints.rest.endpoints.response_failed
• renamed endpoint_deprecated into endpoint_removed
• added app.blueprints.rest.endpoints.endpoint_deprecated

[whikernel]

Hi!
I think it would be better to keep the longer version case_name, case_description etc.

[c8y3]

Random remarks/difficulties:

• What are the case custom_attributes?
• Why is the case_template_id a string and not an integer? (the code is string currently, should it be modified)
• In the documentation of /manage/cases/add, why is the case_customer in the requestBody a number rather than an integer?
• it is difficult to know from the code which fields can be passed as request body. For instance state_id is allowed, but will have no impacts whatsoever, whereas user is a unkown field, whereas user_id is an unexpected keyword argument for __init__.
• should review the TODOs in source/app/util.py and source/app/iris_engine/access_control/utils.py
• /manage/cases/{identifier}, /case/meta and /case/export do not seem to be used in the web interface. However, they do not seem to return the same results. Which endpoint is used? Where?Which one should be implemented?

[c8y3]

Endpoint /case/summary/fetch not straightforward to remove in case.summary.js because the crc of the description is computed server-side. But why?