Scott.Idem/OSIT-AE-App-Svelte
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feat: Migrate ESLint to flat config and resolve initial linting errors

Browse Source 
Migrated the ESLint configuration to the new flat config format ()
and addressed several initial linting errors.

Key changes include:
- Updated ESLint configuration to treat  as warnings instead of errors.
- Fixed  errors in  by declaring  and .
- Corrected  error in  by using  instead of an out-of-scope .
- Resolved  error in  by replacing the undefined  directive with the  component.
- Addressed  errors in  by replacing  with  and  with .
- Fixed  errors in  by importing necessary modules (, , ) and adding missing props (, , , , ).
This commit is contained in:
Scott Idem
2025-11-17 18:46:54 -05:00
parent b99e85f1db
commit 7e1eaba3bc
374 changed files with 95654 additions and 93952 deletions
Download Patch File Download Diff File Expand all files Collapse all files

94
DATA_STRUCTURES.md
View File

@@ -5,68 +5,86 @@ This document outlines the key data structures and their properties used within
## 1. Object Properties and Fields
### 1.1. Core Standard Fields
These fields are expected to be present in most Aether objects, providing a consistent base structure.
* `id`: Primary key for an object (internal use, often a UUID).
* `id_random`: Randomly generated ID for an object (often used for external exposure or URL parameters).
* `<object_type>_id_random`: Specific random ID for an object (e.g., `person_id_random`).
* `code`: Short, unique identifier.
* `name`: Display name.
* `enable`: Boolean for active/inactive status.
* `hide`: Boolean for visibility.
* `priority`: Numeric value for ordering.
* `sort`: Numeric value for ordering.
* `group`: Categorization string.
* `notes`: General notes/comments.
* `created_on`: Timestamp of creation.
* `updated_on`: Timestamp of last update.
- `id`: Primary key for an object (internal use, often a UUID).
- `id_random`: Randomly generated ID for an object (often used for external exposure or URL parameters).
- `<object_type>_id_random`: Specific random ID for an object (e.g., `person_id_random`).
- `code`: Short, unique identifier.
- `name`: Display name.
- `enable`: Boolean for active/inactive status.
- `hide`: Boolean for visibility.
- `priority`: Numeric value for ordering.
- `sort`: Numeric value for ordering.
- `group`: Categorization string.
- `notes`: General notes/comments.
- `created_on`: Timestamp of creation.
- `updated_on`: Timestamp of last update.
### 1.2. Special Use Fields
Fields with specific purposes or conditional usage across different object types.
* `for_type`: Indicates the type of object this object is linked to (e.g., 'account', 'event').
* `for_id`: The ID of the object this object is linked to.
* `archive_on`: Timestamp indicating when an object was archived.
* `passcode`: A password or access code associated with an object.
* `external_id`: An identifier from an external system.
- `for_type`: Indicates the type of object this object is linked to (e.g., 'account', 'event').
- `for_id`: The ID of the object this object is linked to.
- `archive_on`: Timestamp indicating when an object was archived.
- `passcode`: A password or access code associated with an object.
- `external_id`: An identifier from an external system.
### 1.3. Configuration and JSON Fields
Fields designed to store structured data in JSON format.
* `cfg_json`: Configuration data for an object, stored as a JSON string.
* `data_json`: General purpose data for an object, stored as a JSON string.
* `linked_li_json`: A list of linked items, stored as a JSON string.
- `cfg_json`: Configuration data for an object, stored as a JSON string.
- `data_json`: General purpose data for an object, stored as a JSON string.
- `linked_li_json`: A list of linked items, stored as a JSON string.
### 1.4. Special Generated Fields (Client-side)
These fields are generated on the client-side, primarily for facilitating UI logic, such as sorting. They are not typically stored in the backend database.
* `tmp_sort_1`: Temporary sort field 1.
* `tmp_sort_2`: Temporary sort field 2.
* `tmp_sort_3`: Temporary sort field 3.
- `tmp_sort_1`: Temporary sort field 1.
- `tmp_sort_2`: Temporary sort field 2.
- `tmp_sort_3`: Temporary sort field 3.
### 1.5. Future Standard Fields
A list of potential future standard fields, often prefixed with `obj_`. These are conceptual and represent planned expansions to the data model.
* `obj_id`, `obj_ext_uid`, `obj_ext_id`, `obj_import_id`, `obj_code`, `obj_account_id`, `obj_passcode`, `obj_type`, `obj_type_ver_id`, `obj_name`, `obj_summary`, `obj_outline`, `obj_description`, `obj_enable`, `obj_enable_on`, `obj_archive_on`, `obj_hide`, `obj_priority`, `obj_sort`, `obj_group`, `obj_cfg_json`, `obj_notes`, `obj_created_on`, `obj_updated_on`.
- `obj_id`, `obj_ext_uid`, `obj_ext_id`, `obj_import_id`, `obj_code`, `obj_account_id`, `obj_passcode`, `obj_type`, `obj_type_ver_id`, `obj_name`, `obj_summary`, `obj_outline`, `obj_description`, `obj_enable`, `obj_enable_on`, `obj_archive_on`, `obj_hide`, `obj_priority`, `obj_sort`, `obj_group`, `obj_cfg_json`, `obj_notes`, `obj_created_on`, `obj_updated_on`.
## 2. Data Sorting
Standardized sorting orders are applied across various data lists to ensure consistent presentation.
* **Default/General Sorting:** `group > priority > sort > updated_on/created_on`
* **Specific Sorting (e.g., for time-based events):** `type > start_date/time > code or name`
- **Default/General Sorting:** `group > priority > sort > updated_on/created_on`
- **Specific Sorting (e.g., for time-based events):** `type > start_date/time > code or name`
## 3. Data Storage Mechanisms
### 3.1. Local Storage
Used for client-side persistence of various application states and configurations.
* `api`: Stores API-related settings and tokens.
* `app`: Stores global application settings and preferences.
* `core`: Stores settings and data specific to core modules.
* `<module>`: Stores settings and data specific to extended modules (e.g., `journals`, `events`).
* `<custom>`: Stores settings and data specific to custom modules (e.g., `idaa`).
- `api`: Stores API-related settings and tokens.
- `app`: Stores global application settings and preferences.
- `core`: Stores settings and data specific to core modules.
- `<module>`: Stores settings and data specific to extended modules (e.g., `journals`, `events`).
- `<custom>`: Stores settings and data specific to custom modules (e.g., `idaa`).
### 3.2. IndexedDB (Dexie.js)
Used for more structured client-side data storage, often for caching, offline capabilities, and larger datasets.
* `ae_core_db`: The primary Dexie database instance for core application data.
* `<module>`: Module-specific database instances (e.g., `db_journals` for journal data).
* `<custom>`: Custom module-specific database instances (none currently defined, but reserved for future use).
- `ae_core_db`: The primary Dexie database instance for core application data.
- `<module>`: Module-specific database instances (e.g., `db_journals` for journal data).
- `<custom>`: Custom module-specific database instances (none currently defined, but reserved for future use).
### 3.3. IndexedDB LiveQuery Usage
Dexie's `liveQuery` is used to provide reactive data streams from IndexedDB.
* `lq__xyz_obj`: Represents a read-only liveQuery result for a single object.
* `lqw__xyz_obj`: Represents a writable liveQuery result, typically used for forms and data binding.
* **Note:** When using `lqw__xyz_obj`, developers must carefully manage updates to avoid conflicts with the underlying liveQuery and ensure data integrity.
- `lq__xyz_obj`: Represents a read-only liveQuery result for a single object.
- `lqw__xyz_obj`: Represents a writable liveQuery result, typically used for forms and data binding.
- **Note:** When using `lqw__xyz_obj`, developers must carefully manage updates to avoid conflicts with the underlying liveQuery and ensure data integrity.