Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Shared Environment Variables #2373

Open
2 tasks
MarianRaphael opened this issue Jun 30, 2023 · 10 comments
Open
2 tasks

Shared Environment Variables #2373

MarianRaphael opened this issue Jun 30, 2023 · 10 comments
Labels
consideration A potential feature or improvement that is under review for possible development and implementation size:XL - 8 Sizing estimation point story A user-oriented description of a feature

Comments

@MarianRaphael
Copy link
Contributor

MarianRaphael commented Jun 30, 2023

Description

As a Node-RED developer and FlowForge user,
I want to share environment variables at various scopes - global, team, and application,
So that I can efficiently manage and organize variables according to their usage and scope, increasing the maintainability of our projects.

Which customers would this be availble to

Licensed Edition (EE)

Acceptance Criteria

  • appropriate access controls to ensure that only authorized users can create, modify, or delete variables at each scope level
  • creation and management of environment variables at different levels of scope: global, team, and application

Have you provided an initial effort estimate for this issue?

I have provided an initial effort estimate

@MarianRaphael MarianRaphael added story A user-oriented description of a feature size:XL - 8 Sizing estimation point labels Jun 30, 2023
@MarianRaphael MarianRaphael added the consideration A potential feature or improvement that is under review for possible development and implementation label Jun 30, 2023
@ZJvandeWeg
Copy link
Member

@joepavitt Can we reuse the right most column for the overwritten value icon, or when it's inherited from a group?

@joepavitt
Copy link
Contributor

Had considered that, but it can be both inherited and locked or deprecated...

@joepavitt
Copy link
Contributor

Also wanted to make more explicit differentiation between locally/newly defined vars, and inherited

@ZJvandeWeg
Copy link
Member

Deprecated we can remove through a migration. We add them to each instance in the db, and remove their default status.

Inherited cannot be locked, so the left bar is available?

Also wanted to make more explicit differentiation between locally/newly defined vars

Can you elaborate?

@joepavitt
Copy link
Contributor

Inherited cannot be locked, so the left bar is available

Why not? If I define a common env var at the Team/Application level that I want set, and not changed, across all instances, then that's both locked and inherited?

@joepavitt
Copy link
Contributor

Deprecated we can remove through a migration

I suspect this isn't that simple as possibly customer flows that are using these deprecated env vars?

@ZJvandeWeg
Copy link
Member

@joepavitt If we explicitly set them instead, than the new instances don't need them to be set anymore.

@joepavitt
Copy link
Contributor

Removed icon int he value cell, but kept the one left-most

Screenshot 2023-07-06 at 08 14 16

@joepavitt
Copy link
Contributor

Can you elaborate?

I felt like (happy to validate of course) that when viewing the Environment Variables at an Instance-level, you'd want to know, clearly, which ones were defined above (at Application/Team) and which ones were bespoke for this Instance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
consideration A potential feature or improvement that is under review for possible development and implementation size:XL - 8 Sizing estimation point story A user-oriented description of a feature
Projects
Status: No status
Development

No branches or pull requests

3 participants