Customer Portal

Get Involved. Join the Conversation.


    Disable customer log in.
    Topic posted September 19, 2008 by Skawn Blue Ribbon: 750+ Points, last edited October 29, 2011 
    1855 Views, 13 Comments
    Disable customer log in.

    On my current v7.5 site, when a customer wants to use Ask a Question, the following process happens:


    Any customer can get to ask.php - they enter their email address and their question and click submit (no password needed)


    At this point, customers who have used the service already are taken to the smart assist screen to finish submission.


    Customers using the service for the first time go to the account creation screen to fill in a few extra details and then to smart assist screen to finish submission.


    I'd like to do the same in customer portal but and getting really frustrated trying to achieve this.


    There are a few KB articles that look like they should cover this but none really explain (to a CP newbie like me at least) exactly what I need to be editing!




    • Ernie Turner

      There is a way to do something similar to what you are hoping to accomplish, but it won't be exactly like the way it works on your 7.5 site. The key here, is to make the Ask a Question page contain both incident and contact fields on the same form. That way, a user can both create an account and ask a question on the same form. I'll go through a step by step conversion process.


      1. Remove the login_required="true" meta tag from the ask.php page. This will allow non-logged in users to access the page.


      2. On the ask.php page, add a section that allows users to either log in, or create a new account, and only show this section if the user is not logged in. For example, the code I added is in the first image below (added code in white). This code will give users who have an account the ability to log in (which will refresh the  page), and users who do not have an account to create a new one with login, name, and email.


      I've done a screenshot below of what the new page should look like on your site.


      3. Optionally, you might also want the user to fill out additional contact information other than just what is on this form after their account/incident is created. In that case you can change the 'on_success_url' attribute of the FormButton widget to point to "/app/account/profile". When you do this though, you probably only want to redirect them there if they are just creating an account, so you can do that by something like this:


          <rn:widget path="standard/forms/FormButton" label="#rn:msg:CONTINUE_ELLIPSIS_CMD#" on_success_url="/app/ask_confirm" />

          <rn:widget path="standard/forms/FormButton" label="#rn:msg:CONTINUE_ELLIPSIS_CMD#" on_success_url="/app/account/profile" />


      That should mostly accomplish what you want I think. Let me know if you have any other questions on this conversion.


      Note: The example I've mocked up here was done on the August '08 version of Customer Portal.



    • Ernie Turner

      Attaching file "display.png" (23KB)

    • Skawn

      That looks close enough to me - I'll give it a try on Monday when I'm back in the office.

    • Ernie Turner

      I've just learned that the code example I've given doesn't work very well in IE because of the <form> within a <form> tag. Here is new code that should work.

    • Skawn

      What a week!


      Finally had time to have a go at this today.


      It's looking great, thanks for the help.




      EDIT: Just in case anyone else finds this thread and finds it useful, the final step needed was to change login_required="true" to false in the meta tags at the top of ask_confirm.php as we did at the start for ask.php

    • Skawn

      So close and yet so far!


      That works really well for new customers.


      It's going to cause existing customers an issue though - since they don't know they have accounts (since we don't currently require a log-in), anyone who has an existing account will try to use the new form area rather than the log in link which will give them an error when they try to submit (email already in database).


      Is there any way to mimic the behaviour I have on v7.5 where entering details in there creates an account for new users and links the incident onto an existing account for existing accounts (this presumably still happens for email)?


      We already have extranet services that require log in details so I'm very reluctant to have a seperate set of independant user credentials for our RightNow implementation.  I know I could get round this using pass thru auth but I don't have the budget to implement this at the moment.

    • Ernie Turner
      Unfortunately there isn't currently a way to set up the systems so it will take email addresses on existing accounts and automatically attach the incident to them. We are working on pretty much the exact solution you are asking for however. We realized a use case we were missing was customers who want users to be able to ask questions, but don't necessarily want/need them to log in with the accounts they create.
    • Skawn

      Thanks for the feedback.  Thats going to cause me some issues!


      Any idea when we might see that functionality?  I'd be tempted to wait until we can support this rather than try a less than ideal work around.

    • Shiloh Madsen
      In the example listed here, is it necessary to have an explicitly different username, or is it possible for the users email address to BE the username? Would any changes have to be made to accomplish this?
    • Ernie Turner
    • Demian
      I've looked around in the forums and haven't found anything, but has there been any update to associating the e-mail to the incident if it already exists in the database? Thanks!
    • Ernie Turner
      In the November' 08 version and beyond, you can remove the login required meta tag on the ask and ask_confirm pages and as long as the contact email address is the only field on the AAQ form, the incident will either create a new account with that email address, or associate the incident to the existing contact if the email exists. I'm pretty sure there is something in the Nov. '08 documentation about this if you take a look there.
    • Demian
      Ah yes, the issue was that I had additional contact fields other than e-mail. That fixed it. Thank you!