Community Support for OpenDocMan (Deprecated)

Full Version: Specific Department Permissions doesn't work
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
I would like to report a potential bug.
The Specific Department Permissions option when uploading a new file doesn't work in my hands.

1) I have created a department called "siau".
2) I have added three users to this department called reviewer (reviewer for siau) and normal user1 and user2, both also a member of the siau department.
3) If user1 uploads a file, I change "Specific Department Permissions" to "view" for the department of "siau".
4) After authorization by user "reviewer", user2 (who is also a member of the department) should be able to view the document.
However, this is not the case. user2 cannot view the uploaded document. If I want that user2 has the right to view the file, user1 has to check the specific permission when uploading the file.

I' would be grateful if someone could verify my observation.

Many thanks

I did further research on the demo site <!-- m --><a class="postlink" href=""></a><!-- m -->
to avoid reporting errors which might have something to do with my installation. Here my observation.
1) I can verify my observation I have reported in my previous post
2) Specific Department Permissions: setting to "view" for a specific department doesn't work. Other members can still not see the file (jsut listed)
3) Setting Specific Department Permissions to "read" will trigger "view ". Other members of the same department can now download the file. However, they cannot checkout the file
4) Setting Specific Department Permissions to "write" will trigger "view", "read" and "write". Now other members of the department can download (view) and checkout the file
5) The option "view" in "Specific User Permissions:" doesn't work (same like in "Specific Department Permissions"). I have to allow read or write in the "Specific User Permissions:", which also automatically trigger a "view".

I hope my observation makes sense

Ok, I will try to take a look at this.

I am using and it appears that I am having at least something similar. I am going to test other levels to see if they work by department. At present I only tried the "view" and "read" since they didn't have any rights to the doc.
I just attempted "admin" rights for the department settings and my low level user still unable to even view the file.
I believe this issue might be due to user error. Here are the steps you would take to adjust Department Permissions (It is not as clear as it should be and will soon be replaced with a new settings UI):

1) Create a new department "DeptA", and "DeptB"
2) Create new users "depta", "depta2", and "deptb"
3) As admin, edit a file
4) Click on the "Select a department" dropdown and choose "DeptA" then click on the "Read" radio button
5) Click Save
6) Logout
7) Login as "depta" user
8) You should see the file you had edited in "read" mode (So, you can view the file details but cannot download it)
9) Login as "deptb" user
10) You should not see the file
11) Repeat steps 4-10 but change the file to have "admin" permissions for "DeptA"

I just ran through this scenario and the user permissions worked as intended. There are lots of different things that could be happening but I think it may just be the user interface is a little confusing when it comes to department permissions. Each of the values in the "Select a department" dropdown are independent settings. You can click on each of those items and choose a different permission level for each.
Thank you Stephen.
Went through the steps you outlined exactly except I added a new doc to work with that I could delete later. The permissions seem to work OK.

So I then tried to use an existing document for the new user I created in the new department. That worked OK.

So then I tried to set permissions for the same existing document for an existing department and existing user. Not OK!! Still has no access to the doc. It is listed but the permissions are "-/-/-" after I assigned the department admin rights.

I then added the existing department to the new document I posted. The user in that department then had admin rights for the new file I had just posted. So that appears to be working correctly. But still no rights to the earlier file where admin had been granted.

So results are very inconsistent. I reviewed the database records. Listed below is odm_dept_perms please notice mulitple duplicate records.
The file I was working with was ID# 5 and department #2. The record below reports a value of 1. But when I go into the edit it reports none selected for that department. The doc is also assigned to the department as well. I changed it to admin and submit. It reports saved OK. I go back in and select the department again and it is still None. I review the database itself and it still reports 1 in the column, not 4 that I set. So it appears things work right by the numbers in the proper order of things. But when things altered in some way then other issues are presented. But it does appear to me the duplicate records should not be allowed here.

I am also wondering if assigned department perms are different than the values listed here all other departments. It may be the document was assigned to one department and then moved to another department that might cause some confussion as well. I will look in the database and see if there are permissions anywhere else. I am beginning to think if I delete the undesired records here it might start working correctly. Anyway difficult to debug a database you are not familiar with from the start.

