API Composition Entity Uses one view

Support
#1

I have an issue where I have an entity with a composition child entity. Ticket as the main entity with Step as the composition entity collection on Ticket. Through the API, users are updating Ticket and the step collection as one message. It turns out that if a Ticket has two steps, and through the API we set a field called JobId on the first step, this field gets set to null on the second step if it isn’t also included in the message. I dug into the Cuba code on how this is handled. A View is created for the ticket and another View is created for all the steps. The problem is that only one View is created for the steps as a set of all provided fields across all of the steps in the message. If any of the steps doesn’t provide a field that another step is providing, it is set to null. Make sense?

This is creating some complicated logic that users have to adhere to. We don’t support updating steps separately as we have a lot of logic and Ticket and Steps are handled as one entity.

Thoughts?

#2

Hi Josh

Just to confirm - are you talking about REST API?
Also, why not all Steps are loaded - is it because of the application logic or security constraints?

#3

Yes, this is the REST API.

I’m not sure what you mean by all the Steps being loaded. Users will download the data and store it offline. They usually need to just update a single step’s fields because that step is all they care about. They then do a ticket update through the REST API. The nature of JSON is to just provide what you need, we are already requiring them to upload the ticket with all of the other steps in the message. With the single view on steps the REST API is also requiring that all fields be provided for all steps instead of just providing what the user would like to update on the single step.

For example,

  1. A User already has a ticket downloaded that has two steps on it. They only store offline the information they need. They don’t store the entire ticket and they only store details of Step 2.

  2. They do an update to the REST API. They provide a minimal ticket and two minimal steps in the message. They add a value to the ‘LOCATION’ field on step 2, but they don’t care about step 1 so they don’t provide any of the fields. They only provide the Id for step 1 to acknowledge that it’s still there and not being deleted.

  3. The REST API Cuba logic sees that ‘LOCATION’ is provided in step 2 but isn’t provided in step 1. Step 2 gets ‘LOCATION’ set correctly but step 1 has it’s ‘LOCATION’ property set to null even though ‘LOCATION’ wasn’t provided as part of the message.

#4

Thank you for the clear explanation of the problem. We’ll deal with it.

#6

Hi,
You’ve described the behavior correctly:

We don’t plan to change this behavior. In your particular case, if you need to update just a specific field of the “Step” entity, you may pass this single Step without a Ticket to the REST API. Or fill the same set of fields for all steps of the ticket.