Control Single Help Output Access Based on Product Module Permutations

[RoboFan]

Running RoboHelp 2019 (update 12). I produce responsive HTML 5 help for a software application. The help will be hosted in the cloud (e.g. Azure) and users will access it via a link within the software application (something they have to sign in to, to open/run). 

The application consists of a standard feature set that all users receive but also includes a number of optional a la carte modules/features that they can purchase/subscribe to. Here's the big picture "ask": I'd like to restrict users from accessing help topics for modules they haven't purchased. Generating and hosting 30 different permutations of the help based on all the possible combinations of product modules is untenable.

General steps would look similar to this:

1. User logs into software application (authentication is managed via Auth0). User only has access to software modules they've purchased.
2. User launches help from software application. Some solution detects which modules the user has.
3. The help opens and the user doesn't have access to help topics/content for modules they haven't purchased.

Is anyone doing anything like this? I'm interested in any solution (e.g., RoboServer, third-party software, custom scripting/coding, whatever). 

I'm not interested in filtering - that relies on the user to control what they see. I want our customer information (provided after authentication) to control what they see. That said, maybe there's a solution that can leverage build tags (along with custom scripting/coding, some interface between our software and RoboServer, etc.) to achieve the desired goal. 

If RoboServer can do something similar to this, can it be performed without setting up and managing users in RoboServer? (That is, authentication is passed through to it from our software).

Thoughts?

[Peter Grainge]

One way I have heard of for controlling what modules are seen, when your other requirements don't apply, is to use merged help and only install the outputs for the modules purchased. Obviously there must not be links from the standard project to the modules where not all are being installed.

I can't speak for how RoboServer would handle things with your own authentication. I believe but am not sure that it can do what you want if configured by RoboServer. I will see if I can find someone with the requisite knowledge.

[RoboFan]

Thank you for the response, Peter. The end users are brick and mortar businesses. The software application is a web-based application that's installed locally and requires an internet connection. We prefer to host the help in the cloud and not install locally (in the past, my employer published locally installed software and we delivered/included help via CHM files).

However, you raise an interesting point. Each enduser will have some space in the cloud for data and other application dependencies. I hadn't considered the possibility of "installing" multiple instances of the help in the cloud. So if we have 1 core help system and, for example, 10 optional module help systems, and then generate all as merged help, but have our cloud network administrator and development team automate an install (copy/paste) of the core and relevant optional help modules based on the end user's product profile, that might work.

We currently publish merged help for 8 RH2017 projects for internal staff only - but all child projects are always included (we want staff to be able to access everything). For that reason, I'm not sure how merged help output functions (apart from the linking between projects issue) if you remove a child help system (by simply deleting it after publishing - or only copying/pasting the parent output and some of the child outputs). This *could* be a potential solution. I'll have to play around with merged help output, and depending on what I learn, then check with our cloud dev team on whether it'd be possible from their end. Two other benefits if this works: I still only have to publish "one" output (multiple projects, but only one output per project), and I don't have to worry about authentication (I can simply continue to piggyback onto our application's authentication).

[Peter Grainge]

You cannot simply add and remove child projects without generating the parent again.

http://www.grainge.org/pages/authoring/merging_webhelp/merging_method_2019.htm

I think you would have to create multiple merges, generate those, then let your developers point users to the correct combination.

[RoboFan]

My thought was that I'd generate one master merge output with all possible projects - for example, 1 parent project, with 11 merged child projects. The parent project is an empty placeholder/organizer with a re-direct to a "home" topic in one of the child projects (how we do it in RH2017), 1 child project is help for all standard/core functions/features that everyone gets (this is the project where I'd stick the target topic of the redirect), and the other 10 child projects are for each optional module. Then, I was hoping that if you copy/pasted from the entire merged help output the 1 parent project output, 1 standard/core child project output, and whatever combo of the other child project outputs, that copy of the merged help might still work (the absence of the projects not copied would just remove them from the TOC, index, etc. and the rest of the combined help would "just work"). 

Good golly. If my math is correct, generating multiple merges for all the different permutations for 10 optional modules would result in a little more than 1,000 different outputs. 

 I'd still love to hear if anyone has a solution to the overall issue. Thank you.

[Amebr]

I don't know how the developers did it, but in a previous job the developers fudged the structure.

We published our help like so (not in the merge structure):

Base Product

- v1

- v2

Module 1

- v1

- v1.1

- v2

Module 2

- v1

- v2

- v3

etc

The application sent a list of modules and versions installed and magic happened so to the end user it was like the help was published like this:

Base product v2

-mergedProjects

 --Module 1 v1

 --Module 2 v3

I think we were working with webhelp, but the principle should be the same for responsive or frameless.

Sorry I can't give details of how they did it. Hopefully my super non-technical overview can point your devs in the right direction.

At a different timeI did play around with removing children from a merge in responsive and from memory it was possible as long as the placeholder files initially generated by the parent were not deleted, that is, the screendata.js, projectdata.js and parentdata.js files remained in the correct folder locations. I can't remember if all had to be kept or only one or two. 

[Peter Grainge]

Responsive and Frameless merged help (in Classic and 2019 New UI) differs from the old merged webhelp in Classic.

In the old merged help you could remove a child project output and the parent knew which of the children were present and adjusted search and index accordingly. It was thus not necessary to regenerate the parent.

With responsive and frameless, the parent has to be told which children are present.

[Peter Grainge]

I have been given this information on RoboServer.

1. Please ask user to set up multiple areas and assign access to requisite users for that area in his/her case customers
2. User would then need to publish projects onto multiple areas (child or parent)
3. User can set up same project to be published into multiple areas using scripting
4. Auth0 / SSO is not support with RHS 10.0.2 but would be with RHS 11.0

[RoboFan]

I really appreciate all the feedback. 

"With responsive and frameless, the parent has to be told which children are present." -- Perhaps our devs could devise a script to write to whatever parent project file(s) need to know which child projects are included as part of the copy/paste/duplicate process when we spin up a new customer. E.g., - if customer has optional module 2, 3, and 8, then copy parent project, core child project, optional child projects 2, 3, and 8, and edit destination parent project file(s) to remove references to optional child projects 1, 4, 5, 6, 7, 9, and 10. 

I'm looking forward to learning more about RoboServer 11 - I'd heard Adobe was actively developing it. Was hoping to talk to Adobe about it at STC's Summit next month, but I'll have to wait for its release now like everyone else. Auth0/SSO would likely be a requirement for us, so support for that is good to hear.

[Peter Grainge]

Good luck with a script to tell a single parent which children it has.

It isn't that the parent has a file listing those children (it does, the TOC) but that it then goes on to create different searches and so on. The data is spread around different files.