We are getting the locked for shared use message when trying to upload/checkout a file in a SharePoint library.
The user that is not online at the moment. I tried removed her sharing permissions on the file and its still shows she is editing it (upper right corner of the document).
Is there a way to completely remove existing sharing locks on a file so we can upload a new version of the file?
Ideally we would like way to do this with the UI. But any ideas how remove all existing locks with code on the API would also be helpful.
I found that it was not easy to remove the lock cleanly. Basically the only way to remove the type of we experienced was to delete the file and re-add
I was once able to resolve this by forcing them to sign out of all sessions (Admin->Users->Active Users) - Your mileage may vary and it sucks for the user.
Checking out / in seems an outdated way to handle things unless you have a specific reason. Curious to hear more. -Shane
Easiest way to do this is to delete the file then restore from recycle bin.
Related
Is there any way to prevent any changes (i.e., lock or hide) to the calculated columns or scripts in a Spotfire file (.dxp).
We are trying to deploy a template / file we built in Spotfire and would like our team to use it as is and prevent any accidental changes while we continue to work on updates etc...
Any help would be greatly appreciated!
There are a couple of ways you can go about this. For scripting you can remove the scripting licenses from the users of the dxp. But this wouldn't prevent the calculated column changes. The best method, in my opinion, is duplication and versioning.
Deploy your live template to a public folder and then keep a backup in a folder where only you have access. Then, edit another copy of the template with a version control number like Template2_2.dxp. When you are ready to deploy it, just overwrite the live version. You will already have a back up of the live version, so now you just need to backup your newest one.
It's the most basic but easy method and ensures you don't leave room for mistakes or over limit your users by removing licenses.
Is it possible to add custom feed programmatically to Web Platform Installer? I tried adding the feed manually and found that the feed location is stored in `%APPDATA%\Microsoft\Web Platform Installer\web.preferences file. However the file seems somewhat cryptic and I would not like to modify it manually. Is there any API for that?
Update: even if this web.preferences file could be edited it is not the way to go as it is user specific file and I need system wide configuration.
Based on this link,
Sorry, there isn't a way to do that currently (for security reasons,
we don't allow an untrusted feed to be loaded without the user's
consent)
Once the feed is added via the Options dialog, it does persist between
sessions
I think we can't add custom feed without intervene from user. Maybe you can use WebpiCmd.exe
that can be configured programmatically via scripts.
C:\Program Files\Microsoft\Web Platform Installer>WebpiCmd.exe /List /Feeds:http://yourcustomwpifeed.co.id/customFeed.xml
A little late, but maybe it may interest others. You can modify the file %APPDATA%\Microsoft\Web Platform Installer\webpi.preferences. Yes, it is a little cryptic, but here's my post about how to do it.
The file webpi.preferences is user-specific. If you want to set settings for all users, all I can think of is to write a bootstrapper application that first modifies webpi.preferences (using the code in the post) and then runs WebPlatformInstaller.exe.
I need to work with several teams and need to be able to share requirements and design documents. Most people won't be too technical, so I want to avoid source code tools. The main requirements are:
Easy sharing via links. I don't want people to have to install multple tools just to see a file or learn anything about svn checkout.
Permissions - I want to allow view only access to most people, with some having add/edit permissions. I don't want anyone to be able to permanently delete anything.
Revision History - I want to see who has added and edited files and be able to revert to previous versions.
I've tried Dropbox and SkyDrive, but they each have faults. Dropbox allows users to permanently delete files, and it will even delete the file from your local machine when it is synced. SkyDrive doesn't allow enough fine grained permissions or revision history. Do I need a CMS system like Drupal]? Would Sharepoint be the proper tool? I don't necessarily need an open source solution. The easier it is to set up and administer, the better.
Just my personal bias, but I hate Sharepoint. (I see this Q is tagged Sharepoint)
I much prefer some sort of Wiki, and have had good experience with TWIKI. It certainly meets the three basic requirements.
AFAIK Dropbox never deletes files "permanently" but you can undo it via the web interface. If I remember correctly you also can restore old versions of files but I cannot try it right now.
Adobe Buzzword might do most of what you are looking for.
If you do not need online document creation, a traditional CMS is not really what you are after. Drupal could serve your purposes, but it would not be straightforward- afterall, file attachments are second class citizens for a web content system.
Alfresco is a system I've heard used as a competitor for Sharepoint and useful for managing documents.
To quickly summarise my question:
Is it feasible to programmatically change the name of a directory (with both files and sub-folders) in SharePoint? I am expecting that users will have files checked out on at least some occasions what I am attempting the rename.
The background:
I am currently contracting for a company that produces web based software (ASP.NET) with a configurable document management system. The system can be configured to use different underlying systems, with the most common environment being SharePoint (WSS 3).
I have been assigned a task to extend what has to now been a fairly simple system (simply output files into a fixed directory structure, occasionally read). Having never worked with SharePoint before I am doing some research on best practices, and am attempting to work out what is viable. At this stage I do not have access to a testing environment myself, so am limited to reading up online.
One request is to have the directory structure reflect the name (as one example) of the current client - so all documentation for a client will be in one place, and can be accessed externally via SharePoint or other compatible applications. The specification cites that if the name of the client changes then the directory structure should immediately update. My concern is that this will either directly cause errors (eg. Permission denied) or indirectly cause errors (loss of work for users who have externally checked out files).
As a follow up question if there are concerns with the above, is there a better way to implement the above? I have looked at suggesting the users use views to access the structure in SharePoint, however there is a concern from our BA that users will not be able to directly upload new files into this structure.
Thanks
The issue with Folders in SharePoint is that they are not really folders in the way you would expect of a file system. All files in a SiteCollection are stored in one big-assed table on the Database (checkout the AllDocs table).
I cannot categorically say it is safe to rename the folder without doing a bit of testing, I know that the folders "name" is not the key to accessing the document, despite it appearing to be based on the Url you see in the browser.
The best bet is to do a quick test, but I am pretty sure that your plan will not be a problem.
The potential issue is if any Content Query Web Parts etc rely on specific folders to exist or if any other "code" or "pages" look for that folder and not the folderId.
Save the content of the list before you "attempt" it in production. You don't want to loose data.
Checked out documents will still work the way you expect them to.
You may however have to run a crawl again.
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.