@tommy nilsen @Florian Haase @omelhus You've all requested something similar I think.
Can you please provide your context/use cases - then we'll discuss it internally and share feedback. Things to consider: Would choosing between existing origins be enough, or do you need full CRUD? Should the API maybe have it's own origin? Should we add a separate additional field? Etc.
What I want is for the api to have a different level of access than a user. When it’s a user context it’s it should be like today, but when we are using the service client ids we should have the same access as the edi import.
From a integration view, it would be nice to be able to set this.
If not, if the API can set its own orign would be suffisent, with the combination of the user that created the batch.
The problem is that the reference to the client_id is lost when an user updates the batch. The updating user gets the owner of the batchcopy and it is not possible any more to filter out what is imported by the API. But due to revision we have to have the possibility to filter on API-Imports to be able to make check-reports. In the first version I think it would be enough for us, to have an own origin on API-Imports.
Copyright © 2022 Visma.com. All rights reserved.