Customer Controlled Configuration (CCC)
Table of Contents
Configuration
JSON Schema Definition
The configuration schema for CCC is defined in hiiretail-json-schema-registry repo. This schema specifies the required structure, allowed values, and validation rules for CCC configuration.
Configuring CCC in Common Clan Repo
To set up CCC, you must configure the actual configuration in the experience-selfcheckout-common repo. This involves:
- Referencing the JSON schema from hiiretail-json-schema-registry Repo.
- Setting default values for the configuration parameters.
- Defining the configuration level based on the available hierarchy levels.
Below is an example of the YAML configuration:
- name: colors-config
version: v1
display-name: Color Coding Configuration
schema-location: https://raw.githubusercontent.com/extenda/hiiretail-json-schema-registry/refs/heads/master/customer-config/attendant-app/att.colors-config.v1.json
max-tree-depth: business-units/*/workstations/*
default-value:
colors:
primary:
name: "Primary Color"
value: "#1A73E8"
secondary:
name: "Secondary Color"
value: "#efefef"
Available Configuration Levels
The CCC configuration applies at different hierarchical levels. The max-tree-depth property determines the maximum level at which a configuration setting is applied.
| Level | Key Format | Description |
|---|---|---|
global | tenants/all | Shared by all tenants. |
tenant | tenants/self | Specific to a single tenant. |
business unit group | business-unit-groups/* | Applies to a group of business units. |
business unit | business-units/* | Configuration specific to a single business unit. |
workstation | business-units/*/workstations/* | Configuration for an individual workstation. |
Note:
Themax-tree-depthproperty determines how deeply a configuration is inherited across levels.
Usage
Feature Toggle
The feature is toggled via a feature flag: enable.ccc.
Setting Configurations
Configuration values are set through the API based on a specified schema.
Implemented configurations
Alert icons
1. Icon Specifications
- Shape: Round
- Format: PNG
- Background: None (transparent)
- Sizes (Required):
- Small: 22x22 pixels
- Medium: 44x44 pixels
- Large: 66x66 pixels
- Reason for Three Sizes: Different devices have varying pixel densities (DPI), so multiple resolutions ensure that icons appear sharp and correctly scaled across all screens.
2. Naming Convention & Unique ID Management
- The unique icon ID for all alert icons is predefined as
alerts_icon. - Clients must use this exact ID and are not allowed to modify or define their own.
3. Configuration in CCC
Each alert icon must be defined in the CCC configuration as follows:
"alerts_icon": {
"name": "Alerts Icon (Assistance requests)",
"url": "[server_url]/alerts_icon.png",
"url@2x": "[server_url]/alerts_icon@2x.png",
"url@3x": "[server_url]/alerts_icon@3x.png"
}
alerts_iconis the mandatory unique ID for all alert icons.nameis a short descriptive name that must remain unchanged.urlfields indicate the hosted image locations.
4. Server URL Completion Requirement from TENANT
- The placeholder
[server_url]must be replaced with the actual host server URL. - The correct server structure and identification must be followed to ensure proper access to the icons.
- Clients must not alter the file naming structure (alerts_icon.png, alerts_icon@2x.png, alerts_icon@3x.png).
By enforcing these guidelines, we ensure uniformity, control, and seamless integration of alert icons.
5. API requests for configuring values
Set values
Permission required["ccc.configuration.update"]
curl --location --request PUT 'https://ccc-api.retailsvc.com/api/v1/config/att.icons-config.v1/values/tenant' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer token' \
--data-raw '{
"value": {
"icons": {
"alerts_icon": {
"name": "Alerts Icon (Assistance requests)",
"url": "[server_url]/alerts_icon.png",
"url@2x": "[server_url]/alerts_icon@2x.png",
"url@3x": "[server_url]/alerts_icon@3x.png"
}
}
}
}'
Update values
Permission required["ccc.configuration.update"]
curl --location --request PATCH 'https://ccc-api.retailsvc.com/api/v1/config/att.icons-config.v1/values/tenant?replaceExistingPatch=false&calculateDiff=false&dryRun=false' \
--header 'Content-Type: application/json' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer token' \
--data-raw '{
"value": {
"icons": {
"alerts_icon": {
"name": "Alerts Icon (Assistance requests)",
"url": "[server_url]/alerts_icon.png",
"url@2x": "[server_url]/alerts_icon@2x.png",
"url@3x": "[server_url]/alerts_icon@3x.png"
}
}
}
}'
Get configured values
Permission required["ccc.configuration.get"]
curl --location 'https://ccc-api.retailsvc.com/api/v1/config/att.icons-config.v1/values/tenant?tags=%3Cstring%3E&tags=%3Cstring%3E&getPatch=false' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer token'
Delete configured values
Permission required["ccc.configuration.delete"]
curl --location --request DELETE 'https://ccc-api.retailsvc.com/api/v1/config/att.icons-config.v1/values/tenant' \
--header 'Accept: application/json' \
--header 'Authorization: Bearer token'
Workstations status colors
1. Naming Convention
- Status colors must be defined using the prefix
status-followed by the specific status type. - Example valid names:
status-active,status-inactive,status-error,status-imported.
2. Valid Workstation Statuses
The following statuses are valid and must adhere to the naming convention status-[status type]:
- Active:
status-active - Closed:
status-closed - Idle:
status-idle - Error:
status-error - Payment:
status-payment - Finalized:
status-finalized - Imported:
status-imported - Cancelled:
status-cancelled
3. Configuration Format
Each status type is associated with a predefined hex color code, for example:
- Active:
#28A745 - Inactive:
#6C757D - Error:
#DC3545 - Imported:
#FFC107
By enforcing this structure, we maintain uniformity and clarity in workstation status displays.