Edit Delete 1 5 0
Edit Delete 1 7 0
Edit Delete 1 4 0
Edit Delete 1 5 0
Edit Delete 1 6 0
Edit Delete 1 5 0
Edit Delete 1 2 1
Edit Delete 3 5 0
Edit Delete 3 7 0
Edit Delete 3 6 0
Edit Delete 3 4 0
Edit Delete 3 5 0
Edit Delete 3 5 0
Edit Delete 3 2 1
Edit Delete 4 7 0
Edit Delete 4 6 0
Edit Delete 4 5 0
Edit Delete 4 4 0
Edit Delete 4 5 0
Edit Delete 4 2 1
Edit Delete 4 5 0
Edit Delete 5 6 4
Edit Delete 5 5 0
Edit Delete 5 7 0
Edit Delete 5 4 0
Edit Delete 5 2 1
Edit Delete 5 5 0
Edit Delete 5 5 0
Edit Delete 12 6 0
Edit Delete 12 2 1
Edit Delete 12 4 1
Edit Delete 12 5 0
Edit Delete 12 5 0
Edit Delete 12 7 0
Edit Delete 12 5 0
Edit Delete 13 5 0
Edit Delete 13 6 0
Edit Delete 13 2 0
Edit Delete 13 7 0
Edit Delete 13 4 1
Edit Delete 14 4 1
Edit Delete 14 6 0
Edit Delete 14 5 0
Edit Delete 14 2 0
Edit Delete 14 7 0
Edit Delete 15 5 0
Edit Delete 15 7 0
Edit Delete 15 6 0
Edit Delete 15 4 0
Edit Delete 15 2 1
Edit Delete 16 6 4
Edit Delete 16 7 0
Edit Delete 16 5 0
Edit Delete 16 2 4
Edit Delete 16 4 1
Having a terrible time to get anything to be consistent. I deleted ALL the department perm records not desired. I have only ONE dept perm record per file id set to admin for the department that owns the file. (So 7 files and 7 perm records) Had difficult time with phpmyadmin to even delete the dup entries. Had to edit the record first to something else then delete. But when I login now as a user of the department I get the right files with correct permissions. I certainly hope I do not have to go through this for all the files after they add them in the future!!!

So the user has admin rights and goes to the file and selects edit. The screen is displayed with the correct info. Under department permissions they select their own department and nothing is selected. The default perm is set to None and that displays correctly. Select another group and it shows None selected also however it is not set to that so why is showing anything at all. The department with admin rights doesn't even show up with anything. Select department named General and it reports it has admin rights! There are no records granting admin to that department anywhere. Now when I choose another department it reports admin when it didn't earlier! Go back to another department that changes it to none then select the department again it now it reports none instead of admin. The symptom here appears it is displaying whatever the last result was and not even the default permissions when there is nothing to alter it. Neither is the reporting the proper value of the perm record that does exists! Instead it wants to grant it to a different department.

I do not see how you state this behavoir as user error. It appears to me to be unstable and unreliable.
Tried posting a completely new file. Received three dept perm records. They were 1,0,0 levels. The test account was on the 1 level. The account could not view it or anything, just the item listing. When I set the perm to read at level 2 then the user could view and have read permisions. So level 1 is really not usable for any purpose except to let the user know the doc exists. Do not know why the other perm records were created. But when I went back into the edit settings the department selection behaved considerably more like it should when I selected different departments. So it looks like something in the database is causing the other erratic operations on different files.

Currently, I am using and the release is available and I have downloaded it. Considering upgrading since we are just starting out in this. Wondering if any changes in this area might make it more desireable. I can actually delete the whole installation and start over at this point without much headache and recreate the users and post the few docs back in there. I have all original docs but one myself. So it would be easily reloaded.


Update: I installed the release as a new install and completely reconfigured starting all over and posting the docs fresh. At present everything appears to be working great. I do not have any duplicate records and the edit selections appear to work properly. This time I did do all the overhead managment and setup for categories, departments, users, file types, etc. to start with since I knew what we needed. So everything was in place when posting the docs without going back and making modifications to the files afterward.

I suspect some issues might arise making mods to the docs that causes some confusion in the database earlier. These errors can be most difficult to reproduce and debug.

Thank you, James