Document protection - Best Practices

We have a small .NET development team here, 10 developers. We recently
started using SharePoint for our team site as a way to share links,
documents, event information, etc. All of this has been pretty open
without any real concerns for security, basically just a public storage
area.

Now we have set up a separate site for system documentation. For this
area, we do need some security. This site is basically just a shared
document area. At the top level, there is a folder for each project.
When you open a folder, there will be primarily Word documents
outlining the project requirements, etc. There may be other supporting
documents as well such as Visio diagrams, Excel worksheets, screen
shots, etc.

We want everyone to be able to view everything in the folders.
Everyone should be able to save their own copy locally as well. The
goal is that if anyone should be able to view system documentation.
However, we want to limit updates to the document owner/creator or a
system administrator. This sounds incredibly easy, but we seem to be
missing something. Any thoughts on how to best accomplish this?

Engelbert
Tue Aug 15 08:54:50 CDT 2006

You can't limit updates to a document creator. That's the problem.

You can only limit updates to all people who belong to a Site Group that has
update rights to the particular document library. That's usually more than
one person.

The site administrator has (default) rights to everything.

(Note: in some List types you can restrict certain rights to the creator but
not in a document library.)

Engelbert

"Will" <bkunneke@hotmail.com> wrote in message
news:1155647149.273744.98580@h48g2000cwc.googlegroups.com...
> We have a small .NET development team here, 10 developers. We recently
> started using SharePoint for our team site as a way to share links,
> documents, event information, etc. All of this has been pretty open
> without any real concerns for security, basically just a public storage
> area.
>
> Now we have set up a separate site for system documentation. For this
> area, we do need some security. This site is basically just a shared
> document area. At the top level, there is a folder for each project.
> When you open a folder, there will be primarily Word documents
> outlining the project requirements, etc. There may be other supporting
> documents as well such as Visio diagrams, Excel worksheets, screen
> shots, etc.
>
> We want everyone to be able to view everything in the folders.
> Everyone should be able to save their own copy locally as well. The
> goal is that if anyone should be able to view system documentation.
> However, we want to limit updates to the document owner/creator or a
> system administrator. This sounds incredibly easy, but we seem to be
> missing something. Any thoughts on how to best accomplish this?
>

Engelbert
Tue Aug 15 09:00:52 CDT 2006

P.S.1 I'm assuming as you posted here that your "SharePoint" is Windows
SharePoint Services (v2) and that "area" is just a word you are using.

P.S.2 The implementation of folders is not great. If you are not too far in
your WSS implementation look at using Views in your Doc Libs instead of
folders.

Engelbert

"Engelbert" <Engelbert@discussions.nospam.com> wrote in message
news:%23AYgpJHwGHA.4296@TK2MSFTNGP06.phx.gbl...
> You can't limit updates to a document creator. That's the problem.
>
> You can only limit updates to all people who belong to a Site Group that
> has update rights to the particular document library. That's usually more
> than one person.
>
> The site administrator has (default) rights to everything.
>
> (Note: in some List types you can restrict certain rights to the creator
> but not in a document library.)
>
> Engelbert
>
> "Will" <bkunneke@hotmail.com> wrote in message
> news:1155647149.273744.98580@h48g2000cwc.googlegroups.com...
>> We have a small .NET development team here, 10 developers. We recently
>> started using SharePoint for our team site as a way to share links,
>> documents, event information, etc. All of this has been pretty open
>> without any real concerns for security, basically just a public storage
>> area.
>>
>> Now we have set up a separate site for system documentation. For this
>> area, we do need some security. This site is basically just a shared
>> document area. At the top level, there is a folder for each project.
>> When you open a folder, there will be primarily Word documents
>> outlining the project requirements, etc. There may be other supporting
>> documents as well such as Visio diagrams, Excel worksheets, screen
>> shots, etc.
>>
>> We want everyone to be able to view everything in the folders.
>> Everyone should be able to save their own copy locally as well. The
>> goal is that if anyone should be able to view system documentation.
>> However, we want to limit updates to the document owner/creator or a
>> system administrator. This sounds incredibly easy, but we seem to be
>> missing something. Any thoughts on how to best accomplish this?
>>
>
>

Will
Tue Aug 15 09:51:10 CDT 2006

Thanks for the info.

> P.S.1 I'm assuming as you posted here that your "SharePoint" is Windows
> SharePoint Services (v2) and that "area" is just a word you are using.

Yes to both, forgive me, I'm a developer!

> P.S.2 The implementation of folders is not great. If you are not too far in
> your WSS implementation look at using Views in your Doc Libs instead of
> folders.

