TOC should reflect user security profiles

[Bill Legge]

I guess this comes under the heading of single-sourcing...
We produce help for a product which has dynamic security setting functionality. Different clients for our product set different security profile combinations according to how they functionally organise their business. Since we have handed over this capability to our clients, it means they can change security setting combinations whenever they like, (and some of them like to do it frequently). Currently, when a user invokes the help, they can see the entire volume, including topics relating to areas of the system they can't access. Superfluous and irrelevant content is not good help. I am looking for an approach that doesn't involve having to maintain multiple targets, which enables our help to respond automatically to a user's security profile, so the TOC only shows topics relevant to their system access

[NorthEast]

There's nothing built-in to Flare that supports this. So you can't build one output, and then have multiple different conditional "views" of that output that allow you to show/hide certain topics.

You can handle it manually to a limited extent. In one of my projects, I tag content in a topic for different user types, and then use CSS to show/hide that content based on the user type (the user type is sent to the help as a parameter).

However, as Flare doesn't fundamentally support showing/hiding content, it's not easy to conditionally show/hide a topic altogether - i.e. control it appearing in search results, navigation (TOC), menu proxies, mini-TOCs, concept proxies, etc.

[devjoe]

If you are setting the security profile by actually changing Windows permissions, then it may be possible to hide/show content by applying those same permissions within the help, assuming the help exists as files locally installed on the user's machine. CHM and server-based HTML5 allow dynamic, run-time merging of projects, but the server-based solution isn't likely to work (the server isn't going to see the files in the context of the user who is browsing the web site). So I think only CHM will work. If the files are set up to be readable only to users with appropriate permissions, then the help should only include those sections they have access to. One caveat: CHM uses a search index which is built when you first open the help; if the user cannot write in the help installation folder, then this index is created inside the user's profile and is per-user. If the user's permissions change after this is set up, the search index needs to be rebuilt to avoid showing him topics he can no longer access or to show him stuff that he can now access.

If the security profile is just roles assigned to accounts within your application, then this isn't really going to work.

[Bill Legge]

Thanks both for your advice. I can see I will need to take this issue back to our Java devs who built the security components.

[NorthEast]

Using run time merging means that you're using mutiple targets though - Bill wanted an approach that didn't involve multiple targets.

But if you're happy using multiple targets, then that's a different scenario and a different answer.