Choccie is right -- the most straightforward and secure method would, I think, be to deliver separate outputs. Security management, the idea of serving different content based on a user, is really the job of the server, I think.
That said, when you add condition tags to content, as long as that content isn't excluded at output, those tags stay in the HTML:
conditionaltags.png
So, arguably, using JavaScript or jQuery, you
could fool around with eliminating content based on roles, though it wouldn't be truly secure -- the content in the topics would always exist for a time where it could be captured before the script would process out the content. That said, if you were comfortable with that level of security, I'd probably implement this in a basic way by:
1. Applying the appropriate condition tags to all elements that require them.
2. Include on the Master Page(s) some JavaScript (more on that below).
3. Build the project output with none of the appropriate condition tags excluded (i.e., you'd want all of the content for managers, for associates, etc, all available in the project).
4. Publish the output.
This hinges on the JavaScript in Step 2. And caveats, this is just a white-paper sort of implementation, and I'm certain there are individuals more skilled with JavaScript and other languages who would have way better approaches. So! That said...
I would probably do one of the following methods, to start:
a. Talk to whoever manages the server and its security about web storage. Most modern browsers allow you to store data in localStorage and sessionStorage. In this case, you would likely want the role of the user (i.e. manager, associate) to be stored in localStorage. If this was viable, the JavaScript in Step 2 should read the role of the user from localStorage, and exclude the content in the topics that is not pertinent to them before actually displaying the page to the user. At the end of the user's session, you'd probably want to clear the localStorage of that item.
b. Talk to whoever manages the server and its security about cookies. A cookie should be created that identifies the security role of the user. If this was viable, the JavaScript in Step 2 should read the cookie, determine the user, and exclude the content in the topics that is not pertinent to them before actually displaying the page to the user. A problem with this implementation is if the user has their browser configured to block cookies, in which case there would need to be a contingency step so the user didn't just get a mashup of all content.
c. Talk to whoever manages the server about the URL to the help system. Using the server configuration, they should be able to either create unique URL paths to the help system based on the user's role (i.e., a manager might access the help system via
.../manager/helpsystem.htm, whereas an associate might have
.../associate/helpsystem.htm), or append a query string to the end of the URL -- something like
?user=manager. In this case, the JavaScript in Step 2 should parse the URL when the page loads, extract the the role of the user from the URL, and exclude the content in the topics that is not pertinent to them before actually displaying the page to the user. This might also cause some issues with how MadCap's search works for HTML output.
In all three cases, again, this isn't
secure, just a way to control how data is being
displayed. It would be trivial for a user to stop the JavaScript from executing before the content was excluded, and extract the HTML from the page, even if it wasn't visible in the browser window.
If security is a primary concern, the best is multiple outputs, which can be served only to the users who have the proper credentials.
Some light reading on all this stuff:
http://www.w3schools.com/js/js_cookies.asp
http://stackoverflow.com/questions/2998 ... age-reload
https://en.wikipedia.org/wiki/Query_string