1. There's very little you should be doing here, as the help author, beyond delivering the help output. It's up to the developers to configure user privileges, open help in specific formats, etc.
2. Forms (and their controls) in a web application only need to call the topic/bookmark URL; no map ids are needed. That is, AcctMainFrm would call the AcctMainFrm.htm topic. However, if you wanted to name the topics differently, such as accounts_main_window.htm, then you'd need some form of alias file.
3. Don't let the example you've found cloud your judgment on making decisions for your environment, As I see it, their mission statement is really not similar to yours: they wanted dynamically-driven WebHelp AND HtmlHelp; you seem to want WebHelp only, but accessible by login privileges.
Your involvement will probably be either of these:
* Create a merged WebHelp project with the child projects containing user-specific information.
* Create multiple WebHelp layouts (merged or not), which would each be placed within specific directories and restricted by logins.
Which of Leon's two possibilities you go for would probably depend on whether you want one user type to be able to see the help for other user types. The first (merged project) would make all content available to all users. The second would provide help content appropriate only for the user type the developers specify, which is the better option if you have sensitive or restricted information in some help topics that not everyone should see.
OK, I need to do the exact same thing as the original requester--create context-sensitive help for users who log in as different role types--i.e., reader, contributor, editor, administrator, etc. The difference is that we are using HTMLHelp rather than WebHelp. In our current system (in which all user types see all context-sensitive help for all of the user types), IDs are mapped to bookmarked sections within topics rather than to entire topics. What is the simplest way for the next iteration of our product to change the help system so that users only see the context-sensitive help for their own user type? Right now, for example, for a "submitting a report" screen, we have context sensitive help on the data fields on that screen and for each field, the code calls the map ID to jump to the field- specific info for that field. However, the user can scroll through the whole help topic (since the script is mapped to sections of a particular large topic with multiple bookmarked entries, each with a separate map ID) and view the info for data fields that other user types only see in their view of the application.
For the next iteration of our product, what do I need to do to write the help files and how do I need to coordinate with the programmers who are creating the map files to restrict views of context-sensitive help to only the help for data fields and other functionality available to users of a particular user type?
I think you will need to generate different CHMs for different users and leave the developers to call the required file.
AIR help would enable you to have a dropdown with each user type and the user could then pick their section. Not quite what you want but an option. There is information about AIR help on my site. The dropdown for the user types is what is known as DUCC, dynamic user-centric help.
That is a RoboHelp 9 feature described in the RoboHelp Tour on my site. You haven't said what version you are using.
See www.grainge.org for RoboHelp and Authoring tips