* feat(plugins): fire PERSISTED_DATA_CHANGED hook on persisted-data changes
Wires the dead PluginHooks.PERSISTED_DATA_UPDATE enum into a fired hook,
renamed PERSISTED_DATA_CHANGED. Plugins are notified when their persisted
data changes for any reason after the host's initial boot load — local
writes, remote incremental sync via bulkApplyOperations, and post-boot
wholesale loadAllData paths (SYNC_IMPORT / BACKUP_IMPORT / validation
repair / recovery).
Selector-based effect on selectPluginUserDataFeatureState, gated on
SyncTriggerService.afterInitialSyncDoneAndDataLoadedInitially$ so the
boot-time state seeds the pairwise baseline. Differ compares prev/next
by === on the encoded data blob (never decoded). Stage A composite
entityIds (pluginId:key) are normalized to owner pluginId and deduped
so a plugin with N keyed entries changing in one emission fires exactly
once. Per-pluginId dispatch via new PluginHooksService.dispatchHookToPlugin.
Effect is { dispatch: false } and creates no ops, so no sync-window
guard is needed — and adding one (skipDuringSyncWindow) would silently
suppress the very remote-sync deliveries the hook is designed to catch.
Closes#7754. Follow-up: doc-mode adoption tracked in #7752.
* test(plugins): tighten PERSISTED_DATA_CHANGED spec + docs
Multi-review pass 2 surfaced that the 5s timeout spec asserted only that
the dispatcher resolved — it would have silently passed if the timeout
race were removed entirely. Spy on PluginLog.err and assert the timeout
message actually reached the catch branch.
Also:
- Add `:` guard to PluginHooksService.registerHookHandler so the
persistence-key grammar is enforced at both the persistence and
hooks-registry endpoints (defense-in-depth; composeId already throws
at the bridge).
- Add async-rejected-promise spec to cover the Promise.race branch that
sync-throw didn't exercise.
- Carry the PERSISTED_DATA_CHANGED contract paragraph into
docs/plugin-development.md and docs/wiki/3.01-API.md (previously only
in packages/plugin-api/README.md).
- Clarify loadSyncedData(key?) in the README for keyed plugins.
POST /tasks with parentId silently dropped any supplied projectId/tagIds
(the reducer forces tagIds=[] and projectId=parent.projectId), so callers
got 201 with values different from what they sent. Reject the request
with 400 UNSUPPORTED_FIELD instead, symmetric with how subTaskIds and
parentId-on-PATCH are handled.
POST /tasks now accepts `parentId` and creates a subtask via
TaskService.addSubTaskTo (inheriting the parent's projectId). Invalid
parent references return 404 PARENT_NOT_FOUND; nested parents return
400 INVALID_PARENT. `subTaskIds` on POST and `parentId`/`subTaskIds`
on PATCH are now rejected with 400 UNSUPPORTED_FIELD instead of being
silently dropped.
Fixes#7346
* feat(electron): add Local REST API for desktop automation
Add a local HTTP server (port 3876) that allows external scripts and
tools to interact with a running Super Productivity desktop app.
Features:
- Task CRUD operations (create, read, update, delete)
- Task control (start, stop, set current)
- Task archive/restore operations
- Query filters for tasks (by title, project, tag, done status)
- Read-only project and tag listing
The API is disabled by default and can be enabled in Settings > Misc.
Only accepts connections from localhost (127.0.0.1) for security.
* fix: resolve lint errors for local REST API
* fix: use lazy injection for LocalRestApiHandlerService
Fixes StartupService tests by using Injector.get() instead of direct
injection, preventing LocalRestApiHandlerService from being instantiated
when StartupService tests don't have NgRx providers.
* fix: resolve markdown lint errors in API docs
* fix: add security warning to Local REST API hint
* docs(wiki): add new Quickstart to help with using Sync
There is a slew of notes that try to explain or show this so a
Quickstart can help bring everything into one place.
* docs(wiki): combine "First Steps" into single note with relevant links
* docs(wiki): update index notes
* docs(wiki): fix remaining broken external links
* docs(wiki): add core developer How-To guides to orient first-time devs
The majority of the documentation is currently spread across several
files ins "docs/" and READMEs. Over time these can be consolidated into
the wiki while retaining the common CONTRIBUTING.md as a valid entry
point.
* docs(wiki): add basic guides for plugins and issue integration
As with the core development docs, there is too much to add here right
now. These notes will serve as a simple entry to other resources.
* docs(wiki): add basic reference note for theming
* docs(wiki): add basic Translation guide
* docs(wiki): rename Theming and linting to clean up headings
* docs(wiki): add heading lint exception for GH-specific nav pages; rework sidebar and index pages
Sidebar should be a quick-access for the more common topics grouped
thematically with the X.00 notes simply enumerating all the notes where
appropriate.
Includes backward compatibility: client accepts both CONFLICT_SUPERSEDED
and CONFLICT_STALE from the server, and the server keeps a deprecated
CONFLICT_STALE alias. Remove after all deployments are updated.
* docs(wiki): enhance keyboard shortcuts documentation
Added detailed descriptions of functional grouping for keyboard shortcuts, including categories such as Global, Navigation, Task management, and UI panels. Updated the Global Shortcuts section for clarity and included platform-specific differences, configurable vs reserved shortcuts, context-dependent behavior, and storage definitions. This improves user understanding of the shortcut system and its configuration.
* docs(wiki): add reference to Web App vs Desktop differences
Updated the 3.00-Reference and 3.02-Settings-and-Preferences documentation to include a new section on differences between the Web app and Desktop app, linking to the newly created [[3.05-Web-App-vs-Desktop]] page. This enhances clarity and provides users with a direct reference for understanding the distinctions.
* docs(wiki): expand short syntax documentation
Enhanced the 3.04-Short-Syntax.md file by detailing the four main short syntax forms for task metadata: tags, projects, time estimates, and due dates. Each syntax form now includes its purpose, grammar, valid and invalid examples, and additional parsing rules. This update improves user understanding of how to effectively utilize short syntax in task management.
* docs(wiki): add User Data reference to documentation
Included a new reference to [[3.06-User-Data]] in both the 3.00-Reference and _Sidebar.md files. This addition enhances navigation and provides users with direct access to information regarding user data management.
* docs(wiki): expand API documentation for Sync Server and Plugin API
Added comprehensive details on the Sync Server REST API and Plugin API, including authentication methods, endpoint descriptions, request/response schemas, error codes, rate limits, and data retention policies. This update significantly enhances the documentation, providing users with a clearer understanding of the APIs available for data synchronization and plugin development.
- Add top-level headings to all wiki files (MD041)
- Fix heading spacing and blank line issues (MD022, MD012)
- Convert HTML badges to markdown format (MD033)
- Add alt text to images (MD045)
- Fix list indentation and numbering (MD005, MD029, MD032)
- Remove trailing punctuation from headings (MD026)
- Convert emphasis to proper headings (MD036)
- Fix heading level increments (MD001)
- Add trailing newlines to all files (MD047)
This ensures the wiki-sync.yml GitHub Action will pass linting.
All changes maintain the same visual appearance and functionality.
Fixes the lint failures reported in GitHub Action run #21212863659
Contains both a first-draft of content as well as
a comprehensive GH Action to replicate from
docs/wiki to the `.wiki` sub-repo. The linting is
non-blocking at the moment.
- the existing markdown linking appears reliably
rendered in GH but more testing needed.
- style guide for contributions/expectations needs
to be added to the wiki
- **a significant re-work of the README** to
re-direct users to the Wiki is needed to avoid
doc duplication
- updates to the PR templates and contributor
guidelines to emphasize the importance of adding
documentation is still needed
