[feature] - Add feature of promoting suborg to parent org#371
[feature] - Add feature of promoting suborg to parent org#371LalitDeore wants to merge 2 commits intoShuffle:mainfrom
Conversation
frikky
left a comment
frikky
left a comment
There was a problem hiding this comment.
I'm sure it works fine for support users only, but I'm worried about opening it up.
It is a cool feature tho, if it works.
| return | ||
| } | ||
|
|
||
| if !user.SupportAccess { |
There was a problem hiding this comment.
I'm primarily worried what would happen here if we give this to users, which is.. kind of the point. They should control this themselves.
There was a problem hiding this comment.
Should we make this available to normal users? I am afraid that if someone promotes a sub-organization to a parent organization without understanding the impact, they could lose access to distributed auth, files, datastore, and environment data due to how things are currently set up and this can impact workflows. I would prefer to keep this limited to support users. Let me know in case you want me to make it public for normal users.
There was a problem hiding this comment.
They can just move it back then? References aren't lost..
| } | ||
|
|
||
| for _, workflow := range workflowItems { | ||
| if workflow.ParentWorkflowId == "" { |
There was a problem hiding this comment.
Wouldn't this be the same as "stealing" a workflow?
Not sure.
There was a problem hiding this comment.
We skip workflows where workflow.ParentWorkflowId == "".
If a workflow has a parent org ID, it means the workflow is distributed, so we reset it to empty but we are making copy of workflow when distributed. That's why it is still accessible after promoting to parent org.
| } | ||
| } | ||
|
|
||
| func HandlePromoteSubOrg(resp http.ResponseWriter, request *http.Request) { |
There was a problem hiding this comment.
Please document the API right away on the "API" docs. Otherwise we will forget it.
There was a problem hiding this comment.
(this is why I try to not make new APIs if we don't NEED to) :)
There was a problem hiding this comment.
Okay, will write doc for it.
There was a problem hiding this comment.
I have added doc for it in below PR.
frikky
left a comment
frikky
left a comment
There was a problem hiding this comment.
And again, I want to emphasise: The usage of distributed systems is lower than 0.1% of our userbase. Literally one in 1k max. And they are power-users. Power-users need power-tools.
Publishing the system is the whole point. Otherwhise, why have an API at all? That's just code that won't be used..?
Which I tried to make it clear:
- MANUALLY DO THIS THIS TIME. Why do we need to waste time building an endpoint that won't be used?
... or
- Build a proper system that can be used by our users at scale to change parent/child relations at will if they are admins. That way it could actually be useful for management
| return | ||
| } | ||
|
|
||
| if !user.SupportAccess { |
There was a problem hiding this comment.
They can just move it back then? References aren't lost..
2 participants
When a sub-organization is promoted to a parent organization:
Note: This feature is available only to support users initially.