Cannot access draft entities with "HasActiveEntity=true"

[former_member826605]

Hi,

I want to implement Draft Handling in an UI5 Freestyle Application, using a Cap Node.js runtime as backend.

I have an entity with some compositions and annotated with @odata.draft.enabled. The entity is exposed to the frontend via an OData v4 model.

I can create a new draft by creating a new context in the list binding like this.

var oBinding = this.oDataModel.bindList("/Entity")<br>oBinding.create({})

As long as the draft has no active entity it can be accessed from the service via the url 'serviceName/Entity(ID="newDraftUUID",IsActiveEntity=false)'.

The draft can then be saved correctly using

var oOperation = this.oDataModel.bindContext(
	"EventRegistrationService.draftActivate(...)",
	oContext
);

However, when I create a draft from an existing context via

	var oOperation = this.oDataModel.bindContext(
		"EventRegistrationService.draftEdit(...)",
		oContext
	);

I cannot access the created draft, despite the draft entity beeing created in the data base correctly.

Strangely I can access compositions and associations of the created draft via the url 'serviceName/Entity(ID="newDraftUUID",IsActiveEntity=false)/composition', but I cannot access the draft entity or its properties.

Deployment to hana shows, that all tables get build correctly, and that the draft entities are created correctly in the database. Also the draftAdministrative data is correct.

The typical filter: $filter=(IsActiveEntity eq false or SiblingEntity/IsActiveEntity eq null) also only shows active entities and draft entities, that have not been created from an existing context.

We are using @sap/cds latest version, but also tried earlier ones.

In our Fiori Elements Applications Draft handling is still working. Although we are sending basically the same batches to our backend it does not work in the UI5 freestyle app.

The draft handling in our UI5 Application is basically done like in this sample.

The last comment by 'Lisi92' on this closed Issue is probably related to my problem, because the described issue is very similar.

Thanks in advance

Phillip

[former_member781382]

We have the same problem. Are there any news for this?

[david_kunz2]

Hi philliphanebuth ,

The problem was the following:
There was no authentication set up in your CAP app, hence the field `createdBy` was set to null.
Note: I expected `anonymous`, we will check why this isn't the case.

According to the specification, the draft scenario "List Report: All" shows only own drafts (otherwise active data). Since the created draft was not your own (createdBy == null != $user), it was not shown in the list and as a response to the draftEdit action.

Setting up XSUAA or mocked-auth will solve this problem.

Best regards,
David