Control Single Help Output Access Based on Product Module Permutations

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.

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.

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

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.

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. 

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.

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.

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).

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.