flowfuse/flowfuse

Build bespoke, flexible, and resilient manufacturing low-code applications with FlowFuse and Node-RED

FlowFuse helps Node-RED developers deliver applications in a more reliable, collaborative and secure manner. Node-RED’s intuitive, low-code development environment is great for connecting together hardware devices, APIs and online services. FlowFuse adds to Node-RED collaborative development, management of remote deployments, support for DevOps deliver pipelines, and the ability to host Node-RED applications on FlowFuse Cloud. FlowFuse is the devops platform for Node-RED application development and delivery.

Key Features

• FlowFuse adds team collaboration to Node-RED, allowing multiple developers to work together on a single instance.
• Many organizations deploy Node-RED instances to remote servers or edge devices. FlowFuse automates this process by creating snapshots on Node-RED instances that can be deployed to multiple remote targets.
• FlowFuse simplifies the software development lifecycle of Node-RED applications. You can now set up DevOps delivery pipelines to support development, test and production environments for Node-RED application delivery.
• FlowFuse is available from FlowFuse Cloud, a managed cloud service, or a self-hosted solution.
• FlowFuse offers professional technical support for FlowFuse and Node-RED.

Links

• Home Page
• Documentation
• Contributing
• Code of Conduct
• Security
• License

flowfuse's Issues

Story: Be notified of pending team invitations

Description

As a: User

I want to: Be notified of pending team invitations

So that: I can accept or decline the invitation

Acceptance Criteria

• ...

Allow writing of documentation for users and administrators

The current documentation is generated through jsdoc and oriented at developers. However, as a user or administrator I'd like to be able to read how certain actions should be performed.

Requirements:

• Allow users and developers alike to easily update the documentation
• Have documentation and code in the same repository to update in lock-step

Nice to have:

• Rich formatting options (Markdown?)

Story: Change the role of users in the team

Description

As a: Team Owner

I want to: Change the role of users in the team

So that: I can change what access they have

Acceptance Criteria

• ...

Story: Remove myself from a team, unless I'm the only Owner

Description

As a: User

I want to: Remove myself from a team, unless I'm the only Owner

So that: I can choose to leave the team

Acceptance Criteria

• ...

Add Personal Access Token Support

• Add database model for Personal Access Tokens (PATs)
• Define REST API interface to allow user to generate/delete tokens
• Add auth middleware to handle PAT in place of session cookie
• Create UI view to list user's tokens
• Create UI view to create a new token

User Stories

Beta Give feedback

1. Story: Revoke a personal-access-token #42
   scope:enterprise size:M - 3 story +3
2. Story: Generate a personal-access-token #41
   scope:enterprise size:M - 3 story +3
3. APIs with SSO Enabled #2482
   size:M - 3 story +2

Get proper license workflow in place

We currently have a very limited license mechanism in place. It needs a bit more work for MVP.

Current state:

1. A development-only pair of license signing keys are stored in the repository. These can be used to generate valid licenses - but are not what we'll use long term.
2. The license component checks the database to see if a license has been applied as part of the startup wizard.
3. If the license is present, it is verified and the terms it contains are stored
4. The Admin view in the UI will display the current license details but does not allow it to be modified

Required changes:

• Generate the real license key files. Store private key in 1Password vault. Store public key in this repo
• Remove placeholder key files from repository
• Generate a new development-only license using the real key files
• #128 - Add Admin API end point to update license (PUT /api/v1/admin/license)
• #128 - Allow Admin UI view to change the license
• Include license details (as needed by UI) in GET /api/v1/settings response
• Add license checks on API actions that create Users/Teams/Projects
• Add UI prompts where an action is restricted by license

Some outstanding design decisions that should be considered but could be put-off post-MVP

• Current model only allows for a single license. We may want to have them in their own DB table so we can have a history of previous licenses available.
• The current model also means if a user gets a new license, there must be overlap between the 'valid from' date of new license and 'expires at' of the old - so they can apply the new license without having to worry too much about timing. Whereas a DB table of licenses could allow for 'automatic' roll-over onto the whichever is the active license.
• Need to consider license expiry and what happens if a platform finds itself exceeding the current license (or missing license)
• Should we require all users to have a license of some type? Even in the completely free tier - a license we provide that reflects the free tier entitlement. When we get to adding usage telemetry, that would allow us to relate usage back to a license. Hard to retrofit. Downside is that could inhibit experimentation and long-tail adoption.

Story: Stop a node-red instance

Description

As a: User

I want to: Stop a node-red instance

