I want to give permission for a specific user in my TFS project to do the following.
Create Iterations
Edit the Iterations
Activate the Iteration (In simpler words, 'tick' the Iterations so that they can be seen by others in the team)
MSDN says that
To create or modify areas or iterations, you must either be a member of the Project Administrators group, or your Create and order child nodes, Delete this node, and Edit this node permissions must be set to Allow for the area or iteration node that you want to modify. MSDN
I do not want to give Project Administrator permissions to this specific user.
Hence I gave the following permissions to him in the Parent Iteration.
permissions - screenshot
When logged in as the specific user, TFS says that
You do not have sufficient permissions to configure iterations for this team. You must either be a team administrator or a project administrator.
However, the User can do the following.
Create Child Nodes
Edit the Start/End Dates of existing/new iterations
My question is:
Is there any other way to give a user the permission to 'tick' an iteration without giving him 'Edit collection level permission' or 'project admin permission'
You can create a new TFS group under your team project. Then, grant that group "Edit Project Level Information" permissions. This will allow the user to check the tick box to make the iteration show up in the backlog task board.
What I did was create a "[TEAM PROJECT]\Project Managers" TFS group, I granted that group all permissions on the root node of both the Areas and Iterations. And I also granted that group "Edit Project Level Information." My user was then able to manage areas and iterations - including the "ticking" to activate the iteration.
Related
Please explain how content security works on SenseNet.
Especially how to read the following SN database view:
PermissionInfoView
What EFEntries(LocalOnly) flag is used for?
In a nutshell: it works very similarly to the file system permissions in Windows.
You can define permissions for individual users, or (more preferably) groups and org units. Defining a permission happens on a content, usually on a container like a workspace or folder. For example you give Open and Save permissions for the Editors group on the Articles folder.
There is inheritance: child content will inherit permissions you defined on the parent folder (unless it was defined as local only, which means not propagated to children). For example if you define a local only Save permission on a document library for John, he will be able to modify the doclib content itself (e.g. change its display name), but not the files inside the library.
To make things a bit more complex, you can break permissions on a content, for example to remove an inherited permission. This may be necessary if you want to hide a subfolder.
For details please visit the Permission System article.
Permission overview GUI
If you have installed the WebPages component of SN7, you get a Permission Overview page that may help you understand the current permission settings in the tree.
The Permission info database view
In case you have the Services component only (so no GUI) or you really want to look under the hood, you can check out this db view to see all the permission settings in the system.
The records here contain all the defined permission entries in the system (so inherited ones cannot be seen here, they are calculated in memory). The Path is the content where the permissions are defined, the Identity can be a user or group, LocalOnly means not propagated to children (see above), the rest is a list of permissions (e.g. Open or Save) and whether they are allowed, denied or undefined.
For details about this and other db elements please visit the DB structure article.
Newly upgraded TFS server has two user accounts created, "Project Collection Build Service" and "Project Collection Build Service (Team Foundation)". Both accounts have the same GUID (listed in the Username or Scope column). These were created by TFS and the GUID begins with "Build\" Attempts to delete either results in an error. Using TFSConfig to list user accounts, these do not show up.
To run builds, the Project Collection Build Service Accounts group must have, as a member, the Project Collection Build Service user account. Both of the accounts listed above can't be added to the group because of the matching GUIDs.
Every few hours, builds start failing with error stating
The workspace xxxx;Project Collection Build Service does not exist.
This means that the user account with the added (TEAM FOUNDATION) is in the group. If it is removed and the other one is added, builds start working again. Until a few hours later when the builds begin to fail with error stating
The workspace xxxx;Project Collection Build Service (TEAM FOUNDATION) does not exist.
Swap them again and builds start working. It appears it is applying the user account via the GUID but then doing some kind of verification based on the Display Name.
Some help pinpointing this error came from the post at http://www.codewrecks.com/blog/index.php/2016/01/15/troubleshoot-error-tf140
44-in-build-vnext-for-tfs2015/ but I can't find any other references to an issue with these accounts.
You may try to use tfssecurity /gd command to delete a server-level or collection-level group:
tfssecurity /gd groupIdentity [/collection:CollectionURL] [/server:ServerURL]
The group identity is the security identifier (SID). For more information about finding the SID of a group, see /im: Display information about identities that compose direct membership. You can also use the friendly name to delete a group.
Finally found solution at this link:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/495e59d2-d3e3-432d-be
98-1f0c358c2bc2/tf14061-the-workspace-xxxx-does-not-exist?forum=tfsbuild
After deleting all Agents and associated workspaces then adding a new agent and rebooting the server we have had no problems.
Is there a way to set user permissions to restrict changing states (status) or moving items from one sprint (iteration) to another in Microsoft TFS 2015?
Appreciate the help!
"Changing the state of the work item" and "Moving the work item to a different iteration" are both examples of a more generic permission - Edit Work Item. It is defined on area level in TFS. For a specific area path you can deny "Edit work items in this node" permission, and the user won't be able to
Change the state of work items in this area
Move the work items in this area to a different iteration
Modify the work items in any other way
First two points is what you aim for. The last is probably not. If you need to granular permissions on a field level, I am almost sure it is not possible.
I have some issues with the Plone 4.3.1 permission settings. But I have come long way with the existing documentation and Aspelli's book. But I cannot figure out why I am unable to create any object in a folder, even as Site Administrator, after setting up a workflow-state that grants permissions to a specific user role.
The workflow-state is called "Show_External" and the permissions that are set through the Permissions tab of the workflow state are as follows:
Permission Acquire Site Admin Ext_Supplier
Access content information - X X
List folder contents - X X
Modify portal content - X X
View - X X
I do not want to "Acquire" any permissions because the new role is for an external supplier that has no business with anything else on this particular site.
The result - much against what I expected - is that no one can create any object. The option is shown in the interface, but any attempt results in Error Please correct the indicated errors.. No errors are indicated however.
What I can do is make the objects (folders and files) in another folder and then copy paste them to the folder that is set in the workflow-state. Stranger still, once I copy the folder as a subfolder to the External Supplier folder a can add files through QuickUpload, but not by selecting "Add file".
What am I missing in my understanding of the permissions?
You likely ran into a bug, which was fixed just now:
http://plone.293351.n2.nabble.com/Bug-on-sharing-page-upgrade-plone-app-workflow-to-2-1-6-td7566655.html
Does upgrading p.a.workflow help?
The solution in the end was to install plone.app.workflowmanager. For some reason that I do not understand the "Permission Roles" that show up under the workflow states created through ZMI did not have either the "Add" or the Review Permission.
Correcting the permissions through the workflow manager solved the problems.
If you try it out then note that you need to check the "Advanced Mode" checkbox to be able to update the permission settings on existing objects.
Having dregdged through ZMI screens for the past few days, the Workflow Manager is a great improvement! Very nicely done.
If someone can still explain why there is a difference between the permissions that I set through ZMI and the workflow manager I would very much like to know (feel free to edit this answer, marked as "community wiki").
How can I hide a build definition in RTC ?
I can change the 'Project or Team Area' of a build to a specified team that contain the just the developers. Should this action hide the build definition from team members that are not in the 'Project or Team Area' for this build ?
Yes, it should.
This looks like the same way I am hiding a Stream or a component in RTC, as I detail in "How to hide a stream from particular users in RTC source control?".
However, this thread doesn't mention visibility, only permission for:
requesting a build from a build definition
modifying a build definition
So it might not do what you want.
On the permission aspect:
Note that process permissions are looked up starting at the given process area and looking up its parent chain. Permissions may be overridden at the team area level, so different teams within the same project may have different permissions. Also note that the permissions are looked up for a particular user (i.e. the user running JBE or the Ant tasks), they're not defined directly for the engine itself.
For example, if you wanted to prevent team A's engine from processing requests for team B, then you would define:
two build users, bobA and bobB,
and two engines, engineA and engineB (associated with teamA and teamB respectively),
with bobA granted the relevant permissions in teamA, but not teamB, and the opposite for bobB.
When running the two JBEs, one would specify -userId bobA -engineId engineA, and the other would use bobB and engineB.
The build user(s) should also have permission to modify the build definition(s) for the relevant engine(s), since after the build request has been determined, it's the process area for the build definition that governs:
all further operations for the build (updating its state and status, contributing downloads/logs, etc.) and
the definition itself (updating the average build time once the build is complete).