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.
Related
Is Sharepoint my best option to replace an aging network of fileshares? There's approx 1TB of data residing among 3 fileshares (1 DFS, 2 NAS boxes). A document management system is in place for new things - the file shares are now just read-only archives/legacy. Our users would simply need to be able to search for and open the documents.
Users are finding it difficult to locate their documents in the file shares and windows search does not often help. Sharepoint was suggested as something which would play nicely with Office documents (99% of the content) and have a good search facility.
Not being a Sharepoint Developer or having had any training on it, I'm getting a little lost. I have set up a test server to try it out using SP2013. I have managed to index each of my file shares and have created a search page. However, results aren't consistent with the indexted items. I assume I need to somehow get the relevant metadata from the files but I have no idea how to go about this.
Could anyone suggest some resources for help on this subject (my searches have mainly turned up paid-for Sharepoint addons or outdated blogs) and any experience of doing something similar? Also happy for any suggestions on ways to achieve this using other software/platforms.
I went with Microsoft Search Server 2010 in the end.
Sharepoint is basically optimized to be a document manager. I think you don't need to buy or donwload addons.
For your problem, metadata are the key! You need to properly specify the metadata.
I give you the theory of a plan document management in SharePoint 2013 :
https://technet.microsoft.com/en-us/library/cc263266.aspx
A nice introduction to metadata :
http://fr.slideshare.net/gzelfond/document-management-in-sharepoint-without-folders-introduction-to-metadata
Be careful to use the Microsoft documentation for the beginning. From my experience, its difficult to start with this documentation because you have several things in it. There is also good books/ebooks that you can find easily to start well, and probably more simplified than MS documentation.
I'm looking to use Redmine for document management. I know that Redmine is not ideal for this task but there is already a lot of content on the site so I'd like to utilize it if possible.
Redmine currently does not a have great documents module. The files we've uploaded look to be amended on that specific page and it doesn't seem to be able to move to another page (unless you download and re-upload to the proper page).
Idea 1
I see there is a Files section, which could work as a central repository (and you can upload document based on release) however, is there a way to set up a nice-looking 'front-end' page that automatically updates based on new submissions to the Files tab? I envision this front end to be a simple wiki page with the document name, a short description and a links to the file posted in the Files tab.
There are so many documents uploaded to varying pages on the Redmine site. I would only do the whole download and re-upload of files if there was a way to automatically update the 'front end' wiki.
Idea 2
I see there is a DMSF plugin for Redmine. Has anyone used this before and has is solved document management issues? I'd like to hear your feedback. Even if DMSF doesn't totally solve my issue, anything is better than what I have now.
Thanks!
In my opinion DMSF module is a perfect companion for Redmine. We have adopted it in our company. You can easily deal with document versions, webdav access, custom approval workflow, document modifications notification with the extra value of being well integrated with Redmine features (roles, dynamic links in Wiki and issue text and notes).
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.
Does anyone have any strategies/tips/traps for moving to Team System? Should it be done in baby steps, or all at once? Should we migrate our SourceSafe library over, or draw a line in the sand and move forward? Is it worth brining SharePoint into the mix? Any thoughts are appreciated.
I've never had to migrate to TFS, but have used it pretty extensively for the past couple of years.
Regarding your question on Sharepoint, we've found it pretty useful in conjunction with TFS. We use it primarily for documentation management and for storing other "non-technical" artifacts related to the project. Some dev teams advocate keeping documentation in source control alongside source code, which is OK, but in my experience our project stakeholders have an easier time accessing relevent project documentation via the Sharepoint portal than they would having to interface with source control.
I basically was able to distribute the URL to the sharepoint site associated with our TFS team project to the concerned non-technical team members and have been able to avoid constantly e-mailing documents around, so it's been great for us.
It may just be too much work to do it all at once.
I feel that it is easier to divvy out projects to different people one at a time.
That way they can move them across and ensure that each works okay before closing out the SourceSafe.
You will always want a backup of the SourceSafe "database" around just in case.
I do not know how to migrate from SourceSafe to TFS and keep the comments and versions.
By far the easiest it to just add the projects in, but having migrated that way in the past, we always missed the ability to find out what others had done to particular files.
If you find a way to migrate, I would go that way unless it is hideously expensive.
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.