Jim,
This is by design. If content should not be visible to some users, you have to use the permissions. If the three different folders are for different groups of people then assign them roles and set visibility of the content of these folders accordingly. You can even 'lock' the permissions so that users adding/editing content cannot change them (this is a setting of the module).
Peter

Thanks for the info Peter.  Where can I set the permissions for each individual folder?  I see where I can go into Settings and change the permissions there but when i restrict lets say the accounting forms to only accounting people and then logoff, i can still do a search and these forms still come up...is there a different spot where these permissions are located?

Thanks!

Permissions are handled on the input form of an item. There is a checkbox list of view and edit permissions.
Peter

Jim, did the permissions thing solve your problem? We also have the same need but permissions won't work since we want it based on the section you're on in the site and not the user. This is a real sticking point as the client is demanding it. I'm looking into creating my own module to try and link to the dmx library and filter the data myself but not sure if this is possible yet. Has anyone tried to link to DMX with their own module to do any customization? I am assuming that the search results come back into a datable and if I could just get at that I could filter it by category or folder in a dataview.

I'm not sure you're on the same page as the DMX designer (me, that is). The admin's manual has some stuff outlining the permissions design of DMX and I'll try to explain this model below:

1. EVERY DMX entry (whether a collection, a hyperlink, or a file) has its own set of permissions: view and edit. Someone with edit permissions on a collection is allowed to add content to that collection. Approval is set portal wide under the module's options panel.

2. DMX behaves like a file drive in some respects: the collections (and their content) are a single tree. By default permissions are inherited from the parent, but during an edit/create operation you can specify other permissions. There is an 'absolute root' which is not in the database. This is the virtual record with EntryId=0. Because this does not exist it is defined in the module as being a collection with the permissions you gave to the module (for view and edit).

3. Different instances of DMX throughout a SINGLE portal all refer to the same document tree. They are just 'windows' into this content. You can specify these windows to start at different places in the document tree, thus creating 'virtual drives' if you like. On every instance, the permissions are that of the root of that instance. If, for instance, you decide to paste a DMX somewhere that starts with collection 'Finance' then the permissions for the 'Finance' collection decide what icons show up when you first look at that page (i.e. not the module settings). Note that view settings in the module settings always override everything else because it potentially hides the whole module from view.

4. As a feature you can specify that only admins can adjust permissions. As mentioned before content inherits permissions from the parent. If you opt to only allow admins to specify permissions, the admin can make a collection tree to match the organization and set permissions. Logically you would then create DMX instances on pages for the different departments that start at the different levels.

5. Search is portal-wide. If you search for content, all content is returned that satisfies the criteria and that you have permission to see.

Final note: If you want to hide content from a group of users, use security roles to deliniate permissions. To refer to the last post of Jim: there is no way you log out and find content only meant for accounting if you specified a role 'accounting' and specified that the content should only be visible to this role. Make sure you design your DNN/DMX layout well and you should have no problem achieving what you want.

Peter

I think we are on the same page. The issue is that this is not a permissions issue. The client wants the users to get search results of documents only in the current folder they're currently viewing. The user will have permission for all folders. So if the user is in the root folder then yes the results should include everything but if they're in the Policies folder it should only search that folder. I am not pretending to know how it's coded. I just had the assumption that within the results coming back might be the folder that the document is in and that might give me a way to filter out all non-current folder matches.

On the search results page, the last collumn is "Collection". Since the results are displaying the "Collection" that each document belongs too it seems like it would be pretty easy to filter out any that aren't a member of the current collection being viewed, even if nothing more than looping thru the results returned and removing them.

I recall I suggested this last year, and it seems to come up quite often here. It really is a usefuly feature -> users simply don't always want to search an entire site, and its a common requirement to segregate content based on a staff/role in a single site, without having to create multiple websites.

Peter, do you think this functionality will be included in the next version? I believe the document I provided last year with these suggesting included a proposal which would allow this functionality..

Cheers,
Andrew

Certainly the search facility is going to be turned upside down and inside out to check for loose screws and anything that needs adjusting. This is definitely on the roll to implement. The 'single collection search' as Dan mentions is not that hard to implement, indeed. It is the recursive one that needs to be worked out. The danger is an IIS timeout if the document tree gets too large. We need to find the best solution that will scale well.
Peter

You can always hire me (contact me by email for this). As I'm currently freezing DMX 3 to prepare for a major upgrade it's not a good idea to introduce this into the code. The risk of an intermediate release is that new bugs are introduced (putting pressure on support and forcing new updates etc) and we would be stuck on DMX 3 for ever. I'd like to progress to DMX 4 so all enhancement requests are going on to a big heap right now.

Peter

Sorry Dan, it slipped by me. My bad. I'll reply now.