So that: I can halt the application without having to delete it

Acceptance Criteria

• UI to request project stop
• API to request project stop
• Container implementation to stop project

Story: See outstanding team invitations

Description

As a: Team Owner

I want to: See outstanding team invitations

So that: I can resend or cancel the invitation

Acceptance Criteria

• ...

Allow Project starting to be seperated from Project creation

Description

As a: Team Admin

I want to: be notified that a Project has been created before it has been started.

So That: I can get on with other tasks while the Project is starting

This allows for project to start in the background:

• if it will take a long time e.g. if having to pull containers from the registry.
• A project may be valid up resources it depends on may be offline.

Make this repo public

The intention has always been for the FlowForge platform to have an open core - with the core functionality available under a proper OSS license and some parts under a proprietary license.

The pure OSS code will be sufficient to run the basic FlowForge platform.

The proprietary code will be used to implement the licensable features of the platform. This code will still be 'source available' and accept contributions, but will not be under an OSS license that permits redistribution or commercial use without a valid license provided by FlowForge Inc.

This repository is currently private whilst we get things in place - giving us some space without the world watching. But that is only a temporary state. The goal is to make this repo public and to be developing in the open as soon as we can.

What do we need to do before making this repo public?

• Add license information
  We are going to follow the process used by GitLab. The code has already been laid out to match - with the ee directory to contain the proprietary components. There's still more engineering design to be done around how that will work in practice, but that is unrelated to how the license defines what code is made available under what license
• Setup github issue templates
  I have discovered the hard way that GitHub issue templates cannot be used in Private repos. I have the templates ready to go.
• Add CODE_OF_CONDUCT.md - this should be done in the flowforge/.github repo as well
• Add SECURITY.md
• #181
• #182
• #77
• #69
• #78
• #79
• #80
• #81

Story: Remove members from the team

Description

As a: Team Owner

I want to: Remove members from the team

So that: I can manage team membership

Acceptance Criteria

• ...

Story: Create a node-red instance

Description

As a: User

I want to: Create a node-red instance

So that: I can start building my application

Acceptance Criteria

• UI to create new instance
• API for UI to call
• Container implementation to back API

Story: Invite another user to my team

Description

As a: Team Owner

I want to: Invite another user to my team

So that: They can access the projects in my team

Acceptance Criteria

• ...

Story: Accept/Decline team invitations

Description

As a: User

I want to: Accept/Decline team invitations

So that: I choose whether to join a team

Acceptance Criteria

• ...

Story: register a new user

Description

As a: New FlowForge User

I want to: Register with the platform

So that: I can login and start using it.

Note this is different from #26 as that concerns setting up the first admin user. This story covers getting the next user registered.

Acceptance Criteria

• A user is able to 'sign up' via the login screen
• They are registered with the platform and able to login
• A new team will be created for the user

Make user docs available in FlowForge UI

The main user documentation will be maintained in the core FlowForge repository as markdown under the docs directory. The intention is to pull that markdown and generate content for the website.

We should also make it accessible in the platform UI.

• Create Help container pages
• Add Help option to user menu
• Serve doc content from a well-defined URL. This is not part of the formal api (/api/v1/...).

Story: Mark a/many/all passwords as expired

Description

As a: Administrator

I want to: Mark a/many/all passwords as expired

So that: I can force users to change their password next time they login

Acceptance Criteria

• ...

Story: Delete a node-red instance

Description

As a: User

I want to: Delete a node-red instance

So that: I can remove all trace of the instance

Acceptance Criteria

• UI to delete instance
• API to delete instance
• Container implementation to delete instance

Add Documentation to Container Stub API

This will be the canonical version so should contain the working doc

• Create
• Remove
• Start
• Stop
• Restart
• List
• Details
• Settings

Email configuration workflow

The email system requires some configuration to be provided before running the forge app.

If email isn't enabled, the UI does properly restrict actions that require email (such as inviting external users).

But there are some gaps:

• #134
• add to this list

Other items to resolve:

• Should email be configurable via admin UI screens, or is it a purely static configuration (ie env vars/yaml/config)
• #139
• #138

Implement K8s Contatiner Driver

Need to build equivalent to docker instance

Story: Create a new team

Description

As a: User

I want to: Create a new team

So that: I can create a new team to collaborate with other users within

Acceptance Criteria

• ...

Email integration

Story: create first user

Description

As a: FlowForge User

I want to: Create the first user for the system

So that: I can login and start using it.

Acceptance Criteria

