I want to make an EA-Project where I and some other people can see all information but some others should only see selected information.
Is it possible to create an EA-Project and do some settings so some defined elements or tags or element information are shown or hidden to defined users?
Or do i have to create two seperate EA-Projects?
No, that is not possible, if a user has access to an element, he has access to all its properties.
What you can do is hide parts of the model. There are two options:
Hide Project Root
You can use a group lock to hide a project root from users outside of that group. This is mainly a usability feature as it doesn't prevent users from accessing the contents of the hidden project root in other ways.
From the manual:
When you set a Group Lock on a Root Node, you can also select a checkbox to hide the Package in the Browser window from users who are not members of the locking group or Administrators. If you change the type of lock, or remove the lock altogether, the Package becomes visible to all users.
This feature hides the Root Package and its contents from initial view in the Browser window. It does not prevent the contents of the Package from being exposed in Model Searches. If you want to completely hide a Package from groups of users, consider Pro Cloud Server Visibility Levels.
Pro Cloud Server Visibility Levels
This is the real thing. It uses database row level security to prevent certain users from seeing the information stored in these rows. You'll need Pro Cloud Server to setup these visibility levels.
See the manual for more information
Related
In Azure DevOps, we have created Epics to group features together.
Now we would like to make some of them visible to a specific group of users. They would be in read-only mode.
How can it be done ? We know it is possible to create rules to make some fields read-only, but it goes as far as that. Also, is it possible to make all fields read-only instead of going through each of them.
But most importantly how can we hide all epics but these specific ones for that group of users ?
Your requirements should be able to be achieved through the area settings.
Project Settings -> Team configuration -> Areas-> Security
Put the Epics you want only some people to see under an Area, then put some people you don’t want to see these epics into a group, and set "View work items in this node" to Deny . Then users in this group will not see these epics.
As for setting some epics as read-only, please create a new Area and set "Edit work items in this node" in the above figure to Deny to prevent users in this group from modifying these epics.
I can't figure out if it possible and how it can be done to allow certain users in a Visual Studio Team Services project to see only the work items they created, instead of them all.
Thanks in advance for all your help.
For now, there is no ways to set permissions for a user to only view work items which were created by oneself.
It's only available to set permission based on Iterations and Areas for now.
But there has an user voice field level security permissions which suggest similar feature, you can vote and follow up.
And the features in below two user voices have already added in our backlog, when the features are archeived, it can also benefit the situation you met:
Hide Work Item Types (WITs) based on permission/security group
Add ability to hide/mask fields in a work item based on security/permissions
This is not supported. It used to be in the on-prem product a long time ago in the "Work item only view", but that has been removed in favour of the Stakeholder view.
I currently have a few projects pages and I’m looking to display a list of team members that are associated with each project (a member may be associated with multiple projects) but I’m not sure how I can create this. A taxonomy doesn’t provide enough information (ideally want to show an image with name and short bio) so I’m assuming I’ll need to create a /team-members/ page with member pages below it and pull this in somehow to each project.
How would I go about allowing team members to be added to projects through the admin panel?
Basically you can create a page for each team member. These page can be unvisible if you don't want to display them alone
Then you create one page for each project.
When you want to use one member page as a part of one project page, you just include it:
{{ page.find('/some/other.page').content }}
Note that the above code may require you to activate twig parsing on your pages.
This way you can include the same team member in several project pages and update team member content in only one place from the admin panel.
Another approach is to create a plugin that will enable you to manage projects and member as you want to, but it may be a little overkill given Grav can do what you want out of the box.
I am currently writing an iOS application in Swift, and upon login, you are given 1 of 3 different account credentials: New User, Current Member, and Admin Member. A New User is defined as an account that has not been placed into a group, a Current Member is defined as an account that is currently in a group, and an Admin member is defined as an account that is the admin for a group.
I want to try to keep the UI the same for all accounts, to keep usability high for every user. I see 2 options, I can either branch 3 different storyboard routes from login and design them to be the same, or I can design 1 flexible storyboard that loads views based on permissions.
I would like to do option #2, however my question is: Is there the functionality in Swift to run a single, agile storyboard view that changes it's elements based off of permissions? Or would I have better luck creating three different storyboard branches?
Edit: To clarify, all data pertaining to each account will be drawn from a Firebase web application, so the UI itself will not have to worry about storing and fetching data based on account permissions from it's own memory.
Not sure what you mean by "agile storyboard", but you can have your storyboard to include all visual elements for all users and then do programatic adaptation, weather it's to hide/show some views, change colors etc.
However if your views are very different you may opt to create common visual elements in *.xib files and then load them programmatically as needed for a specific user type.
As I see it, you can keep the login permissions for them and depending on that, show it through hiding different objects in your one viewcontroller. If it's a tab bar, through the login permissions, you can hide the specific bar that can't be accessed by the NEW USER.
I want to create an admin bundle, that somehow detects other bundles and tries to add them to the menu and to the same RBAC context.
Eg:
AdminBundle defines a route /admin/dashboard, that requires authentication and authorization. There you can see 3 items in the menu, eg: dashboard, config (some config stored in the db), and users (CRUD for users, found in the UserBundle)
Then someone adds a ProductBundle, which deals with CRUD for e-commerce products or something. Somehow, without modifying any code in AdminBundle, we have now a new item 'products', available in the menu in /admin/dashboard
Later on, the products CRUD is no longer needed, so we just delete the ProductBundle, and it automagically disappears from the admin dashboard menu.
How would you go about implementing something like this? Is there any native support for a plugin-like design like this in symfony 2?
I don't know about a full plugin solution but my approach would be:
There is one "master backend" call it MasterAdminBundle for the sake of conversation. This bundle contains a base.html.twig which just helps define the navigation bar of the Administration area and a {% block content %}. It also has some kind of MenuService which displays the menu. I'd have my other bundles register with this service an AdminMenu subclass by way of using the Tag System just as a Voter can register with the Security Context (see here).
In the base.html.twig I'd then likely use an Embedded Controller to render the menu.
Now with this sort of framework in place your other bundles can stay encapsulated by keeping their own admin routes and interfaces:
ProductController would now also have ProductAdminController where you can use a route prefix #Route("/admin") on the class definition. Any routes could then render templates from within the bundle since templates are held under the controller name. Acme\ProductBundle\Resources\views\ProductAdmin\edit_products.html.twig as long as they extend the base.html.twig from MasterAdminBundle and put their content into the content block.
For other things like a dashboard that you wanted to plug other bundles into I'd likely just keep going the same way, create a service in the MasterAdminBundle and use tags to load other classes into it with the data required.
Hope that makes sense, maybe others will have a better solution to this, I'm interested to hear also since this is something I'm trying to tackle at the moment also.