Customer Portal

Get Involved. Join the Conversation.


  • dmorgan



    Thanks! That is what I thought. I kind of figured it out when no one replied. I found out that the p_li_passwd filed has a value, and I incorporated that into my code but I'm still getting this (http://<some company> dreaded page. I'm not redirecting it to our login page for now. The MYSEC_EXIT_LOGIN_URL value is blank for now. I think that is Ok until I get things working. I'm using ASP with JavaScript to implement this. I have a php implementation of it as well but I'm having the same problem. My code for doing this looks like this:


        var params = new Object;
        params['p_userid'] = 'none';
        params['p_passwd'] = 'password';
        params['p_email.addr'] = '';
        params['p_li_passwd'] = 'myseclipasswd';
        var params_str = "";
        //iterate through array and url encode + build queryparam string
        for (var i in params) {
            params_str = params_str + i + '=' + Url.encode(params[i]) + '&';
        // echo params_str
        Response.Write("The param_str is: " + params_str + "<br /><br />");
        // declare base redirect url
        var redirect_url = 'http://<some company>';
        // append encoded query param string
        redirect_url += Base64.encode(params_str);
        //echo redirect_url
        Response.Write("The redirect_url is: " + redirect_url + "<br /><br />");
        Response.Write("Click here to redirect to: <a href='" + redirect_url + "'>RightNow Customer Portal</a><br />");
        // decode the encoded params_str


    I test it by clicking on the link. 


    And the redirect_url for the above parameters is:


    http://<some company> 


    1. Am I using the right base redirect url (http://<some company>


    2. Do you see any issue with the encoded parameters?


    3. We have the August '08 version of the cp, and I have a redirect url base that is in this format http://<some company> (notice the redirect_to instead of redirect) in the manual but both versions have the same issue. Could it be something else outside the login script?


    Thanks for your help.


  • Ernie Turner

    The Announcement field is controlled by the standard/display/AnnouncementText widget. This widget is referenced on most of the templates which are located at /euf/development/views/templates. The AnnouncementText widget loads a file out of the assets folder. By default this file is located at /euf/assets/announcements/announcement.html.


    If you want to remove the widget entirely, just remove the reference from the templates, or you can modify the announcement.html file if you just want to change what the widget displays.

  • Ernie Turner
    No, the p_li_passwd is not required, but its recommended that you use it for security reasons. Monique had a typo in post, she meant to say the value should be the same as what the MYSEC_LI_PASSWD config is set to.
  • dmorgan



    Is the p_li_passwd parameter a must for pta to work? If so, how can I set it's value in cp? What you wrote in step 3 is a bit confusing to me.  Shouldn't MYSEC_EXT_LOGIN_URL's value be the redirect to page url? I appreciate your help in this matter as I'm stuck trying to accomplish this with out passing the p_li_passwd parameter. 



    3 - make sure your value for p_li_passwd matches the config in MYSEC_EXT_LOGIN_URL




  • EAKBTeam

    Hi Leif,


    Thanks for your assistance, I now have the tooltips aligned correctly. I had to play with the width a little, but got there in the end.


    Thanks again,



  • domn

    Wow, thank you so much for pointing that out. It was indeed the overflow option causing the problem. Of course this opened up a few other problems in 7 but at least I know the root cause.


    Thanks again.  

  • Leif Wickland


    Thanks for providing me with your code. I managed to get it running on an internal site. The problem is in Input.css, which contains a rule like:



    tr.FormField td.FieldContent input[type=text], tr.FormField td.FieldContent textarea







    That CSS was replace with the following in a bug fix which appeared in Feb '09



    tr.FormField td.FieldContent input[type=text], tr.FormField td.FieldContent textarea






    When I was working with your site, just removing the "display:block" bit appeared to be sufficient, but I suspect there's a reason for the width change, too.


    That change is documented in the Feb '09 release notes on page 22 of the upgrade impact presentation.  There's no reason you would've seen that, but I thought I'd mention it so that other folks who encounter this might know where to look to find such solutions in the future.


    Please let me know if that change doesn't fix the problem for you.

  • Leif Wickland
    I'm really glad that you figured it out. Thanks for posting what you found that fixed the problem.

    Please let us know if you have further questions.
  • Leif Wickland

    I think that's a good solution that should work well.

    Thanks for posting what you found.
  • awoolson

    An AHA! moment.

    I had commented out "#rn_sidebar .rn_wrap - Comment out background image" and when I un-commented it out (or put it back in actually, ) everything seems to line up correctly - and the width of the announement box seems to have changed appropriately.


    Thanks so much for your help!!!

  • awoolson

    I really appreciate the help, but I still must be doing soemthing wrong.... after following you suggestion below, the home page looks like this in the development site (see image at bottom). the Announcement text is all the way at the bottom. Any idea where I went wrong?


    Thank you again for all your help and suggestions.




    11685RN.jpeg (139KB)
  • January Fredericks

    So I think we got this to work.


    We ended up going for the report approach. We updated the end user report to map_category  not equals (include no value) no value. We were already using a custom report for this, so it was just an edit.The search widget was already referencing this report. 


    Thanks so much for all your help. I hope I'm not speaking too soon. :)



  • Leif Wickland

    Thanks for the reply.

    I think this post basically explains what's going on. After the user clicks a link containing "/c/***", subsequent requests try to be smart (anticipating the behavior that the other poster requested) by reading parameters out of the current URL to be included in the next search. If you don't want the category filter to apply to the keyword search, you need to remove the "/c/***" bit from the URL. Two places you could make that change are:

    1. Subscribe to the on_before_ajax_request JavaScript event and modify the URL in the desired cases.
    2. Subscribe to the search button's click event. When the button is clicked, get the value of the search box and redirect based on it. For example, redirect to /app/answers/list/kw/theUserSearchTerm.

    I believe the Customer Portal documentation should have an example for subscribing to on_before_ajax_request.
  • Ernie Turner

    Both of these problems are created by a custom CSS rule that you added to the rn_basic.css stylesheet. At the top I see this rule



    body,div,dl,dt,dd,ul,ol,li,h1,h2,h3,h4,h5,h6,pre,code,form,fieldset,legend,input,textarea,p,blockquote,th,td{ margin:0; padding:0; overflow: hidden; }


    The 'overflow:hidden' rule is not in our standard stylesheet and is what is causing both of these issues in IE7. If I remove that rule through the use of the IE Developer Tools, both problems go away. For both issues the problem is around a DIV with the class name 'FieldInfobox', so maybe create an exception for DIV elements with that class name.


    All widgets should work across browsers, its part of the testing that is done on every release. However, as you've seen here, it is pretty simple to make them uncompatible with general CSS rules.



  • January Fredericks

    Hi Leif,

    That is exactly correct!