## NITRO-2973

Expose Endpoint to apply/clear a config template

POST \customer\123\document\configuration\(nospeed|partialspeed|fullspeed)

POST \customer\123\transaction\configuration\(nospeed|partialspeed|fullspeed)

Template with the following values

@Edouard Umbreit supply the flag value per conifg

add a tag to record which config has been clicked

…

Following frontend story

Buttons to apply a default config for document and/or transaction

---

This ticket asks to add new endpoints to apply/clear a customer config template. One targeting document configuration,
another targeting transaction configuration.

Once a template has been applied, WsConfigValue with specific keys should have specific values at the customer level.

---

- [x] Jira:NITRO-29723 https://fiscalteam.atlassian.net/browse/NITRO-2973
- [ ] Implementation:
- [x] Pull Request: https://gitea.fteamdev.valuya.be/cghislai/nitro-back/pulls/76
- [x] Active

### Log

2025-06-09T17:29:21.353Z - Gemini updates
- started: Starting to understand the work item and explore the codebase to identify relevant files and existing logic.
- started: Searching for WsConfigValue to understand its structure and usage.
- done: WsConfigValue is a key entity. Now investigating how customer-level configurations are handled.
- started: Investigating existing customer-specific configuration handling, focusing on CustomerConfigKey and CustomerClientUtils.
- done: CustomerConfigKey is an enum used for customer-specific configurations. Existing usage in `TestAppContext.java` and `CustomerClientUtils.java` confirms its relevance. New 'speed' related config keys will likely be added here. Next, I will investigate existing API definitions for customer configurations.
- started: Investigating existing API definitions for customer and configuration controllers in `nitro-domain-api` to understand endpoint structure.
- started: Examining `WsCustomerConfigController.java` and `WsAppConfigurationController.java` for existing configuration endpoints.
- done: WsCustomerConfigController handles specific document and statement PDF composition configurations. WsAppConfigurationController is more generic, dealing with WsConfigValue objects and providing search/create/delete operations for them. The new endpoints will likely be similar to the existing WsCustomerConfigController paths, but for document and transaction 'speed' configurations. I will assume the new endpoints will be added to WsCustomerDocumentController and WsCustomerTransactionController or a new controller. I will also assume that the 'speed' configurations will be represented by new CustomerConfigKey entries. Now, I will define the test cases in Cucumber format.
- started: Defining test cases in Cucumber format for the new endpoints.
- done: Defined test cases in Cucumber format and saved to `nitro-it/src/test/resources/workitems/2025-06-09-NITRO-2973.feature`.
-  Added file nitro-it/src/test/resources/workitems/2025-06-09-NITRO-2973.featurePR: https://gitea.fteamdev.valuya.be/cghislai/nitro-back/pulls/73