oneentry 1.0.155 → 1.0.157

package/README.md

@@ -181,6 +181,25 @@ const api = defineOneEntry('your-url', {
 
 OneEntry SDK supports optional validation of API responses using Zod. This feature is disabled by default and can be enabled for development or critical operations.
 
+### Time Intervals
+
+Attributes of type `timeInterval` return a compact recurrence rule (an anchor date, daily time ranges and repeat flags), not a ready list of slots. The SDK does not expand it eagerly — a single attribute can materialize into megabytes of slots — so resolve it on demand with `expandAttributeTimeIntervals`, passing the window you actually render:
+
+```js
+import { defineOneEntry, expandAttributeTimeIntervals } from 'oneentry'
+
+const { Pages } = defineOneEntry('your-url', { token: 'your-app-token' })
+const page = await Pages.getPageByUrl('booking')
+
+const slots = expandAttributeTimeIntervals(page.attributeValues.interval, {
+    from: '2025-04-01',
+    to: '2025-04-30',
+})
+// [['2025-04-14T09:00:00.000Z', '2025-04-14T10:00:00.000Z'], …]
+```
+
+Also exported: `expandTimeIntervals(schedule, window)` for a single schedule (e.g. a form's `localizeInfos.intervals`), and the `isTimeIntervalAttribute` type guard.
+
 ### Errors
 
 If you want to escape errors inside the sc, leave the "errors" property by default.

package/changelog.md

@@ -1,5 +1,158 @@
 # SDK Change Log
 
+## v.1.0.157
+
+### What's New
+
+- Subscriptions > `ISubscriptionEntity` — new exported type describing an available subscription: `id`, `identifier`, `localizeInfos` (`ILocalizeInfo`), `productIds`, `periodInDays`, `paymentAccountId`, `isUsed`. It backs the corrected return type of `getAllSubscriptions` (see below) and has a matching Zod schema (`SubscriptionEntitySchema` / `SubscriptionsListSchema`).
+
+- Orders > `IOrderByMarkerEntity` — four fields the API already returns are now declared: `fulfillmentStatusIdentifier`, `fulfillmentStatusLocalizeInfos`, `paymentStatusIdentifier`, `paymentStatusLocalizeInfos` (each `null` until the corresponding status is assigned). Response validation drops every key its schema does not describe, so with `validation.enabled` these four were silently stripped from `getOrderByMarkerAndId` and `getAllOrdersByMarker` before reaching the consumer:
+
+  ```ts
+  const order = await Orders.getOrderByMarkerAndId('my_order', 179);
+  order.paymentStatusIdentifier; // "inProgress-payment"
+  order.paymentStatusLocalizeInfos; // { title: "In progress" }
+  ```
+
+- Orders > `IBaseOrdersEntity` — `statusLocalizeInfos` (localized name of the status assigned to the order) is now declared on the `createOrder` / `updateOrderByMarkerAndId` response, which returned it but had it stripped by validation.
+
+- IntegrationCollections > `ICollectionRow` — `langCode` and `formIdentifier` are now declared. Both are returned by the create/update row endpoints (`formIdentifier` on update) and were stripped by validation.
+
+- AuthProvider > `ISignUpEntity` — `attributeSetId` and `attributesSets` are now declared on the `signUp` response, which returned them but had them stripped by validation.
+
+- Products > `IProductSearchResult` and Pages > `IPageSearchResult` — new exported types describing the short card the quick search endpoints return: `{ id, title, pageId }` for products and `{ id, title }` for pages. Both have matching Zod schemas (`ProductSearchResultSchema` / `ProductSearchResponseSchema`, `PageSearchResultSchema` / `PageSearchResponseSchema`), so the quick search response is validated like every other response.
+
+### What's Changed
+
+- **Breaking** — single-file `image` attributes are now unwrapped in **every** module, not only in the few that ran the extra post-processing step. When an `image` attribute holds exactly one file, its `value` is the file object itself (`[img]` → `img`); values with two or more files stay an array, as before.
+
+  Previously the unwrapping lived in `_clearArray`, which ran only after `_dataPostProcess` (products, menus, forms, forms-data, attribute-sets, integration-collections and `Pages.searchPage`) and only looked at the `attributeValues` key. Everywhere else — blocks, all other pages methods, `Products.getProductsEmptyPage`, `Products.getProductBlockById`, admins, discounts, templates, orders, users — the same attribute arrived as a one-element array, so consumers had to branch on the shape. Form `attributes`, form-data fields and nested `additionalFields` were never unwrapped at all.
+
+  The logic now lives in `_normalizeAttr`, which runs on every attribute of every response:
+
+  ```ts
+  const block = await Blocks.getBlockByMarker('promo');
+  // before: block.attributeValues.img.value[0].downloadLink
+  // now:    block.attributeValues.img.value.downloadLink
+  ```
+
+  Code that reads `value[0]` from products or menus is unaffected — those modules already returned the object. Code that reads `value[0]` from blocks, pages, users or orders must drop the index.
+
+- **Breaking** — a single-file `file` attribute is unwrapped like `image`: `value` is the file object itself, and an array only when several files are attached. `groupOfImages` is a collection by definition and always stays an array. `IBodyTypeFile.value` is widened to `IFileValue | IFileValue[]` accordingly.
+
+- **Breaking** — `real` attributes are cast to a number. `integer` and `float` were already normalized, `real` was not, so the same numeric field reached the consumer as `10` or as `"10"` depending on which of the three types it was declared with:
+
+  ```ts
+  const page = await Pages.getPageByUrl('catalog');
+  // before: page.attributeValues.amount.value // "5"
+  // now:    page.attributeValues.amount.value // 5
+  ```
+
+- **Breaking** — numeric normalization now also runs on form attributes and on form-data fields, which were skipped entirely. A `rating` field of an `integer` form attribute is a `number`, not a string. `IBodyTypeStringNumberFloat.value` is widened to `string | number | null` (send a string; responses come back normalized).
+
+- **Breaking** — an attribute with no value is always `null`. The API returns an empty localization map (`{}`) for an unset value, and the SDK passed it through for text-like types while numeric types became `null` — the same "no value" state had three representations. As a side effect, an unset `integer`/`float` no longer becomes `0`: `Number(null)` is `0`, so an explicit `null` from the API used to be reported as a real zero.
+
+- **Breaking** — form `attributes` are sorted by `position`, the way `attributeValues` always were. The API returns form fields unordered (a field with `position: 10` could arrive after `position: 14`), so rendering a form in CMS order required sorting on the consumer side.
+
+- **Breaking** — Subscriptions > `getAllSubscriptions` returns `ISubscriptionEntity[]` instead of `string[]`. The signature was taken from swagger, which declares `GET /api/content/subscriptions` as an array of markers; the endpoint actually returns full subscription objects, so response validation reported `expected string, received object` on every call and the declared type never matched the data. Callers that read markers should switch from the array element to its `identifier` field:
+
+  ```ts
+  const subscriptions = await Subscriptions.getAllSubscriptions();
+  // before: subscriptions // string[]
+  // now:    subscriptions.map((s) => s.identifier)
+  ```
+
+  `getActiveSubscriptions` is unchanged (`string[]`).
+
+- **Breaking (types only)** — `Products.searchProduct` returns `IProductsEntity[] | IProductSearchResult[] | IError` and `Pages.searchPage` returns `IPagesEntity[] | IPageSearchResult[] | IError`. With `traficLimit: true` both methods return the raw quick search response — a short card without `attributeValues`, `localizeInfos`, `blocks` and the rest of the entity — while the signature promised a full entity in both modes, so a consumer reading `attributeValues` in traficLimit mode got `undefined` with no type error. Runtime behaviour is unchanged; narrow by config or by field:
+
+  ```ts
+  const found = await Products.searchProduct('cos');
+  if (Array.isArray(found) && found.length && 'attributeValues' in found[0]) {
+    // IProductsEntity[] — traficLimit is off
+  }
+  ```
+
+- `Pages.searchPage` no longer runs the template lookup over the traficLimit response. Short cards carry no `templateIdentifier`, so the step could never attach anything; the result is identical, minus the pointless pass.
+
+### Bug Fixes
+
+- Methods whose result is just success-or-failure no longer report `true` when the API rejected the request: `Subscriptions.cancelSubscription`, `Subscriptions.recoverSubscriptions`, `Events.subscribeByMarker`, `Events.unsubscribeByMarker`, `Events.subscribeToForm`, `Events.unsubscribeFromForm`.
+
+  With `errors.isShell` enabled — the default — the SDK **returns** the API error instead of throwing it. The shared helper behind these six methods only had a `try/catch`, so nothing ever reached its `catch` and every failure was reported as a success: `cancelSubscription` answered `true` while the API replied `404 "Subscription already inactive"`, and the `IError` half of the declared `Promise<boolean | IError>` was unreachable. The helper now also inspects the returned value and passes the error through:
+
+  ```ts
+  const cancelled = await Subscriptions.cancelSubscription({ marker: 'premium' });
+  // before: true — on 404 and 403 alike
+  // now:    { statusCode: 404, message: 'Subscription already inactive', ... }
+  ```
+
+  The success path is unchanged (`true`), and `isShell: false` still throws. Code that checks these results with `if (result)` must switch to `if (result === true)` — an error object is truthy.
+
+## v.1.0.156
+
+### What's New
+
+- `expandAttributeTimeIntervals(attr, { from, to })` — new top-level export that resolves a whole `timeInterval` attribute into concrete `[start, end]` ISO pairs for a window you choose. This is the one-call replacement for the removed `timeIntervals` field: it walks the attribute's groups and schedules and merges the results (merging matters — deduplication and ordering only hold within a single schedule). Anything that is not a `timeInterval` attribute yields an empty array, so it is safe to call without checking `type` first.
+
+  ```ts
+  import { expandAttributeTimeIntervals } from 'oneentry';
+
+  const slots = expandAttributeTimeIntervals(page.attributeValues.interval, {
+    from: '2025-04-01',
+    to: '2025-04-30',
+  });
+  // [['2025-04-14T09:00:00.000Z', '2025-04-14T10:00:00.000Z'], …]
+  ```
+
+- `expandTimeIntervals(schedule, { from, to })` — new top-level export that resolves a single schedule. Accepts both shapes the API returns: entity schedules (`attributeValues[marker].value[].values[]` on pages, products, blocks and attribute sets) and form schedules (`attributes[].localizeInfos.intervals[]`). Use it when you already hold one schedule — most notably on forms, whose schedules are already typed:
+
+  ```ts
+  const field = form.attributes.find((a) => a.marker === 'booking');
+
+  const slots = (field?.localizeInfos.intervals ?? []).flatMap((schedule) =>
+    expandTimeIntervals(schedule, { from: '2025-05-01', to: '2025-05-31' }),
+  );
+  ```
+
+  Both functions are pure — they do not mutate their input and perform no requests.
+
+- `isTimeIntervalAttribute(attr)` — new exported type guard narrowing an `IAttributeValue` to `ITimeIntervalAttributeValue`. `IAttributeValue.value` is `unknown` because its shape depends on `type`; this guard is what lets you reach the schedules without a cast:
+
+  ```ts
+  const attr = page.attributeValues.interval;
+  if (isTimeIntervalAttribute(attr)) {
+    attr.value[0].values[0].dates; // fully typed
+  }
+  ```
+
+- `ITimeIntervalAttributeValue`, `ITimeIntervalGroup`, `ITimeIntervalEntitySchedule`, `ITimeIntervalWindow` and `TimeIntervalPair` — new exported types covering the whole `timeInterval` payload: the attribute, its groups, an entity schedule, the expansion window and a resolved slot. `ITimeIntervalSchedule` and `IAttributeValue` are now exported for the same reason. The payload previously had no typed representation at all.
+
+### What's Changed
+
+- `ITimeIntervalSchedule` — `range` is typed `string[]` instead of `unknown[]` (it is a pair of ISO dates), and the optional `inEveryWeek` flag is documented; the SDK always read it, but the interface omitted it.
+
+### Bug Fixes
+
+These affect `expandTimeIntervals`, which replaces the removed built-in expansion:
+
+- The expansion horizon is no longer hardcoded. Monthly recurrence stopped exactly 12 months after the anchor and weekly recurrence stopped at the end of the anchor's month, so slots beyond that could not be obtained at all. The window is now the horizon.
+- A schedule with no recurrence flags (`inEveryWeek: false, inEveryMonth: false`) produced no intervals at all — `_processScheduleDates` had no branch for that case. A plain date range now yields slots for every day in it.
+- Weekly recurrence combined with monthly no longer emits dates **before** the schedule's start date. The old branch walked from the 1st of the anchor's month, so a schedule starting Monday 2025-04-14 also emitted 2025-04-07.
+- Weekly recurrence was host-timezone dependent: it computed its end-of-month bound with `getFullYear`/`getMonth` (local time) while every other date operation used UTC, so the result shifted with the machine's timezone. All arithmetic is now UTC.
+- Weekly+monthly recurrence silently dropped months: it advanced the month before pinning the day to the 1st, so an anchor on the 31st overflowed short months and lost 5 of 12 months.
+- Identical intervals are now actually deduplicated. The old code collected into a `Set` of array references, which compares by identity, so duplicates always survived despite the intent.
+- A range with a non-positive `period` no longer hangs. The slot loop never advanced its cursor and spun forever; such ranges are now skipped.
+- Malformed input no longer throws. `_addTimeIntervalsToFormSchedules` dereferenced its argument unguarded (`TypeError` on `undefined`), and both expanders read `dates[0]` / `range[0]` without checking the array existed. `expandTimeIntervals` returns an empty array instead.
+
+### What's Deleted
+
+- **Breaking** — the computed `timeIntervals` field is no longer added to `timeInterval` attribute values. It was injected into every response carrying a `timeInterval` attribute (pages, products, blocks, attribute sets and forms) and materialized a full year of slots regardless of what the caller needed: a single attribute with hourly slots expanded to roughly 2,000 lines of JSON, and finer slot periods reached megabytes — enough to blow past framework data-cache limits. The field was never declared in any interface or Zod schema, so TypeScript consumers could only reach it through a cast.
+
+  Migrate by calling `expandAttributeTimeIntervals(attr, window)` with the window you actually render. The source data it expands (`dates`/`range`, `times`/`intervals`, `inEveryWeek`, `inEveryMonth`) is unchanged and still on every schedule, so nothing is lost — it is now resolved on demand instead of eagerly, and the compact rule is what gets cached.
+
+- `_addTimeIntervalsToSchedules` and `_addTimeIntervalsToFormSchedules` — removed from every module. Despite the `_` prefix these were public and callable (e.g. `Pages._addTimeIntervalsToSchedules`). Use `expandTimeIntervals`.
+
 ## v.1.0.155
 
 ### What's New
@@ -247,7 +400,7 @@
 
 - Discounts > `getAllDiscounts` — removed `'PERSONAL_BONUS'` from type filter parameter.
 
-- Forms > `IFormsEntity` — type narrowed to `'order' | 'sing_in_up' | 'collection' | 'data' | 'rating'`, removed `moduleFormConfigs` field.
+- Forms > `IFormsEntity` — type narrowed to `'order' | 'sign_in_up' | 'collection' | 'data' | 'rating'`, removed `moduleFormConfigs` field.
 
 - Products > `getProductsEmptyPage` — changed from GET to POST, added `body` parameter, return type changed to `IAggregatedProductGroup[]`.
 

package/dist/attribute-sets/attributeSetsApi.js

@@ -50,7 +50,7 @@ class AttributesSetsApi extends asyncModules_1.default {
         const result = await this._fetchGet(`?` + this._queryParamsToString(query));
         // Validate response if validation is enabled
         const validated = this._validateResponse(result, attributeSetsSchemas_1.AttributeSetsResponseSchema);
-        return this._dataPostProcess(validated, langCode);
+        return this._normalizeData(validated, langCode);
     }
     /**
      * Getting all attributes with data from the attribute set.
@@ -65,7 +65,7 @@ class AttributesSetsApi extends asyncModules_1.default {
         const result = await this._fetchGet(`/${marker}/attributes?langCode=${langCode}`);
         // Validate response if validation is enabled
         const validated = this._validateResponse(result, attributeSetsSchemas_1.AttributesArrayResponseSchema);
-        return this._dataPostProcess(validated, langCode);
+        return this._normalizeData(validated, langCode);
     }
     /**
      * Get a single attribute with data from the attribute sets.
@@ -81,7 +81,7 @@ class AttributesSetsApi extends asyncModules_1.default {
         const result = await this._fetchGet(`/${setMarker}/attributes/${attributeMarker}?langCode=${langCode}`);
         // Validate response if validation is enabled
         const validated = this._validateResponse(result, attributeSetsSchemas_1.AttributeEntitySchema);
-        return this._dataPostProcess(validated, langCode);
+        return this._normalizeData(validated, langCode);
     }
     /**
      * Getting a single object from a set of attributes by marker.
@@ -96,7 +96,7 @@ class AttributesSetsApi extends asyncModules_1.default {
         const result = await this._fetchGet(`/marker/${marker}?langCode=${langCode}`);
         // Validate response if validation is enabled
         const validated = this._validateResponse(result, attributeSetsSchemas_1.AttributeSetEntitySchema);
-        return this._dataPostProcess(validated, langCode);
+        return this._normalizeData(validated, langCode);
     }
 }
 exports.default = AttributesSetsApi;

package/dist/attribute-sets/attributeSetsInterfaces.d.ts

@@ -82,7 +82,7 @@ type AttributeType = 'string' | 'text' | 'textWithHeader' | 'integer' | 'real' |
  * Represents an attribute set entity.
  * @interface IAttributesSetsEntity
  * @property {AttributeType} type - Attribute type. Example: "string", "text", "integer", "etc".
- * @property {unknown} [value] - Value of the attribute, which can be of any type.
+ * @property {unknown} [value] - Value of the attribute, normalized the same way as an entity attribute value: `number | null` for numeric types, the file object itself for a single-file `image`/`file`, `null` when the attribute carries no value.
  * @property {unknown} initialValue - Initial value of the attribute.
  * @property {string} marker - Textual identifier of the attribute (marker). Example: "color", "size", "etc".
  * @property {number} position - Position number for sorting. Example: 1.

package/dist/auth-provider/authProviderSchemas.d.ts

@@ -26,6 +26,8 @@ export declare const SignUpResponseSchema: z.ZodObject<{
     isDeleted: z.ZodOptional<z.ZodBoolean>;
     state: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodAny>>;
     rating: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
+    attributeSetId: z.ZodOptional<z.ZodNullable<z.ZodNumber>>;
+    attributesSets: z.ZodOptional<z.ZodRecord<z.ZodString, z.ZodUnknown>>;
 }, z.core.$strip>;
 /**
  * Auth response schema (login/refresh)

package/dist/auth-provider/authProviderSchemas.js

@@ -30,6 +30,8 @@ exports.SignUpResponseSchema = zod_1.z.object({
     isDeleted: zod_1.z.boolean().optional(),
     state: zod_1.z.record(zod_1.z.string(), zod_1.z.any()).optional(),
     rating: zod_1.z.record(zod_1.z.string(), zod_1.z.unknown()).optional(),
+    attributeSetId: zod_1.z.number().nullable().optional(),
+    attributesSets: zod_1.z.record(zod_1.z.string(), zod_1.z.unknown()).optional(),
 });
 /**
  * Auth response schema (login/refresh)

package/dist/auth-provider/authProvidersInterfaces.d.ts

@@ -268,6 +268,8 @@ interface IOauthData {
  * @property {boolean} [isDeleted] - Whether the entity is deleted. Example: false.
  * @property {Record<string, unknown>} [state] - Additional state information. Example: {}.
  * @property {IRating} [rating] - Rating data.
+ * @property {number | null} [attributeSetId] - Identifier of the attribute set attached to the user, or null when none is attached. Example: null.
+ * @property {Record<string, unknown>} [attributesSets] - Attribute sets attached to the user, keyed by marker; empty object when none. Example: {}.
  * @description This interface defines the structure of a sign-up entity.
  */
 interface ISignUpEntity {
@@ -285,6 +287,8 @@ interface ISignUpEntity {
     isDeleted?: boolean;
     state?: Record<string, unknown>;
     rating?: IRating;
+    attributeSetId?: number | null;
+    attributesSets?: Record<string, unknown>;
 }
 /**
  * Interface representing a code entity used for user registration or verification processes.

package/dist/base/asyncModules.d.ts

@@ -15,6 +15,17 @@ export default abstract class AsyncModules extends SyncModules {
      * @description Constructor initializes the AsyncModules with a given state.
      */
     protected constructor(state: StateModule);
+    /**
+     * Detects an API error returned as a value instead of being thrown.
+     *
+     * With `isShell` enabled (the default) `browserResponse` returns the error
+     * body — and a caught exception — instead of throwing, so a failed request
+     * is indistinguishable from a successful one by control flow alone.
+     * @param {unknown} value - Value returned by a request.
+     * @returns {boolean} True when the value is an API error (statusCode >= 400) or a thrown error object.
+     * @description Recognizes both the OneEntry error body and errors caught by browserResponse (e.g. a network failure).
+     */
+    protected _isErrorResponse(value: unknown): value is IError;
     /**
      * Validates API response against a Zod schema (optional)
      * @param {unknown} data - The data to validate
@@ -59,8 +70,13 @@ export default abstract class AsyncModules extends SyncModules {
      *
      * Several endpoints (cancel/recover subscription, subscribe/unsubscribe to
      * events) return no useful body — callers only care whether the request
-     * succeeded. This helper resolves to `true` on success and to the caught
-     * error (as IError) on failure, centralizing the repeated try/catch.
+     * succeeded. This helper resolves to `true` on success and to the error
+     * (as IError) on failure, centralizing the repeated try/catch.
+     *
+     * The returned value has to be inspected as well: with `isShell` enabled
+     * (the default) browserResponse returns the API error instead of throwing
+     * it, so relying on the catch alone would report every failed call — a 404
+     * from cancelSubscription, a 403 from recoverSubscriptions — as a success.
      * @param {() => Promise<unknown>} request - Thunk performing the fetch call.
      * @returns {Promise<boolean | IError>} `true` on success, IError on failure.
      */

package/dist/base/asyncModules.js

@@ -20,6 +20,26 @@ class AsyncModules extends syncModules_1.default {
         this.state = state;
         this._url = this.state.url;
     }
+    /**
+     * Detects an API error returned as a value instead of being thrown.
+     *
+     * With `isShell` enabled (the default) `browserResponse` returns the error
+     * body — and a caught exception — instead of throwing, so a failed request
+     * is indistinguishable from a successful one by control flow alone.
+     * @param {unknown} value - Value returned by a request.
+     * @returns {boolean} True when the value is an API error (statusCode >= 400) or a thrown error object.
+     * @description Recognizes both the OneEntry error body and errors caught by browserResponse (e.g. a network failure).
+     */
+    _isErrorResponse(value) {
+        if (value instanceof Error) {
+            return true;
+        }
+        return (value !== null &&
+            typeof value === 'object' &&
+            'statusCode' in value &&
+            typeof value.statusCode === 'number' &&
+            value.statusCode >= 400);
+    }
     /**
      * Validates API response against a Zod schema (optional)
      * @param {unknown} data - The data to validate
@@ -33,11 +53,7 @@ class AsyncModules extends syncModules_1.default {
             return data;
         }
         // Skip validation for error responses (statusCode indicates API error)
-        if (data !== null &&
-            typeof data === 'object' &&
-            'statusCode' in data &&
-            typeof data.statusCode === 'number' &&
-            data.statusCode >= 400) {
+        if (this._isErrorResponse(data)) {
             return data;
         }
         // Use strict or safe validation based on config
@@ -109,14 +125,22 @@ class AsyncModules extends syncModules_1.default {
      *
      * Several endpoints (cancel/recover subscription, subscribe/unsubscribe to
      * events) return no useful body — callers only care whether the request
-     * succeeded. This helper resolves to `true` on success and to the caught
-     * error (as IError) on failure, centralizing the repeated try/catch.
+     * succeeded. This helper resolves to `true` on success and to the error
+     * (as IError) on failure, centralizing the repeated try/catch.
+     *
+     * The returned value has to be inspected as well: with `isShell` enabled
+     * (the default) browserResponse returns the API error instead of throwing
+     * it, so relying on the catch alone would report every failed call — a 404
+     * from cancelSubscription, a 403 from recoverSubscriptions — as a success.
      * @param {() => Promise<unknown>} request - Thunk performing the fetch call.
      * @returns {Promise<boolean | IError>} `true` on success, IError on failure.
      */
     async _fetchBoolean(request) {
         try {
-            await request();
+            const result = await request();
+            if (this._isErrorResponse(result)) {
+                return result;
+            }
             return true;
         }
         catch (e) {

package/dist/base/syncModules.d.ts

@@ -88,136 +88,35 @@ export default abstract class SyncModules {
      */
     protected _normalizePostBody(body: any, langCode?: string): any;
     /**
-     * Clears arrays within the data structure.
+     * Normalizes the value of a single attribute in place.
      *
-     * Traverses the data and fixes a specific edge case with image attributes:
-     * when an `image` attribute has a single-element array in `value`,
-     * the API returns an array but consumers expect a plain object.
-     * In that case `value` is unwrapped: `[img]` → `img`.
+     * Applies the three type-driven fixes the API response needs, so that an
+     * attribute of a given type always reaches the consumer in the same shape,
+     * no matter which collection it arrived in:
      *
-     * For all other keys the method recursively copies the structure unchanged.
-     * @param {Record<string, any>} data - The data to clear.
-     * @returns {any} Cleared data.
+     * 1. **Single-file values** (`image`, `file`) — the API always sends an array,
+     * even for one file: `[img]` → `img`. Multi-file values and `groupOfImages`
+     * (a collection by definition) stay an array.
+     * 2. **Empty values** — an attribute with no value comes back as an empty
+     * localization map `{}`; it is replaced with `null`, the same marker the
+     * numeric branch already produced.
+     * 3. **Numbers** (`integer`, `float`, `real`) — cast to a JS number; anything
+     * that is not a number (including an empty value) becomes `null`.
+     * @param {any} attr - The attribute object to normalize in place.
      */
-    protected _clearArray(data: Record<string, any>): any;
+    private _normalizeAttrValue;
     /**
      * Sorts attributes by their positions.
      *
-     * The API returns attributes as an object `{ marker: AttrObject }`.
-     * Each attribute has a `position` field. The method rebuilds the object
-     * with keys sorted by ascending `position` so that the display order
-     * matches the order defined in the CMS.
-     * @param {any} data - The data containing attributes.
-     * @returns {any} Sorted attributes.
+     * Each attribute has a `position` field, and the API returns them in no
+     * particular order. The method rebuilds the collection sorted by ascending
+     * `position`, so the display order matches the order defined in the CMS.
+     * Both container shapes the API uses are handled: an object keyed by marker
+     * (`attributeValues`) and an array (form `attributes`).
+     * @param {any} data - The attributes collection to sort.
+     * @returns {any} Sorted attributes, in the same container shape.
      */
     protected _sortAttributes: (data: any) => any;
-    /**
-     * Adds a specified number of days to a date.
-     * @param {Date} date - The initial date.
-     * @param {number} days - The number of days to add.
-     * @returns {any} The new date with added days.
-     */
-    protected _addDays(date: Date, days: number): any;
-    /**
-     * Common logic for processing schedule dates (weekly, monthly, or both).
-     *
-     * Abstracts date iteration for three scheduling modes:
-     *
-     * - **`inEveryWeek` only**: starting from the start date, generates dates
-     * with a 7-day step until the end of the current month.
-     *
-     * - **`inEveryMonth` only**: pins the day-of-month from the start date
-     * and repeats it for each of the next 12 months. If the month does not
-     * have that day (e.g. Feb 31), the iteration is skipped.
-     *
-     * - **`inEveryWeek` + `inEveryMonth`**: for each of the next 12 months finds
-     * the first occurrence of the target weekday (from the start date), then
-     * iterates all occurrences of that weekday in the month with a 7-day step.
-     *
-     * `processDate(currentDate)` is called for every resolved date.
-     * @param {Date} date - The date for which to process intervals.
-     * @param {object} config - Configuration for schedule repetition.
-     * @param {boolean} config.inEveryWeek - Whether to repeat weekly.
-     * @param {boolean} config.inEveryMonth - Whether to repeat monthly.
-     * @param {(currentDate: Date) => void} processDate - Callback function to process each date.
-     */
-    protected _processScheduleDates(date: Date, config: {
-        inEveryWeek: boolean;
-        inEveryMonth: boolean;
-    }, processDate: (currentDate: Date) => void): void;
-    /**
-     * Generates intervals for a specific date based on a schedule.
-     *
-     * For each date resolved by `_processScheduleDates`, iterates over
-     * the `schedule.times` array of time ranges. Each range is a pair
-     * `[startTime, endTime]` with `{ hours, minutes }` fields.
-     * Creates an ISO interval `[start.toISOString(), end.toISOString()]`
-     * and adds it to `utcIntervals` (Set deduplicates automatically).
-     * @param {Date} date - The date for which to generate intervals.
-     * @param {object} schedule - The schedule defining the intervals.
-     * @param {boolean} schedule.inEveryWeek  - The number of weeks between intervals.
-     * @param {any[]} schedule.times - The times for each interval.
-     * @param {boolean} schedule.inEveryMonth - The month intervals for each interval.
-     * @param {Set<Array<string>>} utcIntervals - A set to store unique intervals.
-     */
-    protected _generateIntervalsForDate(date: Date, schedule: {
-        inEveryWeek: boolean;
-        times: any[];
-        inEveryMonth: boolean;
-    }, utcIntervals: Set<Array<string>>): void;
-    /**
-     * Adds time intervals to schedules.
-     *
-     * Accepts an array of schedule groups (structure of `timeInterval` attributes
-     * for pages/products). For each group iterates over `values` — the set of
-     * concrete schedules. Each schedule contains a date range `dates[0..1]`.
-     *
-     * If both boundaries are equal (`isSameDay`), intervals are generated only
-     * for that single date. Otherwise — for every day in the range inclusive.
-     *
-     * The result (`schedule.timeIntervals`) is a sorted array of ISO pairs,
-     * ready to pass to UI components.
-     * @param {any[]} schedules - The schedules to process.
-     * @returns {any} Schedules with added time intervals.
-     */
-    _addTimeIntervalsToSchedules(schedules: any[]): any;
-    /**
-     * Generates intervals for a specific date for form schedules.
-     *
-     * Unlike `_generateIntervalsForDate`, time ranges here have a different shape:
-     * each `timeInterval` contains `start`, `end` and `period`
-     * (slot length in minutes). The method slices the [start, end) window into
-     * fixed-length slots of `period` minutes:
-     *
-     * start=09:00, end=12:00, period=30 → [09:00–09:30], [09:30–10:00], …, [11:30–12:00]
-     *
-     * Generation stops if the next slot would exceed `end`.
-     * Each slot is added to `utcIntervals` (Set deduplicates automatically).
-     * @param {Date} date - The date for which to generate intervals.
-     * @param {object} interval - The interval configuration.
-     * @param {boolean} interval.inEveryWeek - Indicates whether the schedule is weekly.
-     * @param {boolean} interval.inEveryMonth - Indicates whether the schedule is monthly.
-     * @param {any[]} timeIntervals - The time intervals to process.
-     * @param {Set<Array<string>>} utcIntervals - A set to store unique intervals.
-     */
-    protected _generateIntervalsForFormDate(date: Date, interval: {
-        inEveryWeek: boolean;
-        inEveryMonth: boolean;
-    }, timeIntervals: any[], utcIntervals: Set<Array<string>>): void;
-    /**
-     * Adds time intervals to form schedules (different structure).
-     *
-     * Same as `_addTimeIntervalsToSchedules` but for `timeInterval` attributes
-     * in **forms** (different API data structure):
-     * - `interval.range[0..1]` instead of `schedule.dates[0..1]`
-     * - `interval.intervals` — array of time ranges with slots (`period`)
-     * instead of `[startTime, endTime]` pairs
-     *
-     * Result is written to `interval.timeIntervals`.
-     * @param {any[]} intervals - The intervals to process.
-     * @returns {any} Intervals with added time intervals.
-     */
-    _addTimeIntervalsToFormSchedules(intervals: any[]): any;
     /**
      * Transforms additionalFields from array to object keyed by marker.
      *
@@ -234,36 +133,34 @@ export default abstract class SyncModules {
      *
      * Handles three different attribute formats returned by the API:
      *
-     * **1. `attributeValues`** — attributes of pages, products and other entities.
-     * Contains an object `{ marker: AttrObject }`. For each attribute:
-     * - `_normalizeAdditionalFields` is called;
-     * - numeric types (`integer`, `float`) are cast to a JS number (or `null`);
-     * - `timeInterval` attributes are enriched with computed `timeIntervals`;
-     * - the whole object is re-sorted by `position`.
+     * All three go through the same steps, so an attribute of a given type looks
+     * the same whichever collection it arrived in:
+     * - `_normalizeAdditionalFields` turns nested fields into a marker map;
+     * - `_normalizeAttrValue` unwraps single-file values, empties to `null` and
+     * casts numbers;
+     * - the collection is re-sorted by `position`.
+     *
+     * **1. `attributeValues`** — attributes of pages, products and other entities,
+     * an object `{ marker: AttrObject }`.
+     *
+     * **2. `attributes`** — form attributes, an array (or a marker map on some
+     * endpoints); form-only boolean flags (`isLogin`, `isSignUp`, notifications)
+     * are additionally coerced from `null` to `false`.
      *
-     * **2. `attributes`** — form attributes (different API structure).
-     * Same `additionalFields` and `timeInterval` processing,
-     * but numbers are not normalized here (commented out — logic differs).
+     * **3. `type`** — a standalone attribute: an attribute-set entry, a form-data
+     * field or a nested `additionalFields` entry. Same transformations, but there
+     * is no collection to sort.
      *
-     * **3. `type`** — a single attribute from an attribute set.
-     * Same transformations as in case 1, but without sorting.
+     * `timeInterval` attributes are left exactly as the API returned them — a
+     * compact recurrence rule. Resolving one into concrete slots is the caller's
+     * job, via `expandTimeIntervals`: the rule is open-ended, so only the caller
+     * knows how wide a window it needs.
      *
      * If none of the keys are found — data is returned unchanged.
      * @param {any} data - The data to normalize.
      * @returns {any} Normalized attributes.
      */
     protected _normalizeAttr(data: any): any;
-    /**
-     * Processes data after fetching or receiving it.
-     *
-     * Final post-processing of the API response: first unwraps localized fields
-     * (`_normalizeData`), then fixes single-element image attributes
-     * (`_clearArray`). Called at the end of every fetch method.
-     * @param {any} data - The data to process.
-     * @param {any} [langCode] - The language code for processing.
-     * @returns {any} Processed data.
-     */
-    protected _dataPostProcess(data: any, langCode?: string): any;
     /**
      * Sets the access token in the state.
      * @param {string} accessToken - The access token to set.