...
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)