2 Commits

Author SHA1 Message Date
26ba015b75 +gitignore 2026-01-22 23:25:29 +03:00
49129d3e86 fix error 2026-01-22 23:18:48 +03:00
14 changed files with 2139 additions and 3645 deletions

3
.gitignore vendored
View File

@@ -59,9 +59,10 @@ Thumbs.db
*.ps1
keyring passwords.py
*github*
*git*
*tech_spec*
dashboards
backend/mappings.db
backend/tasks.db

View File

@@ -13,6 +13,7 @@
from fastapi import APIRouter, Depends, HTTPException
from sqlalchemy.orm import Session
from typing import List, Optional
from ...core.logger import belief_scope
from ...dependencies import get_config_manager
from ...core.database import get_db
from ...models.mapping import DatabaseMapping

View File

@@ -10,6 +10,7 @@ from typing import List, Dict
from ...dependencies import get_config_manager, get_task_manager
from ...models.dashboard import DashboardMetadata, DashboardSelection
from ...core.superset_client import SupersetClient
from ...core.logger import belief_scope
router = APIRouter(prefix="/api", tags=["migration"])
@@ -21,6 +22,7 @@ router = APIRouter(prefix="/api", tags=["migration"])
# @RETURN: List[DashboardMetadata]
@router.get("/environments/{env_id}/dashboards", response_model=List[DashboardMetadata])
async def get_dashboards(env_id: str, config_manager=Depends(get_config_manager)):
with belief_scope("get_dashboards", f"env_id={env_id}"):
environments = config_manager.get_environments()
env = next((e for e in environments if e.id == env_id), None)
if not env:
@@ -39,6 +41,7 @@ async def get_dashboards(env_id: str, config_manager=Depends(get_config_manager)
# @RETURN: Dict - {"task_id": str, "message": str}
@router.post("/migration/execute")
async def execute_migration(selection: DashboardSelection, config_manager=Depends(get_config_manager), task_manager=Depends(get_task_manager)):
with belief_scope("execute_migration"):
# Validate environments exist
environments = config_manager.get_environments()
env_ids = {e.id for e in environments}

Binary file not shown.

View File

@@ -1,13 +0,0 @@
<!doctype html>
<html lang="en">
<head>
<meta charset="UTF-8" />
<link rel="icon" type="image/svg+xml" href="/vite.svg" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<title>frontend</title>
</head>
<body>
<div id="app"></div>
<script type="module" src="/src/main.js"></script>
</body>
</html>

View File

@@ -1,4 +1,5 @@
{
"extends": "./.svelte-kit/tsconfig.json",
"compilerOptions": {
"moduleResolution": "bundler",
"target": "ESNext",

View File

@@ -1,117 +0,0 @@
<!-- [DEF:App:Component] -->
<!--
@SEMANTICS: main, entrypoint, layout, navigation
@PURPOSE: The root component of the frontend application. Manages navigation and layout.
@LAYER: UI
@RELATION: DEPENDS_ON -> frontend/src/pages/Dashboard.svelte
@RELATION: DEPENDS_ON -> frontend/src/pages/Settings.svelte
@RELATION: DEPENDS_ON -> frontend/src/lib/stores.js
@INVARIANT: Navigation state must be persisted in the currentPage store.
-->
<script>
// [SECTION: IMPORTS]
import { get } from 'svelte/store';
import Dashboard from './pages/Dashboard.svelte';
import Settings from './pages/Settings.svelte';
import { selectedPlugin, selectedTask, currentPage } from './lib/stores.js';
import TaskRunner from './components/TaskRunner.svelte';
import DynamicForm from './components/DynamicForm.svelte';
import { api } from './lib/api.js';
import Toast from './components/Toast.svelte';
// [/SECTION]
// [DEF:handleFormSubmit:Function]
/**
* @purpose Handles form submission for task creation.
* @pre event.detail contains form parameters.
* @post Task is created and selectedTask is updated.
* @param {CustomEvent} event - The submit event from DynamicForm.
*/
async function handleFormSubmit(event) {
console.log("[App.handleFormSubmit][Action] Handling form submission for task creation.");
const params = event.detail;
try {
const plugin = get(selectedPlugin);
const task = await api.createTask(plugin.id, params);
selectedTask.set(task);
selectedPlugin.set(null);
console.log(`[App.handleFormSubmit][Coherence:OK] Task created id=${task.id}`);
} catch (error) {
console.error(`[App.handleFormSubmit][Coherence:Failed] Task creation failed error=${error}`);
}
}
// [/DEF:handleFormSubmit:Function]
// [DEF:navigate:Function]
/**
* @purpose Changes the current page and resets state.
* @pre Target page name is provided.
* @post currentPage store is updated and selection state is reset.
* @param {string} page - Target page name.
*/
function navigate(page) {
console.log(`[App.navigate][Action] Navigating to ${page}.`);
// Reset selection first
if (page !== get(currentPage)) {
selectedPlugin.set(null);
selectedTask.set(null);
}
// Then set page
currentPage.set(page);
}
// [/DEF:navigate:Function]
</script>
<!-- [SECTION: TEMPLATE] -->
<Toast />
<main class="bg-gray-50 min-h-screen">
<header class="bg-white shadow-md p-4 flex justify-between items-center">
<button
type="button"
class="text-3xl font-bold text-gray-800 focus:outline-none"
on:click={() => navigate('dashboard')}
>
Superset Tools
</button>
<nav class="space-x-4">
<button
type="button"
on:click={() => navigate('dashboard')}
class="text-gray-600 hover:text-blue-600 font-medium {$currentPage === 'dashboard' ? 'text-blue-600 border-b-2 border-blue-600' : ''}"
>
Dashboard
</button>
<button
type="button"
on:click={() => navigate('settings')}
class="text-gray-600 hover:text-blue-600 font-medium {$currentPage === 'settings' ? 'text-blue-600 border-b-2 border-blue-600' : ''}"
>
Settings
</button>
</nav>
</header>
<div class="p-4">
{#if $currentPage === 'settings'}
<Settings />
{:else if $selectedTask}
<TaskRunner />
<button on:click={() => selectedTask.set(null)} class="mt-4 bg-blue-500 text-white p-2 rounded">
Back to Task List
</button>
{:else if $selectedPlugin}
<h2 class="text-2xl font-bold mb-4">{$selectedPlugin.name}</h2>
<DynamicForm schema={$selectedPlugin.schema} on:submit={handleFormSubmit} />
<button on:click={() => selectedPlugin.set(null)} class="mt-4 bg-gray-500 text-white p-2 rounded">
Back to Dashboard
</button>
{:else}
<Dashboard />
{/if}
</div>
</main>
<!-- [/SECTION] -->
<!-- [/DEF:App:Component] -->

View File

@@ -1,18 +0,0 @@
// [DEF:main:Module]
// @SEMANTICS: entrypoint, svelte, init
// @PURPOSE: Entry point for the Svelte application.
// @LAYER: UI-Entry
import './app.css'
import App from './App.svelte'
// [DEF:app_instance:Data]
// @PURPOSE: Initialized Svelte app instance.
const app = new App({
target: document.getElementById('app'),
props: {}
})
// [/DEF:app_instance:Data]
export default app
// [/DEF:main:Module]

File diff suppressed because one or more lines are too long

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,34 @@
# Specification Quality Checklist: Git Integration Plugin for Dashboard Development
**Purpose**: Validate specification completeness and quality before proceeding to planning
**Created**: 2026-01-18
**Feature**: [spec.md](../spec.md)
## Content Quality
- [x] No implementation details (languages, frameworks, APIs)
- [x] Focused on user value and business needs
- [x] Written for non-technical stakeholders
- [x] All mandatory sections completed
## Requirement Completeness
- [x] No [NEEDS CLARIFICATION] markers remain
- [x] Requirements are testable and unambiguous
- [x] Success criteria are measurable
- [x] Success criteria are technology-agnostic (no implementation details)
- [x] All acceptance scenarios are defined
- [x] Edge cases are identified
- [x] Scope is clearly bounded
- [x] Dependencies and assumptions identified
## Feature Readiness
- [x] All functional requirements have clear acceptance criteria
- [x] User scenarios cover primary flows
- [x] Feature meets measurable outcomes defined in Success Criteria
- [x] No implementation details leak into specification
## Notes
**VALIDATION COMPLETE**: All checklist items pass. The specification is ready for `/speckit.clarify` or `/speckit.plan`

View File

@@ -0,0 +1,172 @@
# Feature Specification: Git Integration Plugin for Dashboard Development
**Feature Branch**: `011-git-integration-dashboard`
**Created**: 2026-01-18
**Status**: In Progress
**Input**: User description: "Нужен плагин интеграции git в разработку дашбордов. Требования - возможность настройки целевого git сервера (базово - интеграция с gitlab), хранение и синхронизация веток разработки дашбордов, возможность публикацию в другое целевое окружение после коммита"
## User Scenarios & Testing *(mandatory)*
<!--
IMPORTANT: User stories should be PRIORITIZED as user journeys ordered by importance.
Each user story/journey must be INDEPENDENTLY TESTABLE - meaning if you implement just ONE of them,
you should still have a viable MVP (Minimum Viable Product) that delivers value.
Assign priorities (P1, P2, P3, etc.) to each story, where P1 is the most critical.
Think of each story as a standalone slice of functionality that can be:
- Developed independently
- Tested independently
- Deployed independently
- Demonstrated to users independently
-->
### User Story 1 - Configure Git Server Connection (Priority: P1)
A dashboard developer needs to connect the system to their GitLab server to enable version control for dashboard development. They want to configure the Git server URL, authentication credentials, and repository details through a simple form interface.
**Why this priority**: This is the foundational requirement - without Git server configuration, no other Git functionality can work. It's the entry point for all Git operations.
**Independent Test**: Can be fully tested by configuring a GitLab server connection and verifying the connection test succeeds, delivering the ability to establish Git server connectivity.
**Acceptance Scenarios**:
1. **Given** a user is on the Git integration settings page, **When** they enter valid GitLab server URL and API token, **Then** the system successfully validates the connection
2. **Given** a user enters invalid GitLab credentials, **When** they test the connection, **Then** the system displays a clear error message indicating authentication failure
3. **Given** a user has configured a Git server, **When** they save the settings, **Then** the configuration is persisted and can be retrieved later
---
### User Story 2 - Dashboard Branch Management (Priority: P1)
A dashboard developer needs to create, switch between, and manage different development branches for their dashboards. They want to see available branches, create new feature branches, and switch between branches to work on different dashboard versions.
**Why this priority**: This is core to the Git workflow - developers need to manage branches to work on different features or versions of dashboards simultaneously.
**Independent Test**: Can be fully tested by creating a new branch, switching to it, and verifying the branch operations work correctly, delivering basic Git branch workflow capabilities.
**Acceptance Scenarios**:
1. **Given** a Git server is configured, **When** a user views the branch list, **Then** they see all available branches from the remote repository
2. **Given** a user wants to create a new feature branch, **When** they specify a branch name, **Then** the system creates the branch both locally and pushes it to the remote repository
3. **Given** multiple branches exist, **When** a user switches to a different branch, **Then** the dashboard content updates to reflect the selected branch's state
---
### User Story 3 - Dashboard Synchronization with Git (Priority: P1)
A dashboard developer needs to synchronize their local dashboard changes with the Git repository. They want to commit changes, push to remote branches, and pull updates from other developers working on the same dashboard.
**Why this priority**: This enables collaborative development and ensures changes are properly tracked and shared between team members.
**Independent Test**: Can be fully tested by making dashboard changes, committing them, and pushing to the remote repository, delivering complete Git workflow integration.
**Acceptance Scenarios**:
1. **Given** a user has made changes to a dashboard, **When** they commit the changes with a message, **Then** the changes are committed to the current branch
2. **Given** local changes exist, **When** a user pushes to the remote repository, **Then** the changes are successfully pushed and visible to other team members
3. **Given** remote changes exist, **When** a user pulls from the remote repository, **Then** local dashboard content is updated with the latest changes
---
### User Story 4 - Environment Deployment (Priority: P2)
A dashboard developer needs to deploy their dashboard changes to different target environments (e.g., staging, production) after committing changes. They want to select a target environment and trigger the deployment process.
**Why this priority**: This enables the complete development-to-production workflow, allowing teams to promote dashboard changes through different environments.
**Independent Test**: Can be fully tested by selecting a target environment and triggering deployment, delivering the ability to promote dashboard changes to different environments.
**Acceptance Scenarios**:
1. **Given** dashboard changes are committed, **When** a user selects a target environment for deployment, **Then** the system validates the deployment configuration
2. **Given** deployment is initiated, **When** the process completes, **Then** the user receives clear feedback on deployment success or failure
3. **Given** multiple environments are configured, **When** a user deploys to one environment, **Then** other environments remain unaffected
---
### User Story 5 - Git History and Change Tracking (Priority: P3)
A dashboard developer needs to view the commit history and changes made to dashboards over time. They want to see who made changes, when they were made, and what specific changes were included in each commit.
**Why this priority**: This provides visibility into the development process and helps with debugging, auditing, and understanding the evolution of dashboards.
**Independent Test**: Can be fully tested by viewing commit history and examining specific commits, delivering transparency into dashboard development history.
**Acceptance Scenarios**:
1. **Given** multiple commits exist, **When** a user views the commit history, **Then** they see a chronological list of all commits with relevant details
2. **Given** a specific commit is selected, **When** the user views commit details, **Then** they see the changes included in that commit
3. **Given** commit history is available, **When** a user searches for specific changes, **Then** they can filter and find relevant commits
---
### Edge Cases
- What happens when Git server is temporarily unavailable during synchronization?
- How does system handle merge conflicts when multiple developers modify the same dashboard?
- What happens when a user tries to deploy to an environment that doesn't exist or is misconfigured?
- How does system handle large dashboard files that exceed Git repository size limits?
- What happens when Git authentication tokens expire during operations?
- How does system handle network interruptions during long-running operations like large pushes?
## Requirements *(mandatory)*
## Clarifications
### Session 2026-01-18
- Q: What is the primary data format for storing dashboards in the Git repository? → A: YAML files (more human-readable for diffs)
- Q: How should the system handle merge conflicts during synchronization? → A: Built-in UI for basic resolution (Mine/Theirs/Manual)
- Q: What triggers a deployment to a target environment? → A: Manual trigger by user from UI
- Q: How should the system handle authentication with GitLab? → A: Personal Access Token (PAT)
- Q: What should be the scope of a "Dashboard" in the Git repository? → A: Directory per dashboard (metadata + assets)
### Functional Requirements
- **FR-001**: System MUST allow users to configure Git server connection settings including server URL, authentication via Personal Access Token (PAT), and repository details
- **FR-002**: System MUST support GitLab as the primary Git server with extensible architecture for other Git servers
- **FR-003**: System MUST validate Git server connection using the provided PAT before saving configuration
- **FR-004**: Users MUST be able to view all available branches from the configured Git repository
- **FR-005**: Users MUST be able to create new branches both locally and remotely with proper naming validation
- **FR-006**: Users MUST be able to switch between existing branches and have dashboard content update accordingly
- **FR-007**: System MUST allow users to commit dashboard changes with commit messages and optional file selection
- **FR-008**: System MUST support pushing local commits to remote repository branches
- **FR-009**: System MUST support pulling changes from remote repository to local working directory
- **FR-010**: System MUST handle merge conflicts with a built-in UI providing "Keep Mine", "Keep Theirs", and "Manual Edit" resolution options
- **FR-011**: Users MUST be able to configure multiple target environments for dashboard deployment
- **FR-012**: System MUST allow users to manually trigger deployment to a selected target environment from the UI
- **FR-013**: System MUST validate deployment configuration before initiating deployment process
- **FR-014**: System MUST provide clear feedback on deployment success or failure with detailed logs
- **FR-015**: Users MUST be able to view commit history with details including author, timestamp, and commit message
- **FR-016**: System MUST display detailed changes included in each commit for audit purposes
- **FR-017**: System MUST handle PAT expiration gracefully with re-authentication prompts
- **FR-018**: System MUST provide offline mode functionality when Git server is unavailable
- **FR-019**: System MUST validate dashboard files before committing to ensure they are properly formatted in YAML within their respective dashboard directories
- **FR-020**: Users MUST be able to search and filter commit history by date, author, or message content
- **FR-021**: System MUST support rollback functionality to previous dashboard versions via Git operations
### Key Entities *(include if feature involves data)*
- **GitServerConfig**: Represents Git server connection configuration including server URL, Personal Access Token (PAT), repository path, and connection status
- **Branch**: Represents a Git branch with properties like name, commit hash, last updated timestamp, and remote tracking status
- **Commit**: Represents a Git commit with properties like commit hash, author, timestamp, commit message, and list of changed files
- **Environment**: Represents a deployment target environment with properties like name, URL, authentication details, and deployment status
- **DashboardChange**: Represents changes made to dashboard directories (YAML metadata + assets) including file paths, change type (add/modify/delete), and content differences
- **Branch**: Represents a Git branch with properties like name, commit hash, last updated timestamp, and remote tracking status
- **Commit**: Represents a Git commit with properties like commit hash, author, timestamp, commit message, and list of changed files
- **Environment**: Represents a deployment target environment with properties like name, URL, authentication details, and deployment status
- **DashboardChange**: Represents changes made to dashboard files (YAML format) including file paths, change type (add/modify/delete), and content differences
## Success Criteria *(mandatory)*
### Measurable Outcomes
- **SC-001**: Users can successfully configure a GitLab server connection and validate it within 2 minutes
- **SC-002**: Dashboard branch switching operations complete within 5 seconds for repositories with up to 100 commits
- **SC-003**: Commit and push operations succeed in 95% of attempts under normal network conditions
- **SC-004**: Deployment to target environments completes successfully within 30 seconds for standard dashboard configurations
- **SC-005**: Users can view and navigate through commit history for dashboards with up to 1000 commits without performance degradation
- **SC-006**: Merge conflict resolution guidance is provided in 100% of conflict scenarios with clear resolution steps
- **SC-007**: Authentication token refresh process completes within 10 seconds when tokens expire
- **SC-008**: System maintains dashboard state consistency across branch switches in 99% of operations
- **SC-009**: Deployment rollback operations complete within 1 minute for standard dashboard configurations
- **SC-010**: Users can search and filter commit history with results displayed within 2 seconds for repositories with up to 500 commits

View File

@@ -2,7 +2,7 @@
**Feature Branch**: `012-remove-superset-tool`
**Created**: 2026-01-22
**Status**: Draft
**Status**: Completed
**Input**: User description: "нужен рефакторинг бека - я хочу исключить модуль superset_tool, пусть останется только backend"
## Clarifications

View File

@@ -51,350 +51,6 @@
- 📝 Generates the token-optimized project map.
- ƒ **_write_entity_md** (`Function`)
- 📝 Recursive helper to write entity tree to Markdown.
- 📦 **migration_script** (`Module`)
- 📝 Предоставляет интерактивный CLI для миграции дашбордов Superset между окружениями с возможностью восстановления после ошибок.
- 🏗️ Layer: App
- 🔗 DEPENDS_ON -> `superset_tool.client`
- 🔗 DEPENDS_ON -> `superset_tool.utils`
- **Migration** (`Class`)
- 📝 Инкапсулирует логику интерактивной миграции дашбордов с возможностью «удалить‑и‑перезаписать» при ошибке импорта.
- ƒ **__init__** (`Function`)
- 📝 Инициализирует сервис миграции, настраивает логгер и начальные состояния.
- ƒ **run** (`Function`)
- 📝 Точка входа последовательный запуск всех шагов миграции.
- 🔗 CALLS -> `self.ask_delete_on_failure`
- 🔗 CALLS -> `self.select_environments`
- 🔗 CALLS -> `self.select_dashboards`
- 🔗 CALLS -> `self.confirm_db_config_replacement`
- 🔗 CALLS -> `self.execute_migration`
- ƒ **ask_delete_on_failure** (`Function`)
- 📝 Запрашивает у пользователя, следует ли удалять дашборд при ошибке импорта.
- 🔗 CALLS -> `yesno`
- ƒ **select_environments** (`Function`)
- 📝 Позволяет пользователю выбрать исходное и целевое окружения Superset.
- 🔗 CALLS -> `setup_clients`
- 🔗 CALLS -> `menu`
- ƒ **select_dashboards** (`Function`)
- 📝 Позволяет пользователю выбрать набор дашбордов для миграции.
- 🔗 CALLS -> `self.from_c.get_dashboards`
- 🔗 CALLS -> `checklist`
- ƒ **confirm_db_config_replacement** (`Function`)
- 📝 Запрашивает у пользователя, требуется ли заменить имена БД в YAML-файлах.
- 🔗 CALLS -> `yesno`
- 🔗 CALLS -> `self._select_databases`
- ƒ **_select_databases** (`Function`)
- 📝 Позволяет пользователю выбрать исходную и целевую БД через API.
- 🔗 CALLS -> `self.from_c.get_databases`
- 🔗 CALLS -> `self.to_c.get_databases`
- 🔗 CALLS -> `self.from_c.get_database`
- 🔗 CALLS -> `self.to_c.get_database`
- 🔗 CALLS -> `menu`
- ƒ **_batch_delete_by_ids** (`Function`)
- 📝 Удаляет набор дашбордов по их ID единым запросом.
- 🔗 CALLS -> `self.to_c.network.request`
- ƒ **execute_migration** (`Function`)
- 📝 Выполняет экспорт-импорт дашбордов, обрабатывает ошибки и, при необходимости, выполняет процедуру восстановления.
- 🔗 CALLS -> `self.from_c.export_dashboard`
- 🔗 CALLS -> `create_temp_file`
- 🔗 CALLS -> `update_yamls`
- 🔗 CALLS -> `create_dashboard_export`
- 🔗 CALLS -> `self.to_c.import_dashboard`
- 🔗 CALLS -> `self._batch_delete_by_ids`
- 📦 **superset_tool.exceptions** (`Module`)
- 📝 Определяет иерархию пользовательских исключений для всего инструмента, обеспечивая единую точку обработки ошибок.
- 🏗️ Layer: Infra
- **SupersetToolError** (`Class`)
- 📝 Базовый класс для всех ошибок, генерируемых инструментом.
- 🔗 INHERITS_FROM -> `Exception`
- ƒ **__init__** (`Function`)
- 📝 Initializes the base tool error.
- **AuthenticationError** (`Class`)
- 📝 Ошибки, связанные с аутентификацией или авторизацией.
- 🔗 INHERITS_FROM -> `SupersetToolError`
- ƒ **__init__** (`Function`)
- 📝 Initializes an authentication error.
- **PermissionDeniedError** (`Class`)
- 📝 Ошибка, возникающая при отказе в доступе к ресурсу.
- 🔗 INHERITS_FROM -> `AuthenticationError`
- ƒ **__init__** (`Function`)
- 📝 Initializes a permission denied error.
- **SupersetAPIError** (`Class`)
- 📝 Общие ошибки при взаимодействии с Superset API.
- 🔗 INHERITS_FROM -> `SupersetToolError`
- ƒ **__init__** (`Function`)
- 📝 Initializes a Superset API error.
- **ExportError** (`Class`)
- 📝 Ошибки, специфичные для операций экспорта.
- 🔗 INHERITS_FROM -> `SupersetAPIError`
- ƒ **__init__** (`Function`)
- 📝 Initializes an export error.
- **DashboardNotFoundError** (`Class`)
- 📝 Ошибка, когда запрошенный дашборд или ресурс не найден (404).
- 🔗 INHERITS_FROM -> `SupersetAPIError`
- ƒ **__init__** (`Function`)
- 📝 Initializes a dashboard not found error.
- **DatasetNotFoundError** (`Class`)
- 📝 Ошибка, когда запрашиваемый набор данных не существует (404).
- 🔗 INHERITS_FROM -> `SupersetAPIError`
- ƒ **__init__** (`Function`)
- 📝 Initializes a dataset not found error.
- **InvalidZipFormatError** (`Class`)
- 📝 Ошибка, указывающая на некорректный формат или содержимое ZIP-архива.
- 🔗 INHERITS_FROM -> `SupersetToolError`
- ƒ **__init__** (`Function`)
- 📝 Initializes an invalid ZIP format error.
- **NetworkError** (`Class`)
- 📝 Ошибки, связанные с сетевым соединением.
- 🔗 INHERITS_FROM -> `SupersetToolError`
- ƒ **__init__** (`Function`)
- 📝 Initializes a network error.
- **FileOperationError** (`Class`)
- 📝 Общие ошибки файловых операций (I/O).
- 🔗 INHERITS_FROM -> `SupersetToolError`
- **InvalidFileStructureError** (`Class`)
- 📝 Ошибка, указывающая на некорректную структуру файлов или директорий.
- 🔗 INHERITS_FROM -> `FileOperationError`
- **ConfigurationError** (`Class`)
- 📝 Ошибки, связанные с неверной конфигурацией инструмента.
- 🔗 INHERITS_FROM -> `SupersetToolError`
- 📦 **superset_tool.models** (`Module`)
- 📝 Определяет Pydantic-модели для конфигурации инструмента, обеспечивая валидацию данных.
- 🏗️ Layer: Infra
- 🔗 DEPENDS_ON -> `pydantic`
- 🔗 DEPENDS_ON -> `superset_tool.utils.logger`
- **SupersetConfig** (`Class`)
- 📝 Модель конфигурации для подключения к одному экземпляру Superset API.
- 🔗 INHERITS_FROM -> `pydantic.BaseModel`
- ƒ **validate_auth** (`Function`)
- 📝 Проверяет, что словарь `auth` содержит все необходимые для аутентификации поля.
- ƒ **normalize_base_url** (`Function`)
- 📝 Нормализует `base_url`, добавляя `/api/v1`, если он отсутствует.
- **DatabaseConfig** (`Class`)
- 📝 Модель для параметров трансформации баз данных при миграции дашбордов.
- 🔗 INHERITS_FROM -> `pydantic.BaseModel`
- ƒ **validate_config** (`Function`)
- 📝 Проверяет, что словарь `database_config` содержит ключи 'old' и 'new'.
- 📦 **superset_tool.client** (`Module`)
- 📝 Предоставляет высокоуровневый клиент для взаимодействия с Superset REST API, инкапсулируя логику запросов, обработку ошибок и пагинацию.
- 🏗️ Layer: Domain
- 🔗 DEPENDS_ON -> `superset_tool.models`
- 🔗 DEPENDS_ON -> `superset_tool.exceptions`
- 🔗 DEPENDS_ON -> `superset_tool.utils`
- **SupersetClient** (`Class`)
- 📝 Класс-обёртка над Superset REST API, предоставляющий методы для работы с дашбордами и датасетами.
- ƒ **__init__** (`Function`)
- 📝 Инициализирует клиент, проверяет конфигурацию и создает сетевой клиент.
- ƒ **_validate_config** (`Function`)
- 📝 Проверяет, что переданный объект конфигурации имеет корректный тип.
- ƒ **headers** (`Function`)
- 📝 Возвращает базовые HTTP-заголовки, используемые сетевым клиентом.
- ƒ **get_dashboards** (`Function`)
- 📝 Получает полный список дашбордов, автоматически обрабатывая пагинацию.
- 🔗 CALLS -> `self._fetch_total_object_count`
- 🔗 CALLS -> `self._fetch_all_pages`
- ƒ **export_dashboard** (`Function`)
- 📝 Экспортирует дашборд в виде ZIP-архива.
- 🔗 CALLS -> `self.network.request`
- ƒ **import_dashboard** (`Function`)
- 📝 Импортирует дашборд из ZIP-файла с возможностью автоматического удаления и повторной попытки при ошибке.
- 🔗 CALLS -> `self._do_import`
- 🔗 CALLS -> `self.delete_dashboard`
- 🔗 CALLS -> `self.get_dashboards`
- ƒ **_resolve_target_id_for_delete** (`Function`)
- 📝 Определяет ID дашборда для удаления, используя ID или slug.
- ƒ **_do_import** (`Function`)
- 📝 Выполняет один запрос на импорт без обработки исключений.
- ƒ **delete_dashboard** (`Function`)
- 📝 Удаляет дашборд по его ID или slug.
- 🔗 CALLS -> `self.network.request`
- ƒ **_extract_dashboard_id_from_zip** (`Function`)
- 📝 Извлекает ID дашборда из `metadata.yaml` внутри ZIP-архива.
- ƒ **_extract_dashboard_slug_from_zip** (`Function`)
- 📝 Извлекает slug дашборда из `metadata.yaml` внутри ZIP-архива.
- ƒ **_validate_export_response** (`Function`)
- 📝 Проверяет, что HTTP-ответ на экспорт является валидным ZIP-архивом.
- ƒ **_resolve_export_filename** (`Function`)
- 📝 Определяет имя файла для экспорта из заголовков или генерирует его.
- ƒ **_validate_query_params** (`Function`)
- 📝 Формирует корректный набор параметров запроса с пагинацией.
- ƒ **_fetch_total_object_count** (`Function`)
- 📝 Получает общее количество объектов по указанному эндпоинту для пагинации.
- ƒ **_fetch_all_pages** (`Function`)
- 📝 Итерируется по всем страницам пагинированного API и собирает все данные.
- ƒ **_validate_import_file** (`Function`)
- 📝 Проверяет, что файл существует, является ZIP-архивом и содержит `metadata.yaml`.
- ƒ **get_datasets** (`Function`)
- 📝 Получает полный список датасетов, автоматически обрабатывая пагинацию.
- 🔗 CALLS -> `self._fetch_total_object_count`
- 🔗 CALLS -> `self._fetch_all_pages`
- ƒ **get_databases** (`Function`)
- 📝 Получает полный список баз данных, автоматически обрабатывая пагинацию.
- 🔗 CALLS -> `self._fetch_total_object_count`
- 🔗 CALLS -> `self._fetch_all_pages`
- ƒ **get_dataset** (`Function`)
- 📝 Получает информацию о конкретном датасете по его ID.
- 🔗 CALLS -> `self.network.request`
- ƒ **get_database** (`Function`)
- 📝 Получает информацию о конкретной базе данных по её ID.
- 🔗 CALLS -> `self.network.request`
- ƒ **update_dataset** (`Function`)
- 📝 Обновляет данные датасета по его ID.
- 🔗 CALLS -> `self.network.request`
- 📦 **superset_tool** (`Module`)
- 📝 Root package for superset_tool.
- 🏗️ Layer: Domain
- 📦 **superset_tool.utils.init_clients** (`Module`)
- 📝 Централизованно инициализирует клиенты Superset для различных окружений (DEV, PROD, SBX, PREPROD), используя `keyring` для безопасного доступа к паролям.
- 🏗️ Layer: Infra
- 🔗 DEPENDS_ON -> `superset_tool.models`
- 🔗 DEPENDS_ON -> `superset_tool.client`
- 🔗 DEPENDS_ON -> `keyring`
- ƒ **setup_clients** (`Function`)
- 📝 Инициализирует и возвращает словарь клиентов `SupersetClient`.
- 📦 **superset_tool.utils.logger** (`Module`)
- 📝 Предоставляет универсальную обёртку над стандартным `logging.Logger` для унифицированного создания и управления логгерами с выводом в консоль и/или файл.
- 🏗️ Layer: Infra
- ƒ **belief_scope** (`Function`)
- 📝 Context manager for belief state logging to maintain execution coherence.
- **SupersetLogger** (`Class`)
- 📝 Обёртка над `logging.Logger`, которая упрощает конфигурацию и использование логгеров.
- ƒ **__init__** (`Function`)
- 📝 Конфигурирует и инициализирует логгер, добавляя обработчики для файла и/или консоли.
- ƒ **_log** (`Function`)
- 📝 (Helper) Универсальный метод для вызова соответствующего уровня логирования.
- ƒ **info** (`Function`)
- 📝 Записывает сообщение уровня INFO.
- ƒ **debug** (`Function`)
- 📝 Записывает сообщение уровня DEBUG.
- ƒ **warning** (`Function`)
- 📝 Записывает сообщение уровня WARNING.
- ƒ **error** (`Function`)
- 📝 Записывает сообщение уровня ERROR.
- ƒ **critical** (`Function`)
- 📝 Записывает сообщение уровня CRITICAL.
- ƒ **exception** (`Function`)
- 📝 Записывает сообщение уровня ERROR вместе с трассировкой стека текущего исключения.
- 📦 **belief_scope** (`Method`)
- 📝 Instance method wrapper for belief_scope context manager.
- 📦 **superset_tool.utils.fileio** (`Module`)
- 📝 Предоставляет набор утилит для управления файловыми операциями, включая работу с временными файлами, архивами ZIP, файлами YAML и очистку директорий.
- 🏗️ Layer: Infra
- 🔗 DEPENDS_ON -> `superset_tool.exceptions`
- 🔗 DEPENDS_ON -> `superset_tool.utils.logger`
- 🔗 DEPENDS_ON -> `pyyaml`
- ƒ **create_temp_file** (`Function`)
- 📝 Контекстный менеджер для создания временного файла или директории с гарантированным удалением.
- ƒ **remove_empty_directories** (`Function`)
- 📝 Рекурсивно удаляет все пустые поддиректории, начиная с указанного пути.
- ƒ **read_dashboard_from_disk** (`Function`)
- 📝 Читает бинарное содержимое файла с диска.
- ƒ **calculate_crc32** (`Function`)
- 📝 Вычисляет контрольную сумму CRC32 для файла.
- 📦 **RetentionPolicy** (`DataClass`)
- 📝 Определяет политику хранения для архивов (ежедневные, еженедельные, ежемесячные).
- ƒ **archive_exports** (`Function`)
- 📝 Управляет архивом экспортированных файлов, применяя политику хранения и дедупликацию.
- 🔗 CALLS -> `apply_retention_policy`
- 🔗 CALLS -> `calculate_crc32`
- ƒ **apply_retention_policy** (`Function`)
- 📝 (Helper) Применяет политику хранения к списку файлов, возвращая те, что нужно сохранить.
- ƒ **save_and_unpack_dashboard** (`Function`)
- 📝 Сохраняет бинарное содержимое ZIP-архива на диск и опционально распаковывает его.
- ƒ **update_yamls** (`Function`)
- 📝 Обновляет конфигурации в YAML-файлах, заменяя значения или применяя regex.
- 🔗 CALLS -> `_update_yaml_file`
- ƒ **_update_yaml_file** (`Function`)
- 📝 (Helper) Обновляет один YAML файл.
- ƒ **replacer** (`Function`)
- 📝 Функция замены, сохраняющая кавычки если они были.
- ƒ **create_dashboard_export** (`Function`)
- 📝 Создает ZIP-архив из указанных исходных путей.
- ƒ **sanitize_filename** (`Function`)
- 📝 Очищает строку от символов, недопустимых в именах файлов.
- ƒ **get_filename_from_headers** (`Function`)
- 📝 Извлекает имя файла из HTTP заголовка 'Content-Disposition'.
- ƒ **consolidate_archive_folders** (`Function`)
- 📝 Консолидирует директории архивов на основе общего слага в имени.
- 📦 **superset_tool.utils.network** (`Module`)
- 📝 Инкапсулирует низкоуровневую HTTP-логику для взаимодействия с Superset API, включая аутентификацию, управление сессией, retry-логику и обработку ошибок.
- 🏗️ Layer: Infra
- 🔗 DEPENDS_ON -> `superset_tool.exceptions`
- 🔗 DEPENDS_ON -> `superset_tool.utils.logger`
- 🔗 DEPENDS_ON -> `requests`
- **APIClient** (`Class`)
- 📝 Инкапсулирует HTTP-логику для работы с API, включая сессии, аутентификацию, и обработку запросов.
- ƒ **__init__** (`Function`)
- 📝 Инициализирует API клиент с конфигурацией, сессией и логгером.
- ƒ **_init_session** (`Function`)
- 📝 Создает и настраивает `requests.Session` с retry-логикой.
- ƒ **authenticate** (`Function`)
- 📝 Выполняет аутентификацию в Superset API и получает access и CSRF токены.
- ƒ **headers** (`Function`)
- 📝 Возвращает HTTP-заголовки для аутентифицированных запросов.
- ƒ **request** (`Function`)
- 📝 Выполняет универсальный HTTP-запрос к API.
- ƒ **_handle_http_error** (`Function`)
- 📝 (Helper) Преобразует HTTP ошибки в кастомные исключения.
- ƒ **_handle_network_error** (`Function`)
- 📝 (Helper) Преобразует сетевые ошибки в `NetworkError`.
- ƒ **upload_file** (`Function`)
- 📝 Загружает файл на сервер через multipart/form-data.
- ƒ **_perform_upload** (`Function`)
- 📝 (Helper) Выполняет POST запрос с файлом.
- ƒ **fetch_paginated_count** (`Function`)
- 📝 Получает общее количество элементов для пагинации.
- ƒ **fetch_paginated_data** (`Function`)
- 📝 Автоматически собирает данные со всех страниц пагинированного эндпоинта.
- 📦 **superset_tool.utils.whiptail_fallback** (`Module`)
- 📝 Предоставляет плотный консольный UI-fallback для интерактивных диалогов, имитируя `whiptail` для систем, где он недоступен.
- 🏗️ Layer: UI
- ƒ **menu** (`Function`)
- 📝 Отображает меню выбора и возвращает выбранный элемент.
- ƒ **checklist** (`Function`)
- 📝 Отображает список с возможностью множественного выбора.
- ƒ **yesno** (`Function`)
- 📝 Задает вопрос с ответом да/нет.
- ƒ **msgbox** (`Function`)
- 📝 Отображает информационное сообщение.
- ƒ **inputbox** (`Function`)
- 📝 Запрашивает у пользователя текстовый ввод.
- **_ConsoleGauge** (`Class`)
- 📝 Контекстный менеджер для имитации `whiptail gauge` в консоли.
- ƒ **__init__** (`Function`)
- 📝 Initializes the gauge.
- ƒ **__enter__** (`Function`)
- 📝 Enters the context.
- ƒ **__exit__** (`Function`)
- 📝 Exits the context.
- ƒ **set_text** (`Function`)
- 📝 Sets the gauge text.
- ƒ **set_percent** (`Function`)
- 📝 Sets the gauge percentage.
- ƒ **gauge** (`Function`)
- 📝 Создает и возвращает экземпляр `_ConsoleGauge`.
- 📦 **superset_tool.utils.dataset_mapper** (`Module`)
- 📝 Этот модуль отвечает за обновление метаданных (verbose_map) в датасетах Superset, извлекая их из PostgreSQL или XLSX-файлов.
- 🏗️ Layer: Domain
- 🔗 DEPENDS_ON -> `superset_tool.client`
- 🔗 DEPENDS_ON -> `pandas`
- 🔗 DEPENDS_ON -> `psycopg2`
- **DatasetMapper** (`Class`)
- 📝 Класс для меппинга и обновления verbose_map в датасетах Superset.
- ƒ **__init__** (`Function`)
- 📝 Initializes the mapper.
- ƒ **get_postgres_comments** (`Function`)
- 📝 Извлекает комментарии к колонкам из системного каталога PostgreSQL.
- ƒ **load_excel_mappings** (`Function`)
- 📝 Загружает меппинги 'column_name' -> 'column_comment' из XLSX файла.
- ƒ **run_mapping** (`Function`)
- 📝 Основная функция для выполнения меппинга и обновления verbose_map датасета в Superset.
- 🔗 CALLS -> `self.get_postgres_comments`
- 🔗 CALLS -> `self.load_excel_mappings`
- 🔗 CALLS -> `superset_client.get_dataset`
- 🔗 CALLS -> `superset_client.update_dataset`
- 📦 **superset_tool.utils** (`Module`)
- 📝 Utility package for superset_tool.
- 🏗️ Layer: Infra
- 📦 **main** (`Module`)
- 📝 Entry point for the Svelte application.
- 🏗️ Layer: UI-Entry
@@ -454,6 +110,9 @@
- 📝 Handles task creation from dynamic form submission.
- ƒ **load** (`Function`)
- 📝 Loads initial plugin data for the dashboard.
- 🧩 **TaskManagementPage** (`Component`)
- 📝 Page for managing and monitoring tasks.
- 🏗️ Layer: Page
- ƒ **loadInitialData** (`Function`)
- 📝 Loads tasks and environments on page initialization.
- ƒ **refreshTasks** (`Function`)
@@ -579,7 +238,7 @@
- ƒ **getSuggestion** (`Function`)
- 📝 Finds a suggestion for a source database.
- 🧩 **TaskLogViewer** (`Component`)
- 📝 Displays detailed logs for a specific task in a modal.
- 📝 Displays detailed logs for a specific task in a modal or inline.
- 🏗️ Layer: UI
- ƒ **fetchLogs** (`Function`)
- 📝 Fetches logs for the current task.
@@ -745,21 +404,48 @@
- ƒ **get_scheduler_service** (`Function`)
- 📝 Dependency injector for the SchedulerService.
- 📦 **backend.src.core.superset_client** (`Module`)
- 📝 Extends the base SupersetClient with database-specific metadata fetching.
- 📝 Предоставляет высокоуровневый клиент для взаимодействия с Superset REST API, инкапсулируя логику запросов, обработку ошибок и пагинацию.
- 🏗️ Layer: Core
- 🔗 INHERITS_FROM -> `superset_tool.client.SupersetClient`
- **SupersetClient** (`Class`)
- 📝 Extended SupersetClient for migration-specific operations.
- 📝 Класс-обёртка над Superset REST API, предоставляющий методы для работы с дашбордами и датасетами.
- ƒ **__init__** (`Function`)
- 📝 Инициализирует клиент, проверяет конфигурацию и создает сетевой клиент.
- ƒ **authenticate** (`Function`)
- 📝 Authenticates the client using the configured credentials.
- ƒ **headers** (`Function`)
- 📝 Возвращает базовые HTTP-заголовки, используемые сетевым клиентом.
- ƒ **get_dashboards** (`Function`)
- 📝 Получает полный список дашбордов, автоматически обрабатывая пагинацию.
- ƒ **get_dashboards_summary** (`Function`)
- 📝 Fetches dashboard metadata optimized for the grid.
- ƒ **export_dashboard** (`Function`)
- 📝 Экспортирует дашборд в виде ZIP-архива.
- ƒ **import_dashboard** (`Function`)
- 📝 Импортирует дашборд из ZIP-файла.
- ƒ **delete_dashboard** (`Function`)
- 📝 Удаляет дашборд по его ID или slug.
- ƒ **get_datasets** (`Function`)
- 📝 Получает полный список датасетов, автоматически обрабатывая пагинацию.
- ƒ **get_dataset** (`Function`)
- 📝 Получает информацию о конкретном датасете по его ID.
- ƒ **update_dataset** (`Function`)
- 📝 Обновляет данные датасета по его ID.
- ƒ **get_databases** (`Function`)
- 📝 Получает полный список баз данных.
- ƒ **get_database** (`Function`)
- 📝 Получает информацию о конкретной базе данных по её ID.
- ƒ **get_databases_summary** (`Function`)
- 📝 Fetch a summary of databases including uuid, name, and engine.
- ƒ **get_database_by_uuid** (`Function`)
- 📝 Find a database by its UUID.
- ƒ **get_dashboards_summary** (`Function`)
- 📝 Fetches dashboard metadata optimized for the grid.
- ƒ **get_dataset** (`Function`)
- 📝 Fetch full dataset structure including columns and metrics.
- ƒ **update_dataset** (`Function`)
- 📝 Update dataset metadata.
- ƒ **_resolve_target_id_for_delete** (`Function`)
- ƒ **_do_import** (`Function`)
- ƒ **_validate_export_response** (`Function`)
- ƒ **_resolve_export_filename** (`Function`)
- ƒ **_validate_query_params** (`Function`)
- ƒ **_fetch_total_object_count** (`Function`)
- ƒ **_fetch_all_pages** (`Function`)
- ƒ **_validate_import_file** (`Function`)
- 📦 **ConfigManagerModule** (`Module`)
- 📝 Manages application configuration, including loading/saving to JSON and CRUD for environments.
- 🏗️ Layer: Core
@@ -785,6 +471,8 @@
- 📝 Returns the list of configured environments.
- ƒ **has_environments** (`Function`)
- 📝 Checks if at least one environment is configured.
- ƒ **get_environment** (`Function`)
- 📝 Returns a single environment by ID.
- ƒ **add_environment** (`Function`)
- 📝 Adds a new environment to the configuration.
- ƒ **update_environment** (`Function`)
@@ -862,6 +550,8 @@
- 📝 Returns a list of recent log entries from the buffer.
- 📦 **Logger** (`Global`)
- 📝 The global logger instance for the application, configured with both a console handler and the custom WebSocket handler.
- ƒ **believed** (`Function`)
- 📝 A decorator that wraps a function in a belief scope.
- **PluginLoader** (`Class`)
- 📝 Scans a specified directory for Python modules, dynamically loads them, and registers any classes that are valid implementations of the PluginBase interface.
- 🏗️ Layer: Core
@@ -907,12 +597,76 @@
- **PluginConfig** (`Class`)
- 📝 A Pydantic model used to represent the validated configuration and metadata of a loaded plugin. This object is what gets exposed to the API layer.
- 🏗️ Layer: Core
- 📦 **backend.core.utils.fileio** (`Module`)
- 📝 Предоставляет набор утилит для управления файловыми операциями, включая работу с временными файлами, архивами ZIP, файлами YAML и очистку директорий.
- 🏗️ Layer: Infra
- 🔗 DEPENDS_ON -> `backend.src.core.logger`
- 🔗 DEPENDS_ON -> `pyyaml`
- **InvalidZipFormatError** (`Class`)
- ƒ **create_temp_file** (`Function`)
- 📝 Контекстный менеджер для создания временного файла или директории с гарантированным удалением.
- ƒ **remove_empty_directories** (`Function`)
- 📝 Рекурсивно удаляет все пустые поддиректории, начиная с указанного пути.
- ƒ **read_dashboard_from_disk** (`Function`)
- 📝 Читает бинарное содержимое файла с диска.
- ƒ **calculate_crc32** (`Function`)
- 📝 Вычисляет контрольную сумму CRC32 для файла.
- 📦 **RetentionPolicy** (`DataClass`)
- 📝 Определяет политику хранения для архивов (ежедневные, еженедельные, ежемесячные).
- ƒ **archive_exports** (`Function`)
- 📝 Управляет архивом экспортированных файлов, применяя политику хранения и дедупликацию.
- 🔗 CALLS -> `apply_retention_policy`
- 🔗 CALLS -> `calculate_crc32`
- ƒ **apply_retention_policy** (`Function`)
- 📝 (Helper) Применяет политику хранения к списку файлов, возвращая те, что нужно сохранить.
- ƒ **save_and_unpack_dashboard** (`Function`)
- 📝 Сохраняет бинарное содержимое ZIP-архива на диск и опционально распаковывает его.
- ƒ **update_yamls** (`Function`)
- 📝 Обновляет конфигурации в YAML-файлах, заменяя значения или применяя regex.
- 🔗 CALLS -> `_update_yaml_file`
- ƒ **_update_yaml_file** (`Function`)
- 📝 (Helper) Обновляет один YAML файл.
- ƒ **create_dashboard_export** (`Function`)
- 📝 Создает ZIP-архив из указанных исходных путей.
- ƒ **sanitize_filename** (`Function`)
- 📝 Очищает строку от символов, недопустимых в именах файлов.
- ƒ **get_filename_from_headers** (`Function`)
- 📝 Извлекает имя файла из HTTP заголовка 'Content-Disposition'.
- ƒ **consolidate_archive_folders** (`Function`)
- 📝 Консолидирует директории архивов на основе общего слага в имени.
- 📦 **backend.core.utils.network** (`Module`)
- 📝 Инкапсулирует низкоуровневую HTTP-логику для взаимодействия с Superset API, включая аутентификацию, управление сессией, retry-логику и обработку ошибок.
- 🏗️ Layer: Infra
- 🔗 DEPENDS_ON -> `backend.src.core.logger`
- 🔗 DEPENDS_ON -> `requests`
- **SupersetAPIError** (`Class`)
- **AuthenticationError** (`Class`)
- 📦 **backend.src.core.utils.matching** (`Module`)
- 📝 Provides utility functions for fuzzy matching database names.
- 🏗️ Layer: Core
- 🔗 DEPENDS_ON -> `rapidfuzz`
- ƒ **suggest_mappings** (`Function`)
- 📝 Suggests mappings between source and target databases using fuzzy matching.
- 📦 **backend.core.utils.dataset_mapper** (`Module`)
- 📝 Этот модуль отвечает за обновление метаданных (verbose_map) в датасетах Superset, извлекая их из PostgreSQL или XLSX-файлов.
- 🏗️ Layer: Domain
- 🔗 DEPENDS_ON -> `backend.core.superset_client`
- 🔗 DEPENDS_ON -> `pandas`
- 🔗 DEPENDS_ON -> `psycopg2`
- **DatasetMapper** (`Class`)
- 📝 Класс для меппинга и обновления verbose_map в датасетах Superset.
- ƒ **__init__** (`Function`)
- 📝 Initializes the mapper.
- ƒ **get_postgres_comments** (`Function`)
- 📝 Извлекает комментарии к колонкам из системного каталога PostgreSQL.
- ƒ **load_excel_mappings** (`Function`)
- 📝 Загружает меппинги 'column_name' -> 'column_comment' из XLSX файла.
- ƒ **run_mapping** (`Function`)
- 📝 Основная функция для выполнения меппинга и обновления verbose_map датасета в Superset.
- 🔗 CALLS -> `self.get_postgres_comments`
- 🔗 CALLS -> `self.load_excel_mappings`
- 🔗 CALLS -> `superset_client.get_dataset`
- 🔗 CALLS -> `superset_client.update_dataset`
- 📦 **TaskPersistenceModule** (`Module`)
- 📝 Handles the persistence of tasks using SQLAlchemy and the tasks.db database.
- 🏗️ Layer: Core
@@ -1228,10 +982,8 @@
- 📝 Returns the JSON schema for migration plugin parameters.
- ƒ **execute** (`Function`)
- 📝 Executes the dashboard migration logic.
- ƒ **test_superset_config_url_normalization** (`Function`)
- 📝 Tests that SupersetConfig correctly normalizes the base URL.
- ƒ **test_superset_config_invalid_url** (`Function`)
- 📝 Tests that SupersetConfig raises ValueError for invalid URLs.
- ƒ **test_environment_model** (`Function`)
- 📝 Tests that Environment model correctly stores values.
- ƒ **test_belief_scope_logs_entry_action_exit** (`Function`)
- 📝 Test that belief_scope generates [ID][Entry], [ID][Action], and [ID][Exit] logs.
- ƒ **test_belief_scope_error_handling** (`Function`)