...

• If dateStart is not specified it should be

  • Today if DateEnd is not specified

  • min (Today, DateEnd ) if DateEnd is specified

• Entity.DateValidFrom should be before the DateEnd if DateEnd is not null

• Entity.DateValidTo should be after date DateStart if Entity.DateValidTo is not null

Bulk actions on query

context: In real implementation there is not enough people to look at every claims, contract … meaning that most of those items are approved without a review (this was also the reason why claim AI module was developed). this means that the insurance worker will need to able to approve claims, contract … by bulk. Those bulk updates could targets hundred of thousand items, this means that we should avoid to send all the id back and forth between the front and the back end.

Solution proposed:

The bulk change could take the form of the normal mutation that support changes on an individual entity (claim, contract …), a list of entity or a Query

• the mutation will have a uuid field that will be used when there is only one entity

• the mutation will have a uuids field that will be used when there is a list of entities

• the mutation will have a query field that will be used when the entity need to be fetched with a query

uuid should have the priority on uuids that should have the priority on query

Then the mutation will create queryset based on the uuid/uuids/query

Then additional filter could be added to ensure the entity are eligible for the mutation

In case the query set return an empty result list then mutation should reply “not eligible <RessourceName> found“

The mutation itself should use the queryset in order call the database at the last moment.

if there is less than <confparamListSize> entities in the queryset, uuid of the entity will be returned with a appropriate status

if more than <confparamListSize> entities in the queryset, only the number of entity per status will be return (X errors, Y success)