Home → Questions →

Detect Authed User in KB Article

• Edit

marc

12 Sep, 2012 07:29 PM

Hi -- Is it possible to optionally display some text in KB Articles based on whether or not the visitor is logged in?

1. 1 Posted by Amanda on 12 Sep, 2012 08:19 PM

   

   Hey Marc,

   Can you describe a use case here a little bit?

   • Edit

2. 2 Posted by marc on 12 Sep, 2012 09:20 PM

   

   We'll the general use case is simple. We'd like to display a prompt to register for a free account on our service in context with the KB article when the user is not authed. This would be irrelevant and annoying if registered users were inundated with that information.

   Something related and more specific would be to have access to the extras information embedded in an SSO. With that, we could display very targeted information to the user. Say, for example, you have a service that uses subdomains to identify a customer (e.g., http://yoursubdomain.tenderapp.com). If the user is authed and the extras information contains the subdomain, you could do show them their subdomain instead of a placeholder. Of course, you'd need some capability to use language constructs like if/else, etc. Maybe some combination of Markdown with Liquid support.

   I think it would be kewl and add some extra horsepower to Tender for everyone. It would make some pretty exciting things possible in KB articles like articles that change context based on the "type" of user viewing the article, for example.

   • Edit

3. Support Staff 3 Posted by Courtenay on 13 Sep, 2012 03:42 AM

   

   Interesting idea. I'm not sure the added complexity is worth it, though. (I could be convinced) We may indeed add liquid templates and extras parsing to the kb in future, and the more I think about it the more I like it. We're due for a kb rewrite in the next cycle of dev, in a few months (currently all resources are on a huge new feature).

   You can however use custom javascript to look at the available "public" user data so you always have something like this - (if you're using SSO then you probably can assume they have an account?)

   Tender = {
     logged_in: true,
     kb_enabled: true,
     is_supporter: true,
     user_id: 15075,
     root: '/',
     discussion_editable: false
   }
   

   So your custom js could show/hide classes on the kb page if Tender.logged_in == true We don't expose the users hash to the js, because that encrypted data is between your app and tender only.

   Finally, the "beta" and "important" user classes could also help here, if you have a free class and a paid class of user, you just put the paid class into important and have a whole separate set of instructions for them.

   Hope this all makes sense ;)

   -- Courtenay

   • Edit

4. 4 Posted by marc on 13 Sep, 2012 12:17 PM

   

   Thanks for the heads-up. The custom js enables us to do what we want to today.

   • Edit

5. Courtenay closed this discussion on 14 Sep, 2012 12:44 AM.