One Project: Two Versions, Two Sign-ons?

[BJanke]

In addition to our existing product, we are creating a sister software that needs to share the same help system. In Flare, I know that you can apply conditional tags to the project to create two versions from the same project.

However, some of the users of our new product will not necessarily be users of our existing product and must not have access to its help topics. Can Flare be set up to have one sign-on to the existing product and one sign-on to the new product? Users of the existing software could see both versions if they buy the new product, too.

What option in Flare allows users to see one version or the other?

[whunter]

Flare doesn't control what your end users see, it only allows you to create two different versions of the help file. It is up to your organization to incorporate the help files into the software products in a way so that users only see the appropriate version.

[Andrew]

In addition to our existing product, we are creating a sister software that needs to share the same help system. In Flare, I know that you can apply conditional tags to the project to create two versions from the same project.

However, some of the users of our new product will not necessarily be users of our existing product and must not have access to its help topics. Can Flare be set up to have one sign-on to the existing product and one sign-on to the new product? Users of the existing software could see both versions if they buy the new product, too.

What option in Flare allows users to see one version or the other?

In that sort of a situation, we would normally use conditions to generate two totally separate help files, and then have our application select which one to use based on user login.

[Steveman]

That's exactly what we've done here. We have three output versions and our portal determines which version the user gets based on logon. In some cases parts of topics are different and in other cases whole sections of the Online Help differ. It's a bit of a mission to control but it's not difficult, it just requires diligence. Certainly having a single source for each topic makes that process much simpler than it would have been.

[NeilsonB]

In that sort of a situation, we would normally use conditions to generate two totally separate help files, and then have our application select which one to use based on user login.

I have searched through the madcap forums for this, but don't seem to find out any specifics. Could you (or anybody with skills) please describe how to collect the login security details from within MCF, and then apply them to conditional tags. I'm assuming this is done by harvesting the registry?

Can this be done with javascript or should I be using something else?

Cheers

[whunter]

This isn't a technical answer but maybe it will help clarify.

Using Flare, you would generate two different copies of the help file, one for each condition. You would then include both copies of this help within your application. Your software developers would have to add some programming to your software application that exposes the correct version of the help to the user, depending on some criteria (user rights or role or whatever).

In other words, Flare itself does not use user credentials to build different conditional versions. You build the different versions, and YOUR software determines which version to serve to the user.

[NeilsonB]

Thank you for your answer.

To better clarify, I'm interested in the JS code that determines which security level or group to whom the logged in user belongs (not so much a specific user), then setting the conditions based on that variable output of that code. The rest is vanilla MCF and I've pretty much got that down.

Cheers

[NorthEast]

Thank you for your answer.

To better clarify, I'm interested in the JS code that determines which security level or group to whom the logged in user belongs (not so much a specific user), then setting the conditions based on that variable output of that code. The rest is vanilla MCF and I've pretty much got that down.

Cheers

Just to be clear, you don't 'set conditions' at runtime, after building the help; so you wouldn't be using any javascript code to set conditions. You can't dynamically switch on/off conditional content in a single help output. Instead, you would need to build and supply two separate versions of the help with your application, and you must write code in your application to determine which help to display for the current user.

You apply conditional tags when you're writing the content in Flare. When you build a target you can choose which conditional tags to exclude/include; so that would allow you to build different versions of the help to include in your application.