<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Understanding WorkSite security part 2</title>
	<atom:link href="http://www.jasonplant.co.uk/2009/03/understanding-worksite-security-part-2/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.jasonplant.co.uk/2009/03/understanding-worksite-security-part-2/</link>
	<description>A law blog written by someone from IT or an IT blog written by someone who works for a law firm</description>
	<lastBuildDate>Wed, 18 Jan 2012 13:34:04 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
	<item>
		<title>By: Eileen</title>
		<link>http://www.jasonplant.co.uk/2009/03/understanding-worksite-security-part-2/comment-page-1/#comment-7844</link>
		<dc:creator>Eileen</dc:creator>
		<pubDate>Tue, 01 Jun 2010 14:28:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.jasonplant.co.uk/?p=180#comment-7844</guid>
		<description>Thanks Jason.  This is great.

I have a couple of questions... 
1) When you set the &quot;Shared as&quot; = View, can other read the view-only version, but save a new version? Or would they only have the option to save a new document?  

2) With the View access, could anyone then relate the two documents?  Or would you require Public or ACL=Full Access for that?

Thanks!</description>
		<content:encoded><![CDATA[<p>Thanks Jason.  This is great.</p>
<p>I have a couple of questions&#8230;<br />
1) When you set the &#8220;Shared as&#8221; = View, can other read the view-only version, but save a new version? Or would they only have the option to save a new document?  </p>
<p>2) With the View access, could anyone then relate the two documents?  Or would you require Public or ACL=Full Access for that?</p>
<p>Thanks!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David Kiefer</title>
		<link>http://www.jasonplant.co.uk/2009/03/understanding-worksite-security-part-2/comment-page-1/#comment-351</link>
		<dc:creator>David Kiefer</dc:creator>
		<pubDate>Tue, 24 Mar 2009 15:13:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.jasonplant.co.uk/?p=180#comment-351</guid>
		<description>This is an excellent overview of WorkSite security and some of the issues related to it.  Some other items you may want to discuss in additional articles:

1. What about security (and metadata) on documents that are in multiple locations?  Whichever folder or WorkSpace that is refiled last will set the &quot;winning&quot; values, which may not be correct.

2. Client-side or desktop refiling is certainly inefficient (every document is touched and changed, even if no changes are actually performed) and can be inherently dangerous (users with adequate security rights can damage the security and metadata of potentially many documents if they are not careful which options they choose in the refiling process, or they make changes but select &quot;No&quot; on the refiling dialog and not actually implement the changes).  Users who refile a WorkSpace and tie up their machine for several minutes may decide not to do that again in the future...

3. No history events are added to documents during the native refiling process, so refiling causes untracked changes to document profiles.

Our Refiling Server products address all of these issues, and many more, such as providing control over which metadata values can be changed as part of the refiling process, how documents in multiple locations are handled, and providing history logging of changes.  They completely eliminate all client- or user-side refiling, and allow for much faster and efficient server-side refiling.

Also, what are the implications of user ACLs on structures in terms of what abilities they have to create or modify structures within WorkSpaces?  Again, the Zone Control functionality of our WorkSpace Manager product allows control over which users or groups can create ad hoc structures, completely independent of their security rights.</description>
		<content:encoded><![CDATA[<p>This is an excellent overview of WorkSite security and some of the issues related to it.  Some other items you may want to discuss in additional articles:</p>
<p>1. What about security (and metadata) on documents that are in multiple locations?  Whichever folder or WorkSpace that is refiled last will set the &#8220;winning&#8221; values, which may not be correct.</p>
<p>2. Client-side or desktop refiling is certainly inefficient (every document is touched and changed, even if no changes are actually performed) and can be inherently dangerous (users with adequate security rights can damage the security and metadata of potentially many documents if they are not careful which options they choose in the refiling process, or they make changes but select &#8220;No&#8221; on the refiling dialog and not actually implement the changes).  Users who refile a WorkSpace and tie up their machine for several minutes may decide not to do that again in the future&#8230;</p>
<p>3. No history events are added to documents during the native refiling process, so refiling causes untracked changes to document profiles.</p>
<p>Our Refiling Server products address all of these issues, and many more, such as providing control over which metadata values can be changed as part of the refiling process, how documents in multiple locations are handled, and providing history logging of changes.  They completely eliminate all client- or user-side refiling, and allow for much faster and efficient server-side refiling.</p>
<p>Also, what are the implications of user ACLs on structures in terms of what abilities they have to create or modify structures within WorkSpaces?  Again, the Zone Control functionality of our WorkSpace Manager product allows control over which users or groups can create ad hoc structures, completely independent of their security rights.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

