From af08722ec53ef39cf60d9e5827639d84ee1398cc Mon Sep 17 00:00:00 2001 From: I548646 Date: Thu, 20 Nov 2025 11:05:47 +0100 Subject: [PATCH 01/10] feat: add initial version of new action docs --- node.js/fiori.md | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) diff --git a/node.js/fiori.md b/node.js/fiori.md index 249b783d5..5a36241f2 100644 --- a/node.js/fiori.md +++ b/node.js/fiori.md @@ -185,6 +185,45 @@ You can set the property to one of the following: It can occur that inactive drafts are still in the database after the configured timeout. The deletion is implemented as a side effect of creating new drafts and there's no periodic job that does the garbage collection. ::: +## Enabling `@Common.DraftRoot.NewAction` {.impl .beta} + +By default, to create a new instance of a draft enabled entity in draft state, Fiori Elements will send a `POST` request to the collection path of that entity. +This behavior can be adjusted by annotating the relevant entity with `@Common.DraftRoot.NewAction: MyService.draftNew`, referencing a collection-bound action by name. +Instead of sending a `POST` request to the collection path, to create a new entity, Fiori Elements will now try to trigger that action. +The referenced action is expected to create a new instance of the entity in draft state and return it. + +```cds +service MyService { + + @odata.draft.enabled + @Common.DraftRoot.NewAction: MyService.draftNew + entity MyEntity as projection on db.MyEntity actions { + action draftNew(in: many $self, intId: Integer, stringId: String) returns MyEntity; + } +} +``` + +:::warning +Annotating an entity thus will change the behavior of Fiori Elements, regardless of whether or not using the action has the intended result. +In order to provide a seamless experience in a Fiori Elements UI, your handler implementation for the custom action must comply with all relevant Fiori Elements requirements. +::: + +By providing an action that can be invoked to create a new instance, `POST` requests to the collection path of the entity are now free to be interpreted differently. +Once a draft enabled entity is annotated with `@Common.DraftRoot.NewAction`, `POST` requests to the collection path of the entity, by default, will create an active instance of the entity instead. +These `POST` requests will consider an attribute `IsActiveEntity` in the request body and will still allow creating a draft instance, if `IsActiveEntity: false` is specified explicitly. +This behavior is similar to, but not the same as [bypassing drafts](#bypassing-drafts), + +### Generic `NewAction` {.impl .beta} + +Since implementing a proper `NewAction` and enable a seamless draft experience in Fiori Elements is a repetitive but non-trivial task, CAP Node.js provides the feature `cds.features.new_draft_via_action`. +This feature is disabled by default. +Activating the feature will cause the `@Common.DraftRoot.NewAction` annotation to be added to _every_ draft enabled entity in the background. +Additionally, a collection bound action `draftNew` will be added to the entity's runtime model. +Invokations of this action will internally be handled like a `NEW` event. + +:::warning +No custom handlers can be registered for the `draftNew` action. Instead, such custom handlers should be registered on the regular `NEW` event. +::: ## Bypassing Drafts Creating or modifying active instances directly is possible without creating drafts. This comes in handy when technical services without a UI interact with each other. From 8e09d794a00dd106542c9cad0afc52a9fe72648b Mon Sep 17 00:00:00 2001 From: Paul Date: Thu, 20 Nov 2025 11:09:28 +0100 Subject: [PATCH 02/10] fix: spelling Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> --- node.js/fiori.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/node.js/fiori.md b/node.js/fiori.md index 5a36241f2..b56b81fef 100644 --- a/node.js/fiori.md +++ b/node.js/fiori.md @@ -219,7 +219,7 @@ Since implementing a proper `NewAction` and enable a seamless draft experience i This feature is disabled by default. Activating the feature will cause the `@Common.DraftRoot.NewAction` annotation to be added to _every_ draft enabled entity in the background. Additionally, a collection bound action `draftNew` will be added to the entity's runtime model. -Invokations of this action will internally be handled like a `NEW` event. +Invocations* of this action will internally be handled like a `NEW` event. :::warning No custom handlers can be registered for the `draftNew` action. Instead, such custom handlers should be registered on the regular `NEW` event. From d6297631a12bdd1893b7c61ab22533fd11bc22d8 Mon Sep 17 00:00:00 2001 From: I548646 Date: Thu, 20 Nov 2025 15:45:59 +0100 Subject: [PATCH 03/10] feat: move section on changed post behavior --- node.js/fiori.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/node.js/fiori.md b/node.js/fiori.md index b56b81fef..5ccc4916e 100644 --- a/node.js/fiori.md +++ b/node.js/fiori.md @@ -208,23 +208,23 @@ Annotating an entity thus will change the behavior of Fiori Elements, regardless In order to provide a seamless experience in a Fiori Elements UI, your handler implementation for the custom action must comply with all relevant Fiori Elements requirements. ::: -By providing an action that can be invoked to create a new instance, `POST` requests to the collection path of the entity are now free to be interpreted differently. -Once a draft enabled entity is annotated with `@Common.DraftRoot.NewAction`, `POST` requests to the collection path of the entity, by default, will create an active instance of the entity instead. -These `POST` requests will consider an attribute `IsActiveEntity` in the request body and will still allow creating a draft instance, if `IsActiveEntity: false` is specified explicitly. -This behavior is similar to, but not the same as [bypassing drafts](#bypassing-drafts), - ### Generic `NewAction` {.impl .beta} Since implementing a proper `NewAction` and enable a seamless draft experience in Fiori Elements is a repetitive but non-trivial task, CAP Node.js provides the feature `cds.features.new_draft_via_action`. This feature is disabled by default. Activating the feature will cause the `@Common.DraftRoot.NewAction` annotation to be added to _every_ draft enabled entity in the background. Additionally, a collection bound action `draftNew` will be added to the entity's runtime model. -Invocations* of this action will internally be handled like a `NEW` event. +Invocations of this action will internally be handled like a `NEW` event. :::warning No custom handlers can be registered for the `draftNew` action. Instead, such custom handlers should be registered on the regular `NEW` event. ::: +By generically providing an action that can be invoked to create a new instance, `POST` requests to the collection path of the entity are now free to be interpreted differently. +That is why, with `cds.features.new_draft_via_action` enabled, `POST` requests to the collection path of the entity, by default, will create an active instance instead. +These `POST` requests will consider an attribute `IsActiveEntity` in the request body and will still allow creating a draft instance, if `IsActiveEntity: false` is specified explicitly. +This behavior is similar to, but not the same as [bypassing drafts](#bypassing-drafts). + ## Bypassing Drafts Creating or modifying active instances directly is possible without creating drafts. This comes in handy when technical services without a UI interact with each other. From acded1a97c6eecf4b1e25fd68d4098e57f52fcc0 Mon Sep 17 00:00:00 2001 From: I548646 Date: Fri, 21 Nov 2025 16:09:07 +0100 Subject: [PATCH 04/10] docs: replace docs --- node.js/fiori.md | 51 ++++++++++++++++++------------------------------ 1 file changed, 19 insertions(+), 32 deletions(-) diff --git a/node.js/fiori.md b/node.js/fiori.md index 5ccc4916e..6a8241e3e 100644 --- a/node.js/fiori.md +++ b/node.js/fiori.md @@ -185,49 +185,36 @@ You can set the property to one of the following: It can occur that inactive drafts are still in the database after the configured timeout. The deletion is implemented as a side effect of creating new drafts and there's no periodic job that does the garbage collection. ::: -## Enabling `@Common.DraftRoot.NewAction` {.impl .beta} - -By default, to create a new instance of a draft enabled entity in draft state, Fiori Elements will send a `POST` request to the collection path of that entity. -This behavior can be adjusted by annotating the relevant entity with `@Common.DraftRoot.NewAction: MyService.draftNew`, referencing a collection-bound action by name. -Instead of sending a `POST` request to the collection path, to create a new entity, Fiori Elements will now try to trigger that action. -The referenced action is expected to create a new instance of the entity in draft state and return it. - -```cds -service MyService { - - @odata.draft.enabled - @Common.DraftRoot.NewAction: MyService.draftNew - entity MyEntity as projection on db.MyEntity actions { - action draftNew(in: many $self, intId: Integer, stringId: String) returns MyEntity; - } -} -``` +## Bypassing Drafts -:::warning -Annotating an entity thus will change the behavior of Fiori Elements, regardless of whether or not using the action has the intended result. -In order to provide a seamless experience in a Fiori Elements UI, your handler implementation for the custom action must comply with all relevant Fiori Elements requirements. -::: +The draft choreography does not allow active instances of draft-enabled entities to be created or modified directly. +However, when working with technical services that are not exclusively consumed through a GUI, the option to bypass this restriction can be useful. +The CAP Node.js runtime provides two similar but distinct options for bypassing the regular draft choreography. -### Generic `NewAction` {.impl .beta} +### Generic `@Common.DraftRoot.NewAction` -Since implementing a proper `NewAction` and enable a seamless draft experience in Fiori Elements is a repetitive but non-trivial task, CAP Node.js provides the feature `cds.features.new_draft_via_action`. +By enabling the feature `cds.features.new_draft_via_action`, you can change how new instances of draft-enabled entities get created in the CAP Node.js runtime. This feature is disabled by default. -Activating the feature will cause the `@Common.DraftRoot.NewAction` annotation to be added to _every_ draft enabled entity in the background. -Additionally, a collection bound action `draftNew` will be added to the entity's runtime model. -Invocations of this action will internally be handled like a `NEW` event. +When you activate this feature, the `@Common.DraftRoot.NewAction` annotation is automatically added to _every_ draft-enabled entity in the background. +Additionally, a collection-bound action `draftNew` is added to the entity's runtime model. +When this annotation is present, Fiori Elements triggers the action referenced by the annotation instead of sending a `POST` request to the collection path to create a new entity. +The runtime rewrites calls to this action internally as a `NEW` event. :::warning No custom handlers can be registered for the `draftNew` action. Instead, such custom handlers should be registered on the regular `NEW` event. ::: -By generically providing an action that can be invoked to create a new instance, `POST` requests to the collection path of the entity are now free to be interpreted differently. -That is why, with `cds.features.new_draft_via_action` enabled, `POST` requests to the collection path of the entity, by default, will create an active instance instead. -These `POST` requests will consider an attribute `IsActiveEntity` in the request body and will still allow creating a draft instance, if `IsActiveEntity: false` is specified explicitly. -This behavior is similar to, but not the same as [bypassing drafts](#bypassing-drafts). +By providing a dedicated action that can be called to create a new instance, `POST` requests to the collection path of the entity can now be used differently: +With `cds.features.new_draft_via_action` enabled, `POST` requests to the collection path create an active instance instead of a draft. +When handling these `POST` requests, the runtime considers an `IsActiveEntity` attribute in the request body to still allow creating a draft instance when `IsActiveEntity: false` is specified explicitly. -## Bypassing Drafts -Creating or modifying active instances directly is possible without creating drafts. This comes in handy when technical services without a UI interact with each other. +This change in what the `POST` method does in the context of draft-enabled entities promotes the assumption that all CRUD operations will target the active- rather than the draft-state entity by default. +This is why activating the `cds.features.new_draft_via_action` feature has just that effect: +Just like the `bypass_draft` feature flag, it will cause restrictions on modifications of active entities to no longer be enforced. + +### Disable Enforcement by Feature Flag +Alternatively, you can choose to forcefully disable restrictions on how users interact with active instances of draft-enabled entities. To enable this feature, set this feature flag in your configuration: ```json From 3da8ffb2ca56721547f4ca4e7e3873ecd4a5b5d4 Mon Sep 17 00:00:00 2001 From: I548646 Date: Mon, 24 Nov 2025 16:05:52 +0100 Subject: [PATCH 05/10] fix: align renamed flag --- node.js/fiori.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/node.js/fiori.md b/node.js/fiori.md index 6a8241e3e..d3d36b39a 100644 --- a/node.js/fiori.md +++ b/node.js/fiori.md @@ -193,7 +193,7 @@ The CAP Node.js runtime provides two similar but distinct options for bypassing ### Generic `@Common.DraftRoot.NewAction` -By enabling the feature `cds.features.new_draft_via_action`, you can change how new instances of draft-enabled entities get created in the CAP Node.js runtime. +By enabling the feature `cds.fiori.draft_new_action`, you can change how new instances of draft-enabled entities get created in the CAP Node.js runtime. This feature is disabled by default. When you activate this feature, the `@Common.DraftRoot.NewAction` annotation is automatically added to _every_ draft-enabled entity in the background. Additionally, a collection-bound action `draftNew` is added to the entity's runtime model. @@ -205,11 +205,11 @@ No custom handlers can be registered for the `draftNew` action. Instead, such cu ::: By providing a dedicated action that can be called to create a new instance, `POST` requests to the collection path of the entity can now be used differently: -With `cds.features.new_draft_via_action` enabled, `POST` requests to the collection path create an active instance instead of a draft. +With `cds.fiori.draft_new_action` enabled, `POST` requests to the collection path create an active instance instead of a draft. When handling these `POST` requests, the runtime considers an `IsActiveEntity` attribute in the request body to still allow creating a draft instance when `IsActiveEntity: false` is specified explicitly. This change in what the `POST` method does in the context of draft-enabled entities promotes the assumption that all CRUD operations will target the active- rather than the draft-state entity by default. -This is why activating the `cds.features.new_draft_via_action` feature has just that effect: +This is why activating the `cds.fiori.draft_new_action` feature has just that effect: Just like the `bypass_draft` feature flag, it will cause restrictions on modifications of active entities to no longer be enforced. ### Disable Enforcement by Feature Flag From 0ed17f349c0ce7bbfd6eea57b78650df850a431f Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ren=C3=A9=20Jeglinsky?= Date: Tue, 25 Nov 2025 13:56:02 +0100 Subject: [PATCH 06/10] Apply suggestions from code review --- node.js/fiori.md | 14 +++++--------- 1 file changed, 5 insertions(+), 9 deletions(-) diff --git a/node.js/fiori.md b/node.js/fiori.md index d3d36b39a..42a7a650c 100644 --- a/node.js/fiori.md +++ b/node.js/fiori.md @@ -188,17 +188,15 @@ It can occur that inactive drafts are still in the database after the configured ## Bypassing Drafts The draft choreography does not allow active instances of draft-enabled entities to be created or modified directly. -However, when working with technical services that are not exclusively consumed through a GUI, the option to bypass this restriction can be useful. +However, when working with technical services that are not exclusively consumed through a GUI, bypassing this restriction can be useful. The CAP Node.js runtime provides two similar but distinct options for bypassing the regular draft choreography. ### Generic `@Common.DraftRoot.NewAction` By enabling the feature `cds.fiori.draft_new_action`, you can change how new instances of draft-enabled entities get created in the CAP Node.js runtime. This feature is disabled by default. -When you activate this feature, the `@Common.DraftRoot.NewAction` annotation is automatically added to _every_ draft-enabled entity in the background. -Additionally, a collection-bound action `draftNew` is added to the entity's runtime model. -When this annotation is present, Fiori Elements triggers the action referenced by the annotation instead of sending a `POST` request to the collection path to create a new entity. -The runtime rewrites calls to this action internally as a `NEW` event. +When you activate this feature, the runtime automatically adds the `@Common.DraftRoot.NewAction` annotation to _every_ draft-enabled entity in the background and adds a collection-bound action `draftNew` to the entity's runtime model. +When this annotation is present, Fiori Elements triggers the action referenced by the annotation instead of sending a `POST` request to the collection path to create a new entity. The runtime internally rewrites calls to this action as a `NEW` event. :::warning No custom handlers can be registered for the `draftNew` action. Instead, such custom handlers should be registered on the regular `NEW` event. @@ -206,11 +204,9 @@ No custom handlers can be registered for the `draftNew` action. Instead, such cu By providing a dedicated action that can be called to create a new instance, `POST` requests to the collection path of the entity can now be used differently: With `cds.fiori.draft_new_action` enabled, `POST` requests to the collection path create an active instance instead of a draft. -When handling these `POST` requests, the runtime considers an `IsActiveEntity` attribute in the request body to still allow creating a draft instance when `IsActiveEntity: false` is specified explicitly. +When handling these `POST` requests, the runtime considers an `IsActiveEntity` attribute in the request body to allow creating a draft instance when you explicitly specify `IsActiveEntity: false`. -This change in what the `POST` method does in the context of draft-enabled entities promotes the assumption that all CRUD operations will target the active- rather than the draft-state entity by default. -This is why activating the `cds.fiori.draft_new_action` feature has just that effect: -Just like the `bypass_draft` feature flag, it will cause restrictions on modifications of active entities to no longer be enforced. +This change in what the `POST` method does in the context of draft-enabled entities promotes the assumption that all CRUD operations target the active- rather than the draft-state entity by default. Activating the `cds.fiori.draft_new_action` feature produces this effect: like the `bypass_draft` feature flag, it causes the runtime to no longer enforce restrictions on modifications of active entities. ### Disable Enforcement by Feature Flag From 981d9876681e283faf76cdef890fdf8a173dd796 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ren=C3=A9=20Jeglinsky?= Date: Tue, 25 Nov 2025 14:43:11 +0100 Subject: [PATCH 07/10] Apply suggestions from code review --- node.js/fiori.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/node.js/fiori.md b/node.js/fiori.md index 42a7a650c..3c98dc701 100644 --- a/node.js/fiori.md +++ b/node.js/fiori.md @@ -187,19 +187,19 @@ It can occur that inactive drafts are still in the database after the configured ## Bypassing Drafts -The draft choreography does not allow active instances of draft-enabled entities to be created or modified directly. -However, when working with technical services that are not exclusively consumed through a GUI, bypassing this restriction can be useful. +The draft choreography prevents direct creation or modification of active instances of draft-enabled entities. +However, when working with technical services not exclusively consumed through a GUI, bypassing this restriction is useful. The CAP Node.js runtime provides two similar but distinct options for bypassing the regular draft choreography. ### Generic `@Common.DraftRoot.NewAction` -By enabling the feature `cds.fiori.draft_new_action`, you can change how new instances of draft-enabled entities get created in the CAP Node.js runtime. +By enabling the feature `cds.fiori.draft_new_action`, you change how new instances of draft-enabled entities get created in the CAP Node.js runtime. This feature is disabled by default. When you activate this feature, the runtime automatically adds the `@Common.DraftRoot.NewAction` annotation to _every_ draft-enabled entity in the background and adds a collection-bound action `draftNew` to the entity's runtime model. When this annotation is present, Fiori Elements triggers the action referenced by the annotation instead of sending a `POST` request to the collection path to create a new entity. The runtime internally rewrites calls to this action as a `NEW` event. :::warning -No custom handlers can be registered for the `draftNew` action. Instead, such custom handlers should be registered on the regular `NEW` event. +No custom handlers can be registered for the `draftNew` action. Instead, register such custom handlers on the regular `NEW` event. ::: By providing a dedicated action that can be called to create a new instance, `POST` requests to the collection path of the entity can now be used differently: From 78890bdf103356b342d2c5d4daf4d726e9852ad2 Mon Sep 17 00:00:00 2001 From: Rene Jeglinsky Date: Wed, 26 Nov 2025 13:39:12 +0100 Subject: [PATCH 08/10] new titles, small edit, add Config feature --- node.js/fiori.md | 15 ++++++++------- 1 file changed, 8 insertions(+), 7 deletions(-) diff --git a/node.js/fiori.md b/node.js/fiori.md index 3c98dc701..8f028f9b3 100644 --- a/node.js/fiori.md +++ b/node.js/fiori.md @@ -191,24 +191,25 @@ The draft choreography prevents direct creation or modification of active instan However, when working with technical services not exclusively consumed through a GUI, bypassing this restriction is useful. The CAP Node.js runtime provides two similar but distinct options for bypassing the regular draft choreography. -### Generic `@Common.DraftRoot.NewAction` +### Using Annotation -By enabling the feature `cds.fiori.draft_new_action`, you change how new instances of draft-enabled entities get created in the CAP Node.js runtime. +By enabling the feature cds.fiori.draft_new_action:true, you change how new instances of draft-enabled entities get created in the CAP Node.js runtime. This feature is disabled by default. When you activate this feature, the runtime automatically adds the `@Common.DraftRoot.NewAction` annotation to _every_ draft-enabled entity in the background and adds a collection-bound action `draftNew` to the entity's runtime model. When this annotation is present, Fiori Elements triggers the action referenced by the annotation instead of sending a `POST` request to the collection path to create a new entity. The runtime internally rewrites calls to this action as a `NEW` event. -:::warning +:::warning No custom handlers on `draftNew` No custom handlers can be registered for the `draftNew` action. Instead, register such custom handlers on the regular `NEW` event. ::: By providing a dedicated action that can be called to create a new instance, `POST` requests to the collection path of the entity can now be used differently: -With `cds.fiori.draft_new_action` enabled, `POST` requests to the collection path create an active instance instead of a draft. -When handling these `POST` requests, the runtime considers an `IsActiveEntity` attribute in the request body to allow creating a draft instance when you explicitly specify `IsActiveEntity: false`. +With cds.fiori.draft_new_action:true, `POST` requests to the collection path create an active instance instead of a draft. -This change in what the `POST` method does in the context of draft-enabled entities promotes the assumption that all CRUD operations target the active- rather than the draft-state entity by default. Activating the `cds.fiori.draft_new_action` feature produces this effect: like the `bypass_draft` feature flag, it causes the runtime to no longer enforce restrictions on modifications of active entities. +In the context of draft-enabled entities, this change in the `POST` method promotes the assumption that all CRUD operations target the active- rather than the draft-state entity by default. Activating the cds.fiori.draft_new_action:true feature has a similar effect as the cds.fiori.bypass_draft:true feature flag. It allows you to modify active entities without runtime restrictions. -### Disable Enforcement by Feature Flag +When handling `POST` requests with cds.fiori.draft_new_action:true, the runtime considers an `IsActiveEntity` attribute in the request body, to allow creating a draft instance when you explicitly specify `IsActiveEntity: false`. + +### Using Feature Flag Alternatively, you can choose to forcefully disable restrictions on how users interact with active instances of draft-enabled entities. To enable this feature, set this feature flag in your configuration: From a527878b6e1d49c5c560daf760561ab048be9bf5 Mon Sep 17 00:00:00 2001 From: Rene Jeglinsky Date: Wed, 26 Nov 2025 15:08:25 +0100 Subject: [PATCH 09/10] general edit --- node.js/fiori.md | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/node.js/fiori.md b/node.js/fiori.md index 8f028f9b3..2b919dd75 100644 --- a/node.js/fiori.md +++ b/node.js/fiori.md @@ -191,23 +191,26 @@ The draft choreography prevents direct creation or modification of active instan However, when working with technical services not exclusively consumed through a GUI, bypassing this restriction is useful. The CAP Node.js runtime provides two similar but distinct options for bypassing the regular draft choreography. -### Using Annotation +### Using an Action + +By enabling the feature cds.fiori.draft_new_action:true, you create new draft instances through the collection-bound action `draftNew` in the CAP Node.js runtime. That means, sending a `POST` request to the collection path, for example `/Books`, can be used to create a new active entity instance. You can leverage this behavior, for example, when working with technical services. -By enabling the feature cds.fiori.draft_new_action:true, you change how new instances of draft-enabled entities get created in the CAP Node.js runtime. This feature is disabled by default. + +:::details Learn the details of the `draft_new_action` feature: When you activate this feature, the runtime automatically adds the `@Common.DraftRoot.NewAction` annotation to _every_ draft-enabled entity in the background and adds a collection-bound action `draftNew` to the entity's runtime model. When this annotation is present, Fiori Elements triggers the action referenced by the annotation instead of sending a `POST` request to the collection path to create a new entity. The runtime internally rewrites calls to this action as a `NEW` event. +::: :::warning No custom handlers on `draftNew` No custom handlers can be registered for the `draftNew` action. Instead, register such custom handlers on the regular `NEW` event. ::: -By providing a dedicated action that can be called to create a new instance, `POST` requests to the collection path of the entity can now be used differently: -With cds.fiori.draft_new_action:true, `POST` requests to the collection path create an active instance instead of a draft. +With cds.fiori.draft_new_action:true, the `POST` behaves the same as all CRUD operations: they target the active-state rather than the draft-state entity by default. +You still can create a draft instance through a `POST` request to the collection path. When handling `POST` requests the runtime considers an `IsActiveEntity` attribute in the request body. When you explicitly specify `IsActiveEntity: false` a draft instance is created. -In the context of draft-enabled entities, this change in the `POST` method promotes the assumption that all CRUD operations target the active- rather than the draft-state entity by default. Activating the cds.fiori.draft_new_action:true feature has a similar effect as the cds.fiori.bypass_draft:true feature flag. It allows you to modify active entities without runtime restrictions. +Activating the cds.fiori.draft_new_action:true feature has a similar effect as the cds.fiori.bypass_draft:true feature flag. It allows you to modify active entities without runtime restrictions. -When handling `POST` requests with cds.fiori.draft_new_action:true, the runtime considers an `IsActiveEntity` attribute in the request body, to allow creating a draft instance when you explicitly specify `IsActiveEntity: false`. ### Using Feature Flag From 500cd598be0ef410ab3a8b90eedec42eb0538011 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Ren=C3=A9=20Jeglinsky?= Date: Thu, 27 Nov 2025 10:46:56 +0100 Subject: [PATCH 10/10] Apply suggestions from code review --- node.js/fiori.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/node.js/fiori.md b/node.js/fiori.md index 2b919dd75..2361fc58c 100644 --- a/node.js/fiori.md +++ b/node.js/fiori.md @@ -191,7 +191,7 @@ The draft choreography prevents direct creation or modification of active instan However, when working with technical services not exclusively consumed through a GUI, bypassing this restriction is useful. The CAP Node.js runtime provides two similar but distinct options for bypassing the regular draft choreography. -### Using an Action +### Active as Default By enabling the feature cds.fiori.draft_new_action:true, you create new draft instances through the collection-bound action `draftNew` in the CAP Node.js runtime. That means, sending a `POST` request to the collection path, for example `/Books`, can be used to create a new active entity instance. You can leverage this behavior, for example, when working with technical services. @@ -212,7 +212,7 @@ You still can create a draft instance through a `POST` request to the collection Activating the cds.fiori.draft_new_action:true feature has a similar effect as the cds.fiori.bypass_draft:true feature flag. It allows you to modify active entities without runtime restrictions. -### Using Feature Flag +### Specify State Alternatively, you can choose to forcefully disable restrictions on how users interact with active instances of draft-enabled entities. To enable this feature, set this feature flag in your configuration: