There intentionally isn't a way to hide components from the canvas. You can use the analogy of being in an apartment building and seeing all the doors... you can only see whats inside the one you have the key to, but you still know all the other locked doors are there.
On Mon, May 14, 2018 at 4:10 PM, Anil Rai <anilrain...@gmail.com> wrote: > On the same topic, we currently have many teams sharing our common > development environment. We have created groups for each team and added > users to the groups. > Each team is given a process group and this process group is assigned to > that specific group. So that they can only work on their process group and > do not mess with others. > It works fine. > Only problem on the canvas is that while I cannot mess with other process > groups, I still see other process groups in dotted lines and grayed out. Is > there a way to hide the other process groups from the canvas that I do not > have permissions to? > > Thanks > Anil > > > > On Mon, May 14, 2018 at 3:10 PM, Anil Rai <anilrain...@gmail.com> wrote: > >> Thanks for the detailed explanation Bryan. >> >> Cheers >> Anil >> >> >> On Mon, May 14, 2018 at 3:01 PM, Bryan Bende <bbe...@gmail.com> wrote: >> >>> Hello, >>> >>> When a node joins the clusters, if the node has an empty flow.xml, no >>> users, and no authorizations, then the node will inherit all of those >>> from the cluster, but if any of those are populated then it won't be >>> able to join. >>> >>> One common issue that prevents this from working, is if you have an >>> initial admin populated on the new node, then it starts up and creates >>> the initial admin and policies locally, and when it attempts to join >>> the cluster it will not inherit because now technically it has a >>> user/policies defined which are in conflict with the cluster. So the >>> trick for a new node is to not fill in the initial admin in >>> authorizers.xml. >>> >>> Regarding creating users/groups/policies... anything you can do in the >>> UI can be done via the REST API, the best way to take a look is to >>> open Chrome Dev tools while you use the UI and checkout the calls made >>> in the network tab. >>> >>> You could write a script to perform any of these calls and automate >>> the creation. >>> >>> Thanks, >>> >>> Bryan >>> >>> >>> On Mon, May 14, 2018 at 2:22 PM, Anil Rai <anilrain...@gmail.com> wrote: >>> > All, >>> > >>> > We noticed that we cannot add/modify users and policies when 1 node in a >>> > cluster is down. So seems like all nodes should have the latest and >>> > identical users.xml and auth*.xml. Is this correct? Shouldn't the latest >>> > and up to date files be copied to other nodes during startup instead? >>> (like >>> > flow.gz) >>> > >>> > Secondly, we configures groups, users and policies manually via the >>> canvas. >>> > Is there any automated way? and how do we propagate the users to other >>> > environments? >>> > >>> > Thanks >>> > Anil >>> >> >>
