I have directories in TFS (server is 2010, users are using VS 2012 and 2013), which I want to prevent anyone from working in. I still want them to be there, so users can read the files and view history, but I don't want to let them check anything out or in.
The reason is that we have a bunch of outdated branches which people have created all willy-nilly with terrible names over the years, and we're hoping to not have to move/reorganize them all right now - but I don't want anyone new to accidentally work on one of the old branches without realizing it.
I can lock the directories, but then they show up indefinitely in my on personal changes as locked - I don't want this junking up my workspace, and if I ever leave, I'm sure my locks will be removed anyway.
Is there any "disable" command or anything else I can do to stop checkouts/checkins on directories?
if you right click on the branch you should get security options. in TFS 2013 its Advanced > Security (sorry not got 2010 instance in front of me)
you can then set permissions on the branch, set read for your normal users and disable Check in / check out for them
Related
I am using GitLab in combination with Sourcetree. Every time I want to commit something, I would go to my Domino Designer and right click the database, click Team Development and use 'Sync with ODP...'.
Most of the time everything works perfectly fine but sometimes the synchronization dialog pops up and just wont go away. In my Sourcetree I can see that some files are waiting to be commited but those files are not all.
So the dialog shows up, wont go away and says "Progress information" "Exporting..." and thats it.
There is no "use in background" button there and the 'cancel' button is disabled.
At this point the only thing I can do is to shut down the Designer using the task manager but the problem still wont go away even after restarting my computer and VirtualBox which I am working on (The designer runs on the VM). The only thing that changes: It sometimes gets stuck "later" in the progress.
I have read the designer hangs often due to automatic synchronization. In my case this feature is disabled.
Is there someone who can tell me what causes this problem and how I can fix it?
- Thank you in advance
(The synchronization is in progress for roughly four hours now, with no change)
Are you able to track it down to a specific design element? If there is a corruption in the DXL, the export to the ODP will probably fail. In Package Explorer you can use the "Open With..." right-click menu option to open as XML. Similarly, using the menu options to export as DXL might also highlight any corruption in DXL. Also, is the NSF local or on a server. If it's on a remote server, that may impact the performance of syncing to an ODP (which will be local).
We are using Domino Designer and Sourcetree in combination with Mercurial and Bitbucket for about a year now.
We suffered a lot of difficulties: "hanging" sync, corrupted custom controls, missing files, lot of stress etc.
What I did find out: most of the syncing problems have something to do with the file IconNote in the resources.
Sometimes the associated source contains another version of this resource, so it creates an IconNote.orig. Whenever this file exists, the syncing will go wrong. I guess that IconNote.orig isn't allowed in Resources and so the syncing stops without any warning(!) and often corrupted files.
It took me a very long time find out, but now I know: If IconNote exist in the Git, I delete it instantly! Syncing goes well aftwerwards.
TFS 2012 Checked out by someone else or in another place.
Is there a way to see by who this change is checkout?
I know, because the source code has not been published to the server yet, there's no way to fetch the changes made by that person. Aldo is there no way to get to know who is working on it?
Yes, i can ask arround in the team who is, but we have several teams in different offices.
So its not that obvious...
Yes, there are multiple ways to see who has a file checked out. The mentioned TFS Power tools are one way. Another is to use the commandline tools:
tf status $/TeamProject/Path/To/File.ext
You can use TFS Power Tools (Visual Studio Add-in) and do a search "by Status"
That will show you which items are checked-out, by who and in which workspace.
I found a work-around to get this information, though this procedure may not always be possible. The check-out log shows the list of users who have the file/files checked out.
Right-click on a file/folder and choose Check Out for Edit. In the Output window (if not visible, go to View > Output), you should see something like this:
$/Dev/SharePoint/Finance.Sandbox/Resources/GlobalResources.resx:
opened for edit in TGTRAPP22155;Nigel.Hewitt
opened for edit in SRCGAPP21921;Bob.Carlo
opened for edit in ARSYAPP22182;RDP-ADMN-Jane.Pierre
This should tell you the name of the user and the machine on which the file has been checked out.
(To undo your own check out operation that you just did to get the above information, right-click on the same file/folder and choose Undo Pending Changes. If prompted if you want to "Undo check-out and discard changes?", choose "No to All" to preserve your existing changes and only roll-back check-out on files that don't have changes.)
What I intend to do is lock the whole release branch down so nobody can do check-in.
But there's one developer that does a lot of installer changes, so he has to be able to submit changes.
Is there a way to do it?
Assuming you are an admin for the project: right-click a folder (in your case, your branch root) in source control explorer, click "Advanced/Security" in the menu, and then choose your settings. You may wish to create a new user group, or just add the user individually.
As a side note, it's often more user-friendly if you deny lock and check-in rights (rather than denying check out): if a developer is browsing the code, VS will often try to check out various files, and the error dialogs this shows when security-blocked can be quite intrusive.
I have two reports that I need to build. One that has a dozen or so columns. The other has the same columns + 2 extra. The first one is aimed at employees the second with the additional columns is aimed at Sr. Management.
I have a windows group set up for the proper Sr. Mgt users.
I am using SQL 2012.
I've done some SSRS stuff, but not enough to say I'm competent to do more difficult reports.
The problem I'm having is that we do not want the employees to see the sensitive information in those two columns. Frankly, we don't even want them to know the existence of a different report.
Option 1: I was thinking I can just create a folder in SSRS and add the report there and hide the folder. I created it and applied the security but it seems that everyone can see the folder. Maybe they can't edit anything in it or even maybe they can't read anything in it, but this solution, if unchanged, will not meet the goal of having them not even see it exists.
Option 2: I was thinking that I can use the UserID condition to hide the columns in the report and just create one report that differs depending on who was viewing. There are two issues that surfaced in my research. First, there is no facility for using Windows Groups instead of userid. That would mean I have to maintain the list of people inside the report and boy would that be a pain. And second, my understanding is that the export facility does not respect the column actions -- like hiding.
Am I making this too complicated? Is there an easier way to do this? With no other solution, so I need to put up another instance of SSRS for management and make them go back and forth?
Thanks for your time
Option1: You should not be able to 'browse' for folders unless the 'parent' level permission has an 'everyone' user set up to browse on the higher level. Set up a test account and RDP to a box you can use the test account on. Generally under 'Folder Settings' you set up permission and it cascades down until interupted. If you have a parent permission to browse and a lower one not to, they may be able to browse directories. You can ensure that the directory has ONLY dedicated users and the inherited settings are removed manually.
Option2: I would NOT do this. You will have a maintenance nightmare on your hands as you would have to determine in code who was what and update a list that would probably need to be updated somewhere in SQL or a service. As far as I know SSRS does not work with getting parameters and such directly from AD so you would have to code this time and again. For this reason and security context I would avoid this.
Option3: Set up a 'Subscription' to save the report to a file format(excel, pdf, word, etc) or email on a scedule and turn off permission for everyone but admins. If someone can still see the report or directory there is most likely a security context issue.
Option4: You can do a cheapy 'Hide in tile view' move that for most users will hide the directory unless they go to the URL directly and have access. Click on a folder then choose 'Folder Settings' then check 'hide in tile view' and hit okay. Directory is now gone for most part for regular users browsing in default mode.
I think we can just fix your problem, and avoid inventing a complicated and unnecessary solution:
Option 1: I was thinking I can just create a folder in SSRS and add the report there and hide the folder. I created it and applied the security but it seems that everyone can see the folder. Maybe they can't edit anything in it or even maybe they can't read anything in it, but this solution, if unchanged, will not meet the goal of having them not even see it exists.
Chances are that either you set up the security settings wrong, or there's a bigger configuration nightmare to worry about. What you should do is create the folder, go into the settings of the folder, and edit the security (thus breaking inheritance from the parent folder). Before even adding groups, you need to remove anyone that doesn't belong - namely entries like "YOU\Domain Users" - that gives access to anyone on your domain. Once you've cleaned out whomever shouldn't have access, you can add the users/groups that should. Problem solved.
Now, if that doesn't work, then it would seem to me that your SSRS instance is somehow granting everyone sysadmin access - check the Site Settings to see what users and groups are in the System Administrator role. Investigate any groups thoroughly - is BUILTIN\Administrators a sysadmin in SSRS? Check the group locally on the computer - is there another blanket domain group shown there?
If everyone on your domain has complete access to the SSRS instance, then your goal of "hiding" things is impossible.
What is the general feeling amongst developers regarding the changing of files in the 12 hive.
For example if you were asked to remove the sign is a different user menu item, you would need to modify the relevent user control on the filesystem. Now if you just go and modify it via notepad or copy over and then if you go and bring a new server into the farm you will need to remember to do the same on the new server.
Obvouisly you could deploy the changed file as a solution and have that done automatically, but I'm just wondering if people are hesitant to make changes to the default installed files?
I have done a bit of SharePoint development, and I must tell you that messing with the 12-hive is a ticket to a world of pain if you ever want to move the app.
I'd rather hack up some javascript to hide it, at least that can be bound to the master page, which is much more portable.
And remember, you never know when the next service pack comes around and nukes your changes :)
I agree with Lars. Sometimes you will not be able to avoid it, depending on your needs. But, in general the best policy is to avoid modification if at all possible.
I know that some of the other menu items in the current user menu (change login, my settings, etc) can be changed by removing permissions from the user. Under Users and Groups there is an option for permissions. I can't remember the exact setting (develop at work, not at home), but there are reasonable descriptions next to each of the 30+ permissions. Remove it and you start hiding menu options. No modifications to the 12-hive needed.
There is a very simple rule: if you want to keep official support from Microsoft, don't change any of the files in the 12 hive that are installed by SharePoint.
I've never encountered a situation where the only solution was to change such a file. For example if you want to change an out-of-the-box user control of SharePoint, you can do so by making use of the DelegateControl, and overriding it in a feature.
More info:
http://msdn.microsoft.com/en-us/library/ms463169.aspx
http://www.devx.com/enterprise/Article/36628
I know it's tempting to quickly change a file, and I have to admit sometimes I just do that on a DEV box, but don't go there on a production server!
Not sure if there is much use pitching in, as everyone else pretty much has it covered, but I would also say don't do it. As tempting as it is, its just impossible to know the full impact of that little change you have made.
From a support perspective you will make it difficult for Microsoft support (patches/hotfixes).
From a maintenance perspective you are also opening yourself up to long term costs.
Go the javascript route.
The way to go about it is to use a Sharepoint Solution (WSP) file.
To change the user control, create a new Sharepoint feature with the new functionality.
Include this feature in your solution.
Deploy the solution either using the stsadm command line, or through Central Site Admin.
This will then get automatically deployed to all the servers in your farm, and it avoids you overwriting anything default sharepoint files.
For more info, check out Sharepoint Nuts and Bolts blog on http://www.sharepointnutsandbolts.com/ which give an introduction to WSP and Sharepoint Features.
I've done this many times and I will speak from experience: Never ever touch the onet.xml files within the 12 hive under any circumstance. Any error that you make in there, and to make the CAML even more complex the file is largely whitespace sensitive, will have an impact on every part of SharePoint.
You should also consider that aside from the substantial risk to the installation, you may well be building in dependencies upon your changes that are then over-written in a future patch or service pack.
Most of the time, you can accomplish everything you want to using features and solution packages without modifying the files. However, there are a few (rather annoying) rare cases where your only option would be to modify a file on the system. I have used it for two particular cases so far. One was to add the PDF iFilter to the docicon.xml file, and the other was to add a theme to the themes.xml file. In both cases, it seemed to be the only way to achieve the goal. Still, we used a solution package to write those files out to all the servers in the farm.