This PR should improve performance when opening large workflows that
contain node issues (Fixes ADO-1521)
**Background**
Main reason for this poor performance is that our `getCurrentWorkflow()`
store getter is unnecessarily heavy but on top of that we are calling it
more than we need. This addresses the second part of the issue by
changing the following:
- Pausing node issue processing while workflows are loading
- Only getting current workflow once (instead for every node) when
calling `refreshNodeIssues`
**Benchmark**
This was tested on a workflow attached to [this Linear
ticket](https://linear.app/n8n/issue/ADO-1501/deliveryhero-enterprise-instance-very-slow-loading-workflows)
and this fix brings down opening time from **~1m10s** to **~28s** on my
laptop.
**Tests**
- [Latest e2e tests
run](https://github.com/n8n-io/n8n/actions/runs/7060874994)
https://community.n8n.io/t/ui-very-slow-with-more-than-100-nodes/8236/14
This PR sets the stage for the node creator to handle sections within
subcategories. No visible changes result from this PR; the next PR will
define sections and assign nodes accordingly.
Sections are configurable in
`packages/editor-ui/src/components/Node/NodeCreator/viewsData.ts`:
```
{
type: 'subcategory',
key: FILES_SUBCATEGORY,
category: CORE_NODES_CATEGORY,
properties: {
title: FILES_SUBCATEGORY,
icon: 'file-alt',
sections: [
{
key: 'popular',
title: i18n.baseText('nodeCreator.sectionNames.popular'),
items: ['n8n-nodes-base.readBinaryFiles', 'n8n-nodes-base.compression'],
},
],
},
},
```
For example:
<img width="302" alt="image"
src="https://github.com/n8n-io/n8n/assets/8850410/74470c07-f4ea-4306-bd4a-8d33bd769b86">
---------
Co-authored-by: Michael Kret <michael.k@radency.com>
The template credentials were matched before solely based on the
credential name on the template. This fixes the matching to use both
credential type name and credential name.
Removing scope permission checks on workflow and credential sharing and
relying only on resource ownership.
Every user can share only the workflows and credentials they created.
Moving cloud hooks and store initialization logic after users are
authenticated. This will ensure user local account is available when
their cloud plan data is being fetched.
This PR also adds the following error handling improvements:
- Added error handling to the same initialization logic
- Fixed empty `catch` clauses inside the cloud store which caused it to
silently fail and complicated debugging of this bug
This PR fixes mouse position detection in workflow previews (executions
preview and workflow history view):
https://github.com/n8n-io/n8n/assets/2598782/83237b76-b099-4560-9c47-a963f0848297
**Cause**:
We were setting `isDemo` state in canvas store only when the `NodeView`
component is activated, which never happens for `NodeView` instances
that are kept alive (above mentioned workflow previews)
**Fix**:
This workflow updates store state also when the `NodeView` component is
mounted.
This PR introduces the following changes:
- New Vue stores: `collaborationStore` and `pushConnectionStore`
- Front-end push connection handling overhaul: Keep only a singe
connection open and handle it from the new store
- Add user avatars in the editor header when there are multiple users
working on the same workflow
- Sending a heartbeat event to back-end service periodically to confirm
user is still active
- Back-end overhauls (authored by @tomi):
- Implementing a cleanup procedure that removes inactive users
- Refactoring collaboration service current implementation
---------
Co-authored-by: Tomi Turtiainen <10324676+tomi@users.noreply.github.com>
Followup to #7566 | Story: https://linear.app/n8n/issue/PAY-926
### Manual workflow activation and deactivation
In a multi-main scenario, if the user manually activates or deactivates
a workflow, the process (whether leader or follower) that handles the
PATCH request and updates its internal state should send a message into
the command channel, so that all other main processes update their
internal state accordingly:
- Add to `ActiveWorkflows` if activating
- Remove from `ActiveWorkflows` if deactivating
- Remove and re-add to `ActiveWorkflows` if the update did not change
activation status.
After updating their internal state, if activating or deactivating, the
recipient main processes should push a message to all connected
frontends so that these can update their stores and so reflect the value
in the UI.
### Workflow activation errors
On failure to activate a workflow, the main instance should record the
error in Redis - main instances should always pull activation errors
from Redis in a multi-main scenario.
### Leadership change
On leadership change...
- The old leader should stop pruning and the new leader should start
pruning.
- The old leader should remove trigger- and poller-based workflows and
the new leader should add them.
