Visibility into analyses and models in a custom view is managed by defining specific domains and by associating only domains (with analyses and models of interest included) to the access group associated to a specific user. Access rights cannot be assigned analyses by analyses.
At analysis level you can only decide if you want to make it 'Private' or keep it 'Public' but if you make it 'Private' it will be visible only to the analysis creator.
I hope it clarifies,
I don't think you understand the question. I want users to be able to change which analysis the analysis viewer widget points to, without giving them privileges to modify the custom view. I have created a dozen analysis in a domain. The custom view has multiple pages with just two analysis viewer widgets. The end users want to be able to choose which two of 12 analysis are on each page, and the ability to change the pair frequently. I have provided this ability, but I had to provide View Editor privileges. These users should not have editor privileges for anything.
changing the Analysis each widget points to is definitely a View-configuration task, not something that final users have to do. So if your final users need to see different analysis types each time they access the View, you should re-design your View so that changing the analysis type is no more required. For example you could create different pages configured with all needed analyses types and let the final users choice the right "details" page to see.
Again you are not understanding the use case. There are 24 JVMs for which I have created analysis. I created a custom view with all 24 workloads on the view. That is too much for the end users. They assign pairs of JVMs to development teams for 30 days at a time. The pair assigned are not always the same. They want one page where they can select the pair of JVMs they want to review so they know if development team A is using the environment. To make a separate page with all possible combinations is not practical, so if the widget allowed for a drop down list of the analysis in the domain, then end users could look at the pair of JVMs they care about. I can and have provided that access, but I had to teach them how to use the widget, and I had to give them view editor privileges. I don't want to do that.
Any way you can share a screenshot - edited to remove any confidential information, showing what the View should look like after the development team has chosen the pair of JVM workloads that they want to see in the view? Just enough to see the different workloads and what metrics you are showing in the analysis including how they should look?
I do not believe there is something in the product that is exactly what you are requesting, where users can chose which two specific analysis that they want to review within the custom view, but I am wondering whether an analysis could be created where the content shown will changes based on a custom filter that you allow customers to select the JVM workloads you want to see.
You can send the screenshot directly to me in case you believe that the content is confidential or too sensitive to show in communities.
See screen shots below. I have added a description at the top of each screen shot.
The screen shot below shows one of the pages I have created in this custom view for our end users. I have provided one end user training and access to modify this view. He is setting up pairs of JVMs for his team to monitor development team use of this environment. Note: the first page in this view shows all 24 workload CPU charts for the 24 different JVMs this team is managing. Lastly, note Workload CPU charts are capped at 50% as these are normalized with logical core count.
The screen shot below shows the domain the custom view has access to, and the possible workload CPU analysis they might want to choose from. Each analysis name that ends in “Workload” is a workload CPU chart. The end users assign pairs of these to different development groups for different time intervals. They almost never assign the same pairs. They use these charts to see if the development teams are doing any work. They had too many teams asking for pairs and then not using them for months. This led to more JVMs being created and more deployments, as the same code is deployed to all BC, BC8, PC, and CFR JVMs. We are helping them maximize the use of their environment.