• From a clean start, the user is able to create the first user account on the system.
• This user will be an Admin user
• A new team will be created for the user
• This can be achieved by CLI setup tools as an initial implementation. If done that way, a separate story will be needed to cover a first-run setup sequence in the UI.

Story: Delete the team

Description

As a: Team Owner

I want to: Delete the team

So that: The team and all its resources are removed

Acceptance Criteria

• ...

Identify licensable features for free tier

Story: Invalidate session tokens for a/many/all users

Description

As a: Administrator

I want to: Invalidate session tokens for a/many/all users

So that: I can force users to relogin next time they access the platform

Acceptance Criteria

• ...

Story: Reset a/many/all user passwords

Description

As a: Administrator

I want to: Reset a/many/all user passwords

So that: I can secure the platform quickly

Acceptance Criteria

• ...

Capture audit logging to database

Document what statistics are shared and how

When starting a new FlowForge install, one of the steps is to choose to opt-in to sharing data back to FlowForge Inc.

For an administrator it's unclear what data is obtained and how/when this is done. Documenting this would aid in transparency to the end-user and help them decide what is shared and why.

Story: See a list of my tokens and when they were last used

Description

As a: User

I want to: See a list of my tokens and when they were last used

So that: I know what tokens I have and how they are being used

Acceptance Criteria

• ...

Story: Revoke a personal-access-token

Description

As a: User

I want to: Revoke a personal-access-token

So that: I can prevent any further use of it

Acceptance Criteria

• ...

Story: Add people to teams without an invitation

Description

As a: Administrator

I want to: Add people to teams without an invitation

So that: They are added to the team directly

Acceptance Criteria

• ...

Add test framework

We need a proper testing framework in place.

We already have mocha, with the npm run test task configured to run all *_spec.js files found under either test/** (which doesn't exist yet) or ee/** (which does exist).

That's good enough to get started writing tests.

I'm keen to follow the convention used in the core node-red repo - each source file has a corresponding _spec.js file under the appriopriate test directory.

That will be suitable for 'unit' type testing, but we will also need bigger, system-wide/integration tests. It may be better to have separate unit, integration directories under the test directory.

Build Local Filesystem "container" drive

UI: Add project-create view

Add a view to create a new project.

Story: Change my avatar

Description

As a: User

I want to: Change my avatar

So that: I can customise my appearance

Acceptance Criteria

• ...

Story: Change my default team

Description

As a: User

I want to: Change my default team

So that: I can chose which team I am shown when I log in

Acceptance Criteria

• ...

UI: Add project view

Create a view to show the details of an individual project.

Add logging framework

Fastify already uses pino under the covers and I don't currently see any reason why not to use that.

It supports a pluggable transport layer to get the logs to a destination of choice.

Its log records are JSON formatted, but there is a pretty printing option that allows for more human-readable logs.

As it is used by fastify, every http request gets logged in great detail. My slight concern is the logs are too verbose to surface end-user log messages. But maybe that's more a filtering issue.

First-run user-experience

Story: Create a new user

Description

As a: Adminstrator

I want to: Create a new user

So that: I can create new users on the system on their behalf

Acceptance Criteria

• ...

Story: Edit my settings

Description

As a: User

I want to: Edit my settings

So that: I can change my display name and other user settings

Acceptance Criteria

• ...

Avatars not shown if you change the BASE_URL

The current BASE_URL is included in the avatar field in the database.

This should probably have a database model getter method to prepend the current value so it is not always localhost:3000

Cross-platform install script for LocalFS

Story: Edit a users settings

Description

As a: Administrator

I want to: Edit a users settings

So that: I can manage the users on the system

Acceptance Criteria

• ...

Allow seperate internal/external URL hosts

When running on K8s it would be useful to route storage/logging and project/uuid/settings endpoints over the internal overlay network rather than via the public FlowForge Application hostname.

E.g. Avatars still loaded from http(s)://forge.example.com

storage API loaded from http://forge.default (where default is the K8s namespace the application is running in)

Story: Generate a personal-access-token

Description

As a: User

I want to: Generate a personal-access-token

So that: I can access the forge API without a sign-on challenge

Acceptance Criteria

• ...

Story: Transfer a project to another team I'm a member of

Description

As a: Team Owner

I want to: Transfer a project to another team I'm a member of

So that: I can manage my projects across teams

Acceptance Criteria

• ...

Story: See a history of events within my team

Description

As a: Team Owner

I want to: See a history of events within my team

So that: I know who is doing what and spot any misuse or unexpected events

Acceptance Criteria

• ...