Nodes can have properties that have a displayOption which specifies a
version
for which node versions that property applies to. We should take this
into
account when forming the action types for a Node in the NodeList.
For example Notion node has 2 version which have different Page
operations.
Github issue / Community forum post (link here to close automatically):
---------
Co-authored-by: Omar Ajoue <krynble@gmail.com>
Co-authored-by: कारतोफ्फेलस्क्रिप्ट™ <aditya@netroy.in>
This PR introduces banner framework overhaul:
First version of the banner framework was built to allow multiple
banners to be shown at the same time. Since that proven to be the case
we don't need and it turned out to be pretty messy keeping only one
banner visible in such setup, this PR reworks it so it renders only one
banner at a time, based on [this priority
list](https://www.notion.so/n8n/Banner-stack-60948c4167c743718fde80d6745258d5?pvs=4#6afd052ec8d146a1b0fab8884a19add7)
that is assembled together with our product & design team.
### How to test banner stack:
1. Available banners and their priorities are registered
[here](f9f122d46d/packages/editor-ui/src/components/banners/BannerStack.vue (L14))
2. Banners are pushed to stack using `pushBannerToStack` action, for
example:
```
useUIStore().pushBannerToStack('TRIAL');
```
4. Try pushing different banners to stack and check if only the one with
highest priorities is showing up
### How to test the _Email confirmation_ banner:
1. Comment out [this
line](b80d2e3bec/packages/editor-ui/src/stores/cloudPlan.store.ts (L59)),
so cloud data is always fetched
2. Create an
[override](https://chrome.google.com/webstore/detail/resource-override/pkoacgokdfckfpndoffpifphamojphii)
(URL -> File) that will serve user data that triggers this banner:
- **URL**: `*/rest/cloud/proxy/admin/user/me`
- **File**:
```
{
"confirmed": false,
"id": 1,
"email": "test@test.com",
"username": "test"
}
```
3. Run n8n
Context
When a user is attempting to interact with a foreground action inside an
entity card (workflow, credential, community node, logging destination),
they might accidentally open that entity instead of interacting with a
foreground action.
For these card components, actions are always placed on right side.
A/C
Area around right "column" of entity cards (workflow, cred, community
node, logging destination) should not be a hoverable area (that opens
that entity when clicked). This area is roughly highlighted in screen
shot below in orange.
Github issue / Community forum post (link here to close automatically):
Since the change to allow workflow IDs to become strings in Nano ID
formats, this input broke.
This PR allows all characters that comprise workflow IDs.
---------
Co-authored-by: Iván Ovejero <ivov.src@gmail.com>
Github issue / Community forum post (link here to close automatically):
This PR aims to address an issue where an Error workflow cannot be
started, either due to insufficient permissions or because its settings
prevent it from being called.
The way of addressing this is by creating a failed execution for the
appointed error workflow stating the error, as can be seen below.
This means the execution itself won't start, as it's prevented before
the execution beings, but we save a "stub" execution to show the error.
