Securing Topics

[dwag]

Some of our software customers have asked whether it is possible to make it so that users whose authorizations are limited to particular screens and menus also are limited to the help content for those screens and menus only; therefore, if a user with access to screens A and B only clicks the Help icon for one of those screens, he'll be unable to navigate to help for screens C and D.

Sounds like a tall order, but I thought I'd ask you whether there's a way.

[LTinker68]

The only way I can think to do it is if the help is provided on a server and the server admin sets access rights on specific folders. That might be a bit of a pain to set up but you should talk to your IT guys to see how they'd like to do it. After all, if the help is on the server then the server admin is the final say of what pages can/can't be viewed and by whom.

However, it might be easier if you generate multiple targets and upload them to several folders, such as "MinAccess", "MediumAccess", and "FullAccess" or something like that. If UserA only has MinAccess, then his path to the help is to inside the MinAccess folder, and if he clicks on a topic that talks about ScreenC but only FullAccess users have rights to that page, then he'd instead see a screen that says something like "You do not have permission to view ScreenC". So your ScreenC topic would include text that said "You do not have permission to view ScreenC" that's tied to the MinAccess and MediumAccess conditions, and all other text in the topic would have the FullAccess condition applied.

If it's set up like that, then the permission levels are set at the top-most folder level instead of some permissions on FolderA and different permissions on FolderB and still different permissions on FolderC, etc.

Does that make sense?

[RamonS]

Surely, there are ways. I can come up with a few and I don't like any of them:
a) Create separate help outputs - that works OK if you can predict the scope for particular user roles and the number of roles is fairly small. If you have a system that allows add/edit/delete/view down to the field level you would have to create an insane amount of permutations of the output and maintenance would be something I'd put in the 'impossible' corner

b) Segment the help into individual help projects - chunking the current content isolates areas and won't even give any easy chance of access to those sections that are off-limits. The problem is that you get a detached array of small help pieces that do not have a common ToC, do not allow for searching and indexing across the allowed sections, and linking across chunks is also not really an option

c) Dumb down the help system - limit the ToC to common topics, do not allow searches, limit the index to common topics, and don't link from topics to other topics that could be not allowed to be viewed for a user

d) Enter software development - you could generate a bunch of pages that contain dynamic content that is changed programmatically based on the current access rights. This would compile a ToC, Index and full text search on the fly as well as enable or disable hyperlinks across topics. Basically, you need to replicate the security model of the application in your help system using code.

e) Build help into the application - rather than having an external help system, add help sections to each form displayed on screen. If one doesn't have access to a section the help content is off limits as well. That would also not allow for linking topics and creating a replacement for an Index and ToC may be possible using code, but adding search capabilities gets tricky (see d)).

What I proposed some time ago to MadCap is to implement conditions that get applied at runtime. Basically, that would generate the same output customization one currently gets using conditions, but the exclusion/inclusion would not take place when compiling the help system, but when making a help call. So a help call would include one or more conditions or none at all to display everything (or a specified default selection). ToC and Index are created dynamically and search omits everything that does not pass the conditional requirements. It would still be a lot of work for the developers and the tech writer, but by far better than my other proposals.

[dwag]

Thanks for the prompt, detailed replies. You've been most helpful.