Not too far into it yet. Not sure how/why Views would any better.
Let's say there are about 50 systems we have documentation on. Lets
say there is an average of 3 documents per system. Lets also say that
the our standards call for a common naming convention for system
documentation eg, there should always be a file named Problem
Statement.Doc for each system. Given these constraints, we need some
way to organize the documents by each different system. If I create a
folder named Telephone Billing System and then put several documents
into that folder, I can easily identify all the documents that belong
to the Telephone Billing System. How would I use Views to accomplish
this?

Engelbert
Tue Aug 15 10:51:14 CDT 2006

Your common naming standard is the snag *if it is the file name* as there
can only be one file of the same name in each document library. Of course
you could have different document libraries but with only three files in
each that would be stupid.

Otherwise with only 3 documents per folder (and assuming different file
names) then different Views would be more logical as you could then (with
150 documents in all) have various views of the lot (in different sort
orders; or different columns or both) of them plus you could have a View per
set of three (rather a long list in the left hand column or you could even
have as well a view that grouped them per the equivalent of a folder (so the
group you wanted could be expended if needed). Plus views could allow you to
group document sets (Category=X and Category=Y and Category=Z) which might
be useful in some cases.

Does that help with the concept (I'm assuming an extra field Category which
is a Choice field listing the alternative names)

Engelbert

"Will" <bkunneke@hotmail.com> wrote in message
news:1155653469.976749.286260@m79g2000cwm.googlegroups.com...
> Thanks for the info.
>
>> P.S.1 I'm assuming as you posted here that your "SharePoint" is Windows
>> SharePoint Services (v2) and that "area" is just a word you are using.
>
> Yes to both, forgive me, I'm a developer!
>
>> P.S.2 The implementation of folders is not great. If you are not too far
>> in
>> your WSS implementation look at using Views in your Doc Libs instead of
>> folders.
>
> Not too far into it yet. Not sure how/why Views would any better.
> Let's say there are about 50 systems we have documentation on. Lets
> say there is an average of 3 documents per system. Lets also say that
> the our standards call for a common naming convention for system
> documentation eg, there should always be a file named Problem
> Statement.Doc for each system. Given these constraints, we need some
> way to organize the documents by each different system. If I create a
> folder named Telephone Billing System and then put several documents
> into that folder, I can easily identify all the documents that belong
> to the Telephone Billing System. How would I use Views to accomplish
> this?
>

CW
Tue Aug 15 11:29:20 CDT 2006

I agree with the implementation of views and categories, because once
into WSS it makes so much sense. One other important consideration
however, one that I learned from one of Jim Buyens' books, is that you
want to consider structuring everything with the limit of 1000
files/folder and 1000 folders/Doc Library in mind.

It sounds like a lot, but depending on the workplace, that could take a
matter of weeks to meet that limitation so knowing what your document
loading is likely to be will really help the structuring of the doc
lib.

Cheers all!!

CW

Engelbert wrote:
> Your common naming standard is the snag *if it is the file name* as there
> can only be one file of the same name in each document library. Of course
> you could have different document libraries but with only three files in
> each that would be stupid.
>
> Otherwise with only 3 documents per folder (and assuming different file
> names) then different Views would be more logical as you could then (with
> 150 documents in all) have various views of the lot (in different sort
> orders; or different columns or both) of them plus you could have a View per
> set of three (rather a long list in the left hand column or you could even
> have as well a view that grouped them per the equivalent of a folder (so the
> group you wanted could be expended if needed). Plus views could allow you to
> group document sets (Category=X and Category=Y and Category=Z) which might
> be useful in some cases.
>
> Does that help with the concept (I'm assuming an extra field Category which
> is a Choice field listing the alternative names)
>
> Engelbert
>
> "Will" <bkunneke@hotmail.com> wrote in message
> news:1155653469.976749.286260@m79g2000cwm.googlegroups.com...
> > Thanks for the info.
> >
> >> P.S.1 I'm assuming as you posted here that your "SharePoint" is Windows
> >> SharePoint Services (v2) and that "area" is just a word you are using.
> >
> > Yes to both, forgive me, I'm a developer!
> >
> >> P.S.2 The implementation of folders is not great. If you are not too far
> >> in
> >> your WSS implementation look at using Views in your Doc Libs instead of
> >> folders.
> >
> > Not too far into it yet. Not sure how/why Views would any better.
> > Let's say there are about 50 systems we have documentation on. Lets
> > say there is an average of 3 documents per system. Lets also say that
> > the our standards call for a common naming convention for system
> > documentation eg, there should always be a file named Problem
> > Statement.Doc for each system. Given these constraints, we need some
> > way to organize the documents by each different system. If I create a
> > folder named Telephone Billing System and then put several documents
> > into that folder, I can easily identify all the documents that belong
> > to the Telephone Billing System. How would I use Views to accomplish
> > this?
> >