0

I don't know how to start this so I will try to explain situation:

Users: Programmers, managers, clients. Files: Various files not supported by Office, mostly code samples, manuals.

What do I need? I need a system in SharePoint which would let the users to "share" these files between each other. Programers upload these files, managers approves them, clients use them.

My solution: Task list, each "task" would define project, programmers attach files, managers approves them by checking status columns, files then are sent to client libraries.

Problems: SharePoint is quite limited and needs custom code. 1 problem. How do I categorise attachments' in tasks? Secondly, how do I display and upload them in tasks list by categories? Thirdly, how do I send them to clients' document libraries?

For third problemn workflows would be the best solution, however it's not Document library, so I can't extract attachments from task by category.

Why Document library won't work? Firstly, I would to create folder for each Project, then for each category. Moreover, you cant move folders in SharePoint, so I would build workflows for each folder. Also columns in each folder would be the same as in document library. Also, it's takes a lot of time to create folders each time.

I don't ask for code samples, all I need is to know is there any better solutions for this than using task list and is my way of thinking on the right way?

Thanks.

Improve this question
3
  • I think this needs some more details to get a reasonable response, although even then it will likely be somewhat opinion based: how many projects are you dealing with (It doesn't matter specifically, but order of magnitute: is it closer 100 or 100000)? How many (number)/how many MB/GB of files are we talking in each project? Is seperating file access from client1 vs client2 important? Do you have project managers that would be responsible for administering their files or is everything administered by you?
    – John-M
    Commented Jul 29, 2014 at 13:49
  • How many projects? Well, my team works for 10-30 companies(I'm not dealing with these companies, I was given just this task). Each company can have more than 1 project, so it's hard to say exact number. Well, cant realy tell the size of files, but each project doesn't need more than 10mb for sure. Yes, seperating files from client1 ir client2 is needed. In this case, I thought that each company would have document library, where done projects would be stored, ofcourse with approval status. What about administration.. I'm just like supervisor of projects. Programmers after work upload files...
    – user3529236
    Commented Jul 29, 2014 at 20:46
  • ...managers/consultants checks them and then some workflow maybe or the consultant itself uplaod the files to clients' library.
    – user3529236
    Commented Jul 29, 2014 at 20:47

3 Answers 3

Reset to default
1

It's hard to give a super concise answer to this without doing a more thorough analysis of your process -- but I would probably have one central site where documents are initially uploaded and approved, this area would be internal access only (no clients). I would have some specific identifier for every project you're working on, so that documents could be tagged with metadata for that project as they are created -- preferably an identifier you could use as a site URL -- because in order to control client access to only the right things, I would make a sub-site for at least every client, more likely one for every project.

Then, from your central site, as documents are published and approved you can have the project manager/programmers/consultants create copies of the documents down in to the client/project sub-sites. Do this using the 'copy to' feature in the ribbon from the original document location, then you can also prompt authors to publish changes to the copies when they make them in the central site -- an alternative, if you wanted to alleviate some work for people, would be to automate this process with a workflow or event receiver, but it's really not too much effort to create SP managed copies in sub-sites 'manually.'

This technique would allow you to easily control access to everything, because each client or project would be in its own sub-site. You can quite easily just delete a site when you're done with it, and because your original documents live in the central site you could then keep/archive in a records center/delete them as necessary. This also provides the benefit of allowing the same document to be copied and updated into multiple project folders if necessary.

One of your comments noted that the file uploaders would need to specify which project they are working on -- I think it's important to realize there is no way around this; you have to pick one way or another -- whether you use metadata fields, managed metadata, sites, or folders it all requires the same work to be done.

Improve this answer
0

With the info presented, I'm not sure I understand why you went with the 'Tasks' option. One possible scenario is to leverage the metadata potential of SP and just store all the files in a custom list with columns defining the project names, status etc. This allows you to categorize as well as add custom workflows. And you would not need folders at all.

Improve this answer
2
  • If clients are accessing these directly the folders would be required for permissions purposes likely.
    – Aboba
    Commented Jul 29, 2014 at 18:54
  • Well, clients would have their own list, where the files would be stored. But I see one problem, which is review of those projects. Tasks and folders let to store files in one row for certain project. If I would upload files like this method, it would be a long list with pages even, also the uploader would need to set project name. Also, what I didn't mention, that those files could have changes/updates, so managing them like a group(folder, task) is a easier way I think.
    – user3529236
    Commented Jul 29, 2014 at 20:57
0

It looks like you are looking for a kind of Github/Sharepoint Integration https://zapier.com/zapbook/github/sharepoint/

the only reason I might see that it wouldn't be a best practice to use a 'document library' as a code repository is because the metadata of folders can affect documents inside the folder. I'm not completely familiar with all of the ins-and-outs on this but it is something to be aware of: http://social.technet.microsoft.com/wiki/contents/articles/16166.sharepoint-2013-using-folders.aspx

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.