Help File Based on User Roles

[CRO1]

Hello All,

Using RoboHelp X5, We are creating WebHelp for an application which is based on user roles. The application is composed of 10 tabs, the number of tabs the user can view is based on the assigned role. Each tab has a link to the corresponding help file topic. Is it possbile to implement a feature in the help file, whereby the user can only view help topics based on his/her application role?

For example: User 1 has access to tab 1,2,3. User 1 would only see the help file topics for tab 1,2,3, not the remaining tabs, 4-10.

Thanks,
Chris

[CraigCC]

Hi CRO1,

I'd go for a modular approach 10 .chm files or 10 webhelp projects. Then get your developers to exclude these modules depending on the users responsibilities/access - this can probably be set at login.

You can then have one introductory section for all users.

Hope that helps
Craig

[Peter Grainge]

This is a regular question so a search will bring up more information. In short, there is nothing in RH so one solution is to put the different users topics in different folders and your developers can then control access.

In your case I think the simpler solution would be to created different help outputs for each tab so that the help icon can call the topics for that tab. The tab access is already controlled by your application.

[RoboColum_n_]

Hi Chris. There are two sides to this issue. The first is... can the help files be developed to limit certain users to access only certain partsof it. The second is... can the application install only those help files required by the user.

To answer the first question (as it's easier ), yes they can. By using the build tag feature of RH you can apply a tag for each tab in your application and then include/exclude as appropriate to generate the required help files. You may also want to consider using child projects and merging them into a master project depending on the help file size.

OK now the more difficult part. I assume you only have one application which uses some sort of access right to control what tabs a user can see. If you adopted the child project appraoch, you could publish the output to different folders and then limit the access to those folders accordingly.

[RoboColum_n_]

Doh! All our posts overlapped! Friday afternoons... don't you love them!

[Peter Grainge]

Come on Rick, Leon, Roger et al. You are late on parade!

[HKabaker]

It's still morning on this side of the puddle.

H

[Roger_N]

Uh, yeah. What those other guys said....

Ok, here are my two centavos worth: Server-side scripting based on the user log in and permissions is the way to go. If this is in a corporate intranet, your network guys will create the groups, user types will be determined at login, and your web admin will set up the permissions for your various webhelp folders. On the WWWeb, users will register as a new user, and then log in at the application from then on.

Either way, you'll need an .asp page on the front end, to test for the usertype, and display your tabs accordingly.

And that's about all I have to say about that....

[Chet Zeshonski]

Of course, if your application allows for customized user privileges, you're stuck.

[Roger_N]

Chet -

quote:

---

Of course, if your application allows for customized user privileges, you're stuck.

---

Could you elaborate?

[Chet Zeshonski]

Sure can, Roger. To keep it simple, I'll assume that your application allows for two types of users: data entry specialists and administrators. Data entry specialists can access a subset of the application's features; administrators can access all of them, including the administrative functions (e.g., creating new user accounts, viewing user logs). In this case, the help author knows that he needs two sets of help files: one for data entry specialists, one for the administrators. This is the simplest case, and it's easy to provide separate help files based on RoboHelp's single-source layout capability; the application's programers simply load the proper one at logon based on the user's type. Even with multiple user types, this situation is relatively easy to handle.

But let's expand the scenario. Suppose that, in addition to X number of user types, you have an X+1 template: "Other." Furthermore, suppose that members of the "Other" group can be assigned any number of privileges in any combination desired. So, if normally data entry specialists get privileges A, B, and C, and administrators get privileges A, B, C, D, and E, a member of the "Other" group can get privileges A and B. Or A and D. Or C, D, and E. Or any of the large number of options available. This situation is not easy to handle, because you can't produce a single help file for members of the "Other" group.

Ideally, of course, you could make your help system modular, allowing for privileges (or groups of privileges) to be bundled into separate help files. But that creates some other problems, starting with the most obvious inconvenience: your help menu at the top of the application might contain a dozen (or more) links, which will probably confuse the user.

That's the situation at my NPO. The application contains five predefined templates, but it also allows for a sixth: "Other." And the next iteration will allow users to name and define their own templates, which blows modularity out the window. The best response I've been able to come up with so far? Put a link to the "Understanding Templates and Privileges" topic in the Related Topics button for each topic. If someone else has a better idea, I'm all ears. (Fortunately, no one has asked for such help-topics-by-privileges functionality.)

-Chet

[Captiv8r]

Hi Chet

I do have a thought on this. Possibly an easy way for you or others to achieve this "modularity" among the Data Entry folks.

I'm aware that those managing web servers can actually restrict who gets to see what. Now I should also preface this with the fact that I only have a vague understanding of the actual process that makes it happen, but I'm aware it is possible.

What if you constructed that foundation file in such a manner that each module has its own folder? Then, after you publish it all, your web server administrator can restrict the folders to only those that should see them. All based on login. So here you would have a full WebHelp system, but certain folders would simply be "missing" from the output. Again based on the user role.

I suppose this might bring to surface a different issue. How to handle the TOC, Index and other links pointing to possibly non-existent topics. (The topics are actually there, just obscured from the end user at run time, as they wouldn't have access to the folder. However, I'm thinking that even this *MIGHT* be somewhat easily handled by virtue of using a customized "404" page, that indicates proper permission is needed.

Just a thought... Rick

[HKabaker]

I always ask this question:

If the data entry people don't have access to the administrators' functions in the production application, what's the harm in letting them read help topics outside their box?

I'm assuming all work for the same company, and since it's one WebHelp package, they're using parts of the same application, or at least something closely related.

Keeping people in the dark is a good way of suppressing curiosity and discouraging thoughts of career enhancement. Don't some of the folks who work in compartments A and B sometimes get promoted, to compartments C and D, or shift laterally, to E and F?

If the supervisors in C are tearing their hair out over the way the grunts in A are doing their work, isn't it helpful for A to have some idea what C does with their output? Isn't it good for the company, when a supervisor retires or takes a job somewhere else, to have a pool of candidates who know how the company does things?

A friend of mine worked in a water heater factory for the summer and filled in for someone who was going on vacation. The task was to turn a piece of metal into something round. Before the guy went on vacation, he showed my friend how to do it, and the friend asked him how it goes into the water heater. "I don't know," he said, "I just make this piece round and put it in that box."

Harvey