Eric,
DMX is 'portal-wide' by design. There are no real solid work-arounds. You would really need to make a lot of changes to the code of the module to make it reliably 'module-specific'. From my perspective you're better off splitting the divisions into their own portals.
Peter

For what its worth, I'd love this option to Peter (see my recommendations document from last year, involving the creation of a new table 'tblRepositories') It would also allow us to segregate searches which is a huge hope of ours for future versions

Yes, creating sub-portals is an option but adds a far greater administrative head-ache, and this would force users to navigate to different portals simply for the the task of obtaining documents in this fashion, whereas they don't need to do it for most other modules (mind you, DMX is no ordinary module!!)

Cheers,
Andrew

We have not used the categories to great extent, so I may not be qualified to comment on this issue, but our upcoming addition of our UK users to our US intranet will be in the form of a sub-portal. Users will have 2 separate instances of DMX where all categories, collections and documents will be separated. Each sub-portal will have any ever-present link to the other in the upper left corner of the screen so browsing UK documents on the US portal will be just a click away.

This provides some other benefits such as setting default language for the UK users (so their dates will be displayed 'correctly') and the ability to move their entire site to a UK-based server if there ever comes a need.

Personally, I like the DMX approach where the module is 'portal-wide' by design. It's been my experience that trying to teach prospective DNN admins how to use modules where data is tied to each instance of the module is a headache.

Mike

I agree, Mike - having a 'portal-wide' DMX library is preferred.

But, collections can be relegated on a module-by-module basis, and I wish that categories had that same capability - to be able to restrict categories to a particular collection, or at least, to be able to dictate which categories appear in a particular instance of DMX.

I don't know if it's a good solution yet, but as a workaround, I switched from using several categories, to making sub-collections instead.

One option would be to use sub-categories. So the categories could be...

Bus unit #1
- Cat 1
- Cat 2
- Cat 3

Bus unit #2
- Cat 1
- Cat 2

...and so on

Although users would have the ability to browse other categories, they would at least be steered in the right direction.

Mike

This is quite an interesting thread as it develops. As I'm trying to understand each point of view I'm trying to see if all of these wishes could be coherently put into a single solution. I do not want to abandon the 'portal wide' design. I'm fully with Mike in that it I find it at times 'counter-intuative' that modules have their data attached to their module instance, and not the portal in which they reside. I've tried to help people gain some flexibility by providing alternative 'starting points' for their DMX instance, but I grant it is a partial solution for separation. By design it is processor intensive to navigate up/down the document tree. This means that cross-referencing stuff to location in the document tree (e.g. search in a particular collection/subcollections, catagories by collection) would take too long to realistically implement. This is embedded in the very core of the design of this module. As much as I'd like to cater to all different demands, I have to warn that Eric's wish will probably never be satisfactorily met in any future version.

Peter

Thanks for chiming in Peter. I am new to some of the nuances of DMX in certain circumstances, so must admit I might be seeing the forest to spite the trees (or whatever).

With 4 'DMX Libraries' being built on a portal, it quickly became clear that categories weren't the way to go since they were "portal wide" in implementation. I had experimented with, and abandoned, sub-categories because it seemed like there was a better option available through collections and sub-collections. It just seems (so far anyway) like they are more sandboxed.

Of course, I haven't seen what the pitfall of this approach is yet. Please offer up any gotcha's that come to mind!

Amending queries in the What's New or Shortlist addons get me display results that I want, so things are looking good there.

Maybe a down-side of collections versus categories is that a single doc can be in multiple categories, yet can't in the same way be in multiple collections? At least I think that's true.

What it so far comes down to for this situation where categories don't entirely fit the bill, is that it would be helpful to be able to restrict what particular categories display in a particular instance of a DMX module. It would then enable the use of sub-categories successfully.

Eric,
You're getting the picture. Catagories are meant to cross reference stuff in DMX. Collections are meant to organize it. It is essential that a document belong to only one collection as you need one unifying structure that people can relate to. You can use this to sandox as well, as you've noted. There is only one pitfall I can think if: remember that a search returns from all documents, not just the ones in your current 'sandboxed' part. But the latter can be aleviated a little (if it is a problem) by having a more rigid permission structure where the sandboxed parts have their own permission set and you specify that only admins can edit permissions on items.
Regarding your last comment/request: that's what I referred to in my previous post as being practically inachievable given the design.
Hope this helps,
Peter