Looking for advice... client wants different groups sandboxed to their
own section of the site (in site admin). They DON'T want the users to
see any other section of the site (even though the permission settings
won't allow edits in sections other than their own).
Is this for data security or just because they think it would be appropriate? There is little point hiding the content if they can ultimately see it online anyway. Also you remove the ability for users to be able to cross-link to related areas of the site outside of their branch, and preclude the use of file and image libraries.
When I've encountered this type of resistance in the past, generally asking the specific reasons for doing it normally shows up the silliness of the whole idea -- and it *is* silly.
I can hack the core index.cfm and set url.rootobjectID eq to the highest level node that they have appropriate permissions for, but ideally I'd want to have a policy Group field that holds a nav alias, identifying the default root node for the tree when users of that group log in. Is there any other desire for this functionality out there? (I saw a thread or two in the archives) The changes are not huge... pros/cons? I know one con is that once this default root is set, users of that group will not be able to modify sections of the site, at or above that level... but I can accept that.
The con of hacking the core is that you hacked the core! Your team will forever have to update your code base with the hacks every release, every patch, support is more difficult and so on. Do not hack the core -- hacking the core is bad.
Better to build your own admin tab with similar functionality -- who knows as an admin you may want to access all regions of the site, no? In fact, it may be better development ROI to simply run a separate FarCry instance for each department.
-- geoff http://www.daemon.com.au/
--- You are currently subscribed to farcry-dev as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]
MXDU2004 + Macromedia DevCon AsiaPac + Sydney, Australia http://www.mxdu.com/ + 24-25 February, 2004
