We are testing DMX5 on DNN 5.6

I have made a folder "Sales" and set authentication to specific role (eg Sales)
in that folder i have some documents (with permission to all users)

When a user WITHOUT the role Sales navigates through the document tree this Sales folder does not appear (which is a good thing!)

Except, when that same user searches through all in repository the document within the sales folder are show in the search results (and can be viewed/downloaded)

This is not what i am expecting since those documents are in a folder with specific sales authentication.

Is my expectation wrong?

If so, does this mean that i have to set authentication on each file individually (in stead on a folder)?

Thanks,

Kind Regards

Rob Niessen

Hi Rob,

I can't replicate this. Permissions are checked for browsing, search and download. Either the user *does* have access to those documents *or* you've switched user but the DNN cookie remained intact and the system still sees you as the previous user. BTW, you say you're testing DMX 5 on DNN 5.6. I'd go for DMX 6 already.

Peter

Hi Peter,

let me rephrase my question/remark:

I have a FOLDER 'Quote' with access rights for role Sales.

Is there a way that new added FILES to the folder 'Quote', inherit the rights set to that folder?

Or do i need to set rights individually on every new added file?

Rob

additional info : using v6 (not 5 like mentioned before)

Hi Rob,

Permissions are inherited by default. When you add a document to a folder the permissions grid shows the permissions from the parent folder. If you don't change this, the permissions are just as the parent. This should also be true if you don't see the permissions grid. The permissions are copied over when the file is created. ADD permission of the folder is merged with the EDIT to become the EDIT permissions of the child.

Peter

I know I am replying to an old post, but we are having the same problem. The search function and also categories do not respect security access settings.

Example:

We have folder A that only users with security role X have been given permissions to.

We have folder B that only users with security role Y have been give permissions to.

When users with security role X go to Document Exchange, they do not see folder B.

However, if the same users with security role X put in search criteria or select a category that pertains to the documents in folder B, those documents are showing in their search -- even though they do not have rights to access that folder or anything in it.

This is a serious security problem and we don't know what to do. Please help.

Hi Kate,

A possibility is that you created the folders A and B and added documents to them to test before you set the more restrictive security roles on the individual folders.

If you select folder B, right click and edit attributes, go to permissions, you will see a check box that says "Unify permissions on children". Select this and click finish. This will force the correct permissions (i.e., the security roles with desired permissions at the folder level) to overwrite permissions on all content within the folder (the children objects).

At the top level main options of the module, you may also want to select "Permissions only by Admins" which will prevent non-admins from setting permissions on individual files.

Hope this helps.

Rob Ralston
SilverBullet Technologies LLC

Hi Rob, thanks for answering. I actually did consider that, and I checked the "Unify permissions on children checkbox" and selected Update. I also reran most of the scripts, including the rebuild permissions one. But the behavior has not changed.

One thing I DID notice, however: When I go back and look at the folder the box that I checked is now unchecked. Once I select it and update it should stay checked, right? Maybe that is the source of the problem somehow?

No, the checkbox does not stay checked after you apply it. It is used on an as needed basis since once everything is set and security roles are "unified" on the child objects, new entries automatically inherit the folder permissions, unless users are also allowed to edit permissions as they add items.

When you look at your permissions on the folder, make certain you select Filter by Group "All Roles" to make certain you are seeing all security roles in the portal. That might uncover something.

Other than that, I would look directly at the permissions on one of the files in Folder B that security role X should not have access to, yet is seeing via search or category. Also, report back what version of DMX and DNN you are using so Peter can try to make sense out of this if necessary.

We're using DocX (version 6.0.3) and installed it on DNN community version 6.01.05.

I double checked folder for All Roles. Only has permissions for Administrators and the correct group.

We're using DocX (version 6.0.3) and installed it on DNN community version 6.01.05.

I double checked folder for All Roles. Only has permissions for Administrators and the correct group.

@Kate: Rob's advice is the first to follow. Then, if the issue persists, you'll need to drill down and really analyze a single case. So find a hidden document, and note its entryid (click "Navigate to" and the entryid shows up in the browser url bar). Then, when logged in as admin you'll need to do the following: go to this document (verify it is the same entry id) and check the permission settings on it (click properties on the document). Now double check with the user's roles.

Did the user *ever* belong to one of the roles needed to see the hidden doc? I.e. could it be a temporal issue?

Peter

I wash I had a better answer for anybody else who is having this same problem.

I think the origin of the problem was, as Rob mentioned in his 29 June post, that:" A possibility is that you created the folders A and B and added documents to them to test before you set the more restrictive security roles on the individual folders."

The problem was that selecting Unify Permissions on Children didn't initially fix the problem. It was one of those things where over about a day and a half I checked it repeatedly and also re-ran a bunch of the scripts (like "rebuild permissions" etc.). Finally at some point it "took," but I don't know why, because as far as I know I was simply doing the same thing over and over. You might want to check this scenario out, Peter, and just make sure that selecting Unify Permissions on Children isn't failing in some situations.

OK, thanks. I'll look into it.

Peter