Has anyone found a successful method for hiding topics in an HTML output based on a user's role or license?
For example, if we have a topic called "Tips for Administrators" and a topic called "Tips for Clerks," is there a way to hide topics in the help file that are marked "Administrators Only", etc. so that if you're an Admin, you're only seeing that Admin topic, and if you're a Clerk, you're only seeing the Clerk topic, and so on? In another situation, if we have a module, "Settings," and another module, "Check Out," would there be a way to hide Settings topics in the help file from users who don't have permissions to see the Settings screens in the software?
I'm thinking the answer here is 'No', but thought I'd check if anyone has explored this themselves.
Thanks!
Hide topics based on roles/licenses?
Re: Hide topics based on roles/licenses?
We are trying to tackle the exact same problem at the moment.
Showing and hiding content dynamically that is tagged for a role/license (these tags are called condition tags) is easy to achieve on one HTML page. You can even do cool things like control which elements you show/hide with an in-page menu. See http://tregner.com/flare-blog/version-f ... l5-output/.
This all falls down when you are trying to dynamically show/hide parts of your table of contents. None of this condition information is passed through onto the 'menu proxy' or Skin elements which allow you to navigate through the document, so basically you are without a way to show/hide links dynamically.
Luckily you can control these settings well when building the HTML, so you can still generate n*m different versions of your help for combinations of role and license, but you will have to define these all separately and then, depending on the knowledge you have about role/license, serve the relevant link to your user.
Showing and hiding content dynamically that is tagged for a role/license (these tags are called condition tags) is easy to achieve on one HTML page. You can even do cool things like control which elements you show/hide with an in-page menu. See http://tregner.com/flare-blog/version-f ... l5-output/.
This all falls down when you are trying to dynamically show/hide parts of your table of contents. None of this condition information is passed through onto the 'menu proxy' or Skin elements which allow you to navigate through the document, so basically you are without a way to show/hide links dynamically.
Luckily you can control these settings well when building the HTML, so you can still generate n*m different versions of your help for combinations of role and license, but you will have to define these all separately and then, depending on the knowledge you have about role/license, serve the relevant link to your user.
-
- Senior Propellus Maximus
- Posts: 3669
- Joined: Thu Feb 02, 2006 9:57 am
- Location: Pittsford, NY
Re: Hide topics based on roles/licenses?
To the best of my knowledge, there is no way to achieve this out-of-the-Flare-box. The one author I know how achieved something approaching this told me that it took heavy s/w dev effort. She had to work closely with them, and the solution they crafted was complex and in some ways resulted in her having more constraints on just what she could do in the Flare project going forward. Sorry that I don't know the details myself. Just wanted to say that I don't think Flare, by itself (or even at all), can accomplish this out of the box.
Nita
RETIRED, but still fond of all the Flare friends I've made. See you around now and then!
RETIRED, but still fond of all the Flare friends I've made. See you around now and then!
-
- Senior Propellus Maximus
- Posts: 2632
- Joined: Wed Apr 14, 2010 8:01 am
- Location: Surrey, UK
Re: Hide topics based on roles/licenses?
One possible solution would be to generate two different help targets, one for Administrators and one for Clerks. You would then need your devs to work some magic so that the help file displayed depends on the licence of the user, but you might struggle to get your devs to do something like that for you - in my experience devs tend to be rather busy (they would say "overworked"!) so you'd need to do some persuading. You'd also need to be a bit careful with what gets included in your help file with judicious use of conditions to ensure that Admin stuff doesn't appear in the Clerk help.
Good luck, and have a chat with the dev manager, preferably accompanied by biscuits.
Good luck, and have a chat with the dev manager, preferably accompanied by biscuits.
Started as a newbie with Flare 6.1, now using Flare 2023.
Report bugs at http://www.madcapsoftware.com/bugs/submit.aspx.
Request features at https://www.madcapsoftware.com/feedback ... quest.aspx
Report bugs at http://www.madcapsoftware.com/bugs/submit.aspx.
Request features at https://www.madcapsoftware.com/feedback ... quest.aspx
Re: Hide topics based on roles/licenses?
I have a project where I dynamically show/hide content, and I include two menu proxies, but hide the one I don't want.KayJay wrote:This all falls down when you are trying to dynamically show/hide parts of your table of contents. None of this condition information is passed through onto the 'menu proxy' or Skin elements which allow you to navigate through the document, so basically you are without a way to show/hide links dynamically.
That's ok for menu proxies, but it won't work for the main top nav menu.
For my project, I think dynamically showing/hiding content works ok, but I think it works best for showing/hiding content within a topic.
There are certain limitations; e.g. you can't hide topics from search results, topic headings can't have dynamic text since the full text would be used in search results and xrefs.
-
- Propeller Head
- Posts: 58
- Joined: Tue Mar 21, 2017 3:35 pm
Re: Hide topics based on roles/licenses?
Another Flare author introduced me to this webinar - http://www.madcapsoftware.com/webinars/ ... cap-flare/
Your needs sound very similar to what Mike goes about doing in his project. Might be worth a look.
Your needs sound very similar to what Mike goes about doing in his project. Might be worth a look.