11 replies to this topic

[hellenb]

Hi,

I am having a problem with the documentgroups. This is the situation. I have a website for a preliminary school in which each class has one or more documents which they can manage. A class can have on or two teachers who both work parttime. Every teacher has only access to the documents of his/her class.

I have a userrole called 'editor' which has the settings :

- etomite manager
- change/save password
- show/change/save documentdata
- clear cache

Then I have a few users (which are teachers of a school) they have all been assigned to this role.

Next I have a few usergroups :
- groep 1
- groep 2
- groep 3
- groep 45
etc.
Each usergroup contains one or more teachers (

I have documentgroups:
- documenten groep 1
- documenten groep 2
- documenten groep 3
etc
These documentgroups each contain one or more documents belonging to the classes.
A document can only belong to 1 documentgroup.

The usergroups are linked to the documentgroups very simple.
groep 1 --> documenten groep 2
groep 2 --> documenten groep 2
etc

The problem is this. When a teacher is logged and changes on of hiss/her documents and saves it, then this document is automatically added to all of the other documentgroups. Which results in the fact that other teachers are also able to change that document, which ofcourse is not allowed.

Example
usergroup:
groep 1 (users: john, eric)
groep 2 (users: Carly)

documentgroups:
documenten groep 1 (documents: 113, 115)
documenten groep 2 (documents: 117, 121)

User-documentgroup link:
groep 1 --> documenten groep 1
groep 2 --> documenten groep 2

John logges in and changes document 113 and saves it. After saving it this is how the documentgroups is:
documentgroups:
documenten groep 1 (documents: 113, 115)
documenten groep 2 (documents: 113, 117, 121)

Carly will now also be able to change document 113, which is not allowed.
what I am doing wrong?

[Cris D.]

Is the permissions checkboxes avaliable to the document group user in the edited document "permissions" tab?
Are they unchecked before saving and checked after saving eve though they are not being checked by the user?

[hellenb]

Is the permissions checkboxes avaliable to the document group user in the edited document "permissions" tab?
Are they unchecked before saving and checked after saving eve though they are not being checked by the user?

This is what happens:
- if i uncheck the "access permission" in the permission managent in the user role, then when a user edit a document (he cant see the permissions tab) and saves it, then the document is added to all the other documentgroups and yes the permissionboxes for all the other documentgroups are checked after saving.

- If i check the "access permission" in the permission managent in the userrole, then when the user edits and saves a document (he can now also see the permissionstab), the document will only be in his documentgroups. It is not added (the checkboxex are unchecked) to all the other documentgroups.

Ofcourse I do not want the users to have access to the permission management.

[Cris D.]

Sounds like a bug to me

[Ralph]

Not a bug... Merely a deficiency in the current user/document/group permissions capabilities... Hence the need for a rewrite of the code base to account for more flexible and extensible permissions management...

[hellenb]

Not a bug... Merely a deficiency in the current user/document/group permissions capabilities... Hence the need for a rewrite of the code base to account for more flexible and extensible permissions management...

So,... in the mean time, what can I do, is there some solution, maybe another way to make sure that one person cannot edit the other person's document?

[Ralph]

So,... in the mean time, what can I do, is there some solution, maybe another way to make sure that one person cannot edit the other person's document?

Currently, I don't think so... Here's the issue in the plainest terms I can muster at the moment... The whole user and roles concept isn't conducive to a hierarchical permissions tree... By that I mean that you cannot assign one user to be the subordinate of another user so nobody is in control of anyone else... Each individual either has rights or they don't... Document rights cannot be assigned by specific user/documents by the system itself, nor can they be assigned to a parent folder document basis...

The only way I can think of, with the current code base, would be to assign a separate document group for each user... That might work... I honestly don't use permissions enough to be an expert on them but I know I have always seen room for improvements in the current code base... Unfortunately, so many changes would be required that it's easier to just rewrite the whole application... The same can be said for several other features that many of us would like to see implemented...

[hellenb]

Currently, I don't think so... Here's the issue in the plainest terms I can muster at the moment... The whole user and roles concept isn't conducive to a hierarchical permissions tree... By that I mean that you cannot assign one user to be the subordinate of another user so nobody is in control of anyone else... Each individual either has rights or they don't... Document rights cannot be assigned by specific user/documents by the system itself, nor can they be assigned to a parent folder document basis...

The only way I can think of, with the current code base, would be to assign a separate document group for each user... That might work... I honestly don't use permissions enough to be an expert on them but I know I have always seen room for improvements in the current code base... Unfortunately, so many changes would be required that it's easier to just rewrite the whole application... The same can be said for several other features that many of us would like to see implemented...

I don't think i understand your point in the first alinea. The structur that I am using i rather straight forward, no cross authorizations etc. I agree with Chris that it is probably a bug, because everything works fine if the user has "access permission" in the permission managent.
so maybe you can point out where this part of code is programmed, maybe I can take a look and make some ad-hoc solution?

[Ralph]

I guess I'm getting confused here... If access permissions are disabled in the Etomite configuration panel then the system pay no attention to permissions regardless of what document user groups you have established... They only come into play when the checkbox is checked...

Now, I've done some testing and I can see where there might be a problem... And, again, I think this is due to the lack of hierachical permissions... If I enable Permissions management within the users role then I have access to the permissions tab... The permissions setting cannot be automatically set based on the user because of how document groups work along with the user role... While I can imagine how it should work, making it happen in the current code base would be a major task, as previously mentioned...

Here's the crux of the matter... When permissions were added into the code base, as they weren't there in the initial release, the implementation was limited and has never been improved due to the overall layout of the code base... Any deficiencies will have to wait and be addressed in the next major release as development on the Prelude code base is coming to an end so that we can concentrate on newer and better code for everyone... We also won't be making efforts to hand-hold anyone who decides to attempt to figure out a way to make things work as we have better things to do with our time... If modifying the permissions management was easy it would have been done by now...

[hellenb]

Hi Ralph,

I think there is still some misunderstanding of my problem. Let me put it this way in a simple example.
e.g.

I have 2 users and a website existing of 4 documents (1,2,3 and 4). I want user 1 to be able to edit and save documents 1 and 2.
User 2 should maintain documents 3 and 4. They are not allowed to edit each others document.

What should I do to make this work. This is a rather simple example which I think must be possible in etomite. This is the most simple form of access rights. Still I can't make this work .

This is my solution:

Accessrights in the configuration is checked.

usergroup 1 (user 1) ==> linked to documentgroup 1 (documents 1, 2)
usergroup 2 (user 2) ==> linked to documentgroup 2 (documents 3, 4)

Userrole for both users only contains: access to etomite manager, edit documents, save document.

At first user 1 has no access rights to documents 3,4 and user 2 has no rights to documents 1,2. Which is great!
But as soon as user 1 saves one of his documents, user 2 gets access to that document (or viceversa).

Why do i think this is a bug? Because when I check this option (permission management: ACCESS PERMISSION) in the userrole, then the whole thing works fine!

[Cris D.]

I have also had a play with this and it seems that the "problem" is that every time a user with a role where they are allowed to save a document, on saving, the document is added to every document group UNLESS the "access permissions" box in the role is checked. That means to successfully save the document from group1 and NOT have it available in group2, you NEED to have the "access permissions" box checked. The unfortunate side effect of this is that now you have granted access to your user to edit and delete user groups, document groups and document/group links.

Ideally, the "permissions" tab on the document would return something other than "on" when user permissions were not allowed.

This is my findings:

The default value for the document_groups table is 0.

The
save_content.processor.php file looks for the $_POST['document_groups']...

Source code for role:Access Permissions= ON

<!-- <div class="tab-page" id="tabPage4"> -->
<div class="tab-page" id="tabPage4" >
  <div class="tab">
	<img src='./media/images/misc/dot.gif' alt="." />&nbsp;Permissions  </div>
  <script type="text/javascript">
	tpSettings.addTabPage(document.getElementById("tabPage4"));
  </script>

  <div class="sectionBody">
	<p class="menuHeader">Here you can select which document groups this document belongs to</p>

	<br />

		<input type="checkbox" name="document_groups['1']" >author homes<br />
	<input type="checkbox" name="document_groups['3']" >tset<br />
	<input type="checkbox" name="document_groups['4']" >group1docs<br />
	<input type="checkbox" name="document_groups['5']" >group2docs<br />
	</div>

Source code for : Access Permissions =OFF

<!--tabPage4-->
	<input type="hidden" name="document_groups['1']" value="on">
	<input type="hidden" name="document_groups['3']" value="on">

	<input type="hidden" name="document_groups['4']" value="on">
	<input type="hidden" name="document_groups['5']" value="on">
	</div>
  
  <input type="submit" name="save" style="display:none">
  </form>

</div> <!--tabPage4-->

if $use_udperms ==1, saves the document to the document group if the $_POST['document_groups'] value is "on".

$document_groups = $_POST['document_groups'];

 // put the document in the document_groups it should be in
		// first, check that up_perms are switched on!
		if($use_udperms==1) {
		  if(is_array($document_groups)) {
			foreach ($document_groups as $dgkey=>$value) {
			  if($value=="on") {
				$sql = "INSERT INTO $dbase.".$table_prefix."document_groups(document_group, document) values(".stripslashes($dgkey).", $key)";
				$rs = mysql_query($sql);
				if(!$rs){
				  echo "An error occured while attempting to add the document to a document_group.";
				  exit;
				}
			  }
			}
		  }
		}

Therefore, the following will stop the document from being saved in all groups:

Change the default hidden form fields to 'NULL' (except the existing document group). (I couldn't find where this was being generated).

Assuming "$use_udperms" means 'user_document permissions' then it is being incorrectly set to 1 when the "access permissions" is unchecked. (I couldn't find where this was being generated either).

[Ralph]

Like Cris pointed out, if access permissions are disabled then any documents created during such time will not have any accurate document group permissions handling enabled, even if access permissions were enabled previously or will be in the future... Additionally, there is no default document group which can be assigned, which I pointed out in an earlier post - the whole reason I stated that this is the major issue with permissions in the current code base... A user does not have default document group permissions, only a default role... A user gets assigned to document groups on an as-needed basis with no group being a users default as a default simply doesn't exist...

I do truly understand the problem, it is everyone else that doesn't understand the WHY... When access permissions are enabled, there are no document groups - they must be created... The whole process must be done manually... You can have dozens of document groups and user groups, but they still need to be created and linked manually... And only after that can a document be assigned to a document group which is controlled by a user group... If there is not link then there still isn't any accurate permissions handling... This is the problem... Documents aren't required to be linked to permissions, it is an option...

There is little need in continuing to beat this into the ground... There are diagrams in the documentation that clearly map out, well as clearly as possible, how Alex originally implemented permissions... And let me be the first to say that there is a whole lot of room for improvement... Unfortunately, as I keep trying to say, the current code base is not going to be modified to make permissions work properly due to how they were originally tied into the code base... You have what you have until we can rewrite the code base to properly handle permissions as opposed to adding them in after the fact as they were in the current release... Until then a simple "stay the hell out of other peoples documents" should suffice... And if not then you have someone in the manager that shouldn't be there to begin with...

EDIT:
Ok, I just had a chat with Dean and now he understands the WHY... If anyone else really needs to know more about this they will need to IM me via Yahoo, MSN, or ICQ so I can do it one-on-one as I can do it that way far easier than going on and on here...