We have a TFS user who appears to have the same permissions as a colleague in their team. However this user can't be #mentioned despite having the ability to open and close and otherwise edit the bug that they can't be mentioned in.
The following error is emailed to me following attempting to #mention this user.
#Joe Bloggs cannot be mentioned in the Bug 41729. The user does not have
sufficient permissions.
We can't see any differences between a user that can be tagged and one that can't.
We were getting this same error.
Went into the project settings -> security.
Clicked "remove" on that user
at which point the "remove" changed into an "undo".
Clicked the "undo".
Now we are no longer seeing this error. Seems like something internally just needed to be recombobulated :-)
If you are sure that the user exists and can be mentioned with "Joe Bloggs" then they do not have read permission on the bug you are referring to. You should go back and check what group membership they have in the project.
Related
I am getting the following error in in visualstudio.com when accessing nuget feed:
{"$id":"1","innerException":null,"message":"4d90beec-a2e5-4f8f-8108-23480a7b53f8\
MICROSOFT-ACCOUNT lacks permission to complete this action.
You need to have 'ReadPackages'.","typeName":
"Microsoft.VisualStudio.Services.Feed.WebApi.FeedNeedsPermissionsException,
Microsoft.VisualStudio.Services.Feed.WebApi",
"typeKey":"FeedNeedsPermissionsException","errorCode":0,"eventId":3000}
The above answer works for most cases. But if you are still getting that issue check that
The user has access to the correct project (organization settings)
The user is also part of the team for that project (within the project settings)
Set the correct access level in TFS.
The default access level is set to “Stakeholder”.
https://blogs.msdn.microsoft.com/tfssetup/2016/12/06/tfs-2017-nuget-publisher-task-fails-with-401-unauthorized-exception/
Also more information here:
https://github.com/Microsoft/vsts-tasks/issues/4319
I have looked up various answers on here and none has helped me thus far.
I am rebuilding a database project and it is complaining about one particular script:
CREATE USER [doro] FOR LOGIN [doro];
Now there are other scripts under the security folder which are exactly the same with different logins - which it does not complain about.
With this particular user the error is:
SQL71501: User [doro] has an unresolved reference to Login [doro].
I tried following some suggestions and using the "Add New" option to add the login but this made several other errors appear in relation to that login.
I have the master database reference.
Any suggestions appreciated.
Also, does a rebuild sync the dacpac with the original source database or do you have to manually do a compare and update?
thanks,
KS
While trying to cleanup a Sonar instance from unwanted users/permissions it seems that the permissions for the Administrator have been withdrawn. We can no longer see the settings menu item (normally appears next to the Administrators login link), cannot change alerts any more ...
I have spent a couple of hours now trying to find out where in the DB these permissions reside and hoping to put them back using some insert statements in the DB.
Can someone explain how to put this back? I can login with the Administrator but that is all, no more administrator permissions.
This happens often enough that a FAQ section has been created for it. You'll have to fix it at the database level:
INSERT INTO user_roles(user_id, role) VALUES ((select id from users where login='mylogin'), 'admin');
According to Google's documentation regarding container-specific installable triggers, the trigger will "run as the user who installed the trigger, not as the user triggering the event."
This seems to mean that a trigger could update a protected sheet in Google Docs, because although the user may not be able to edit the protected sheet, the trigger could if it was installed by a user with write privileges.
To test this idea in the simplest way possible, I tried using an onOpen event that triggers a script that edits the value of a cell on a protected sheet. This was installed by a user that can edit the sheet. Although it works if the user opening the sheet has write access, it fails to update the sheet if the user does not.
Is this due to my misunderstanding of how it is supposed to work, or is it a bug? It seems like Google was pretty clear that the script runs with the authority of the user that uploaded the script.
It's a bug.
In March I [posted][1] on the old GAS forum about it. Anton Soradoi from Google replied to me privately by email because I was unable to share the spreadsheet publicly. I shared it with him and got this reply via email on Tue Apr 3rd:
"The issue you are running into appears to be a bug.
We are currently investigating it.
I will get back to you with more info once I have it."
I didn't raise an issue because they were already on the case but I haven't heard any more since.
it's interesting.
if you did this for onEdit, you would have to manually add a trigger to run "On Edit" and call onEdit function and it would run under your name whenever anybody edited something, but I think for onOpen it will run only if you are the user opening the spreadsheet, you can try.
I've been trying to set issues to status "fixed" from my SVN commits, but it keeps on failing. This is what I've been trying as SVN comment:
#TCSE-20 fixed
and
TCSE-20 fixed
Where TCSE-20 of course is my issue id. I then run my build in TeamCity, which is linked to the YouTrack project.
The comment gets recognized in YouTrack as it's added to the Comments tab. But the state remains as Submitted. What am I doing wrong?
The solution was what I was hinting in my comment. I am the administrator of our YouTrack server, and I used my email address for the "root" account, as well as having my own user, based on my username, with the same email address. When I changed the "root" accounts email address to one of my colleagues, the commands executed correctly.
Now I would like to know how to solve this better, like disabling "root" from the user lookup function, but that will be another issue. :-)