50 lines
3.0 KiB
Markdown
50 lines
3.0 KiB
Markdown
## 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
|
|
|