Customer Portal

Get Involved. Join the Conversation.


  • Barrilito van Dijk


    Try not to combine too much code. It will not be readable, and you would have to guess (and try) what will be loaded / rendered first. Go for a clear and save approach, use the conditional page tags to show / hide a message based on the product in the url. See the ci/admin area and look for the conditional tags under the page tags.


  • Willie Eide

    OK. I think I found the source of the issue.

    In 16.8, the OSvC PHP team restricted access to some directories in the new PHP executable for security reasons. These changes were in PHP 5.6.3 and OSvC 16.8. After the release, it was realized that to many directories were shut down and thus were added back in 16.11. There is not mechanism to service pack those changes in 16.8. 

    /euf/assets was one of those directories

    While that is available again in 16.11 I understand that doesn't help you today. You can write to :​

    ./euf/application/source (and sub directories)

    to name a few.


  • Barrilito van Dijk

    Hi Pramod,

    Good to see you have some questions based on interest in the product and the fact that you really want to understand it all, that is for me already a reason to spend some time on it! smiley

    Here are my few thoughts:

    • Is CP 3.2.XX to any higher version is called CP Migration or is it completely different from my understanding?
      It all depends what you define by "migration". I would think a migration is anything that has to be moved from A to B of where everything has to be changed/altered of replaced by something else. But in the end my question to you would be: "what does it matter how it is called?" The process from CP2 to CP3 I would definitely call a migration as lots has changed. And yes, from CP 3.2.XX to higher can have much impact as well. Is it a migration? Perhaps it is, I don't wonder about how to call it. In general I always call it an upgrade, I just look at the differences and try to estimate the time I need and try to upgrade it decently so each upgrade is up-to-date to minimize a next upgrade.
    • After migrate how do we confirm that site has been migrated? At present, I am assuming that most of us will observe directory changes and folder structure changes(in Cyberduck) and also cross check in /ci/admin. If there are any other checks, please let me know.
      When we have migrated / upgraded, you will indeed see file changes. You can always look at the dates etc of the files, and in big upgrades from old to new the entire file structure differs. But in the end it is simple, you do a deploy of the files and if that goes well, and if the logfiles have no errors then you will look first at the deployed customer portal. I think most of the upgrades always have some specific visual change that makes you know that you are looking at the new files. If not, then you should either trust that it has been deployed or perhaps show something new in the content to be sure, but I guess this is always the same issue you have whith each deployment.
    • I understand custom widgets cannot be migrated as is - but wondering what is the importance of "Would you like to copy customized files to version 3? Both options require you to edit your custom code after migration?" and "Yes[If you have significant custom code]"
      Good question!  Personally I am not a fan of the conversion tools. Sometimes it can be handy to look at processed code what is done with it. The questions of the tool are not realy very transparent (perhaps due the translation to the language of your interface). So many times you are doubtful about what options to choose. In the end you keep on editing files. And what has been copied or created is never what I want. Many times I choose to rebuild / rewrite it all or to just copy the old widget, make a "1.0" subdirectory and change some minor things in the logic file and controller file. In an upgrade my advise would be not to develope new things, but if you have a big change from CP2 to CP3 sometimes it is wise to start from scratch and just use the new standard code, it all depends on how much is customized and how well you can update widgets or rewrite them. Especially in the newer releases lots of things change, you suddenly have a result page, new search widgets with new search sources and all is (almost) responsive, etc. So to get back to the question, it does not makes so much sense to me, and I prefer not to wonder to much about it and just rebuild it all or use an older widget that works fine if it is a simple widget that uses basic stuff that will not change for years.
    • Is DynamicformInput and DynamicProductInput deprecated in new version?
      I would not know, not realy familiar with it. I have seen some posts about it, sometimes widgets are suddenly gone...

    In general I would like to add that wether something is a migration or not, or an upgrade or not, there is in practice always more to it then the theory states. And most of it depends (unfortunately) on your own creativity and trust.

    Nice discussion Pramod!




  • Anurag Mittal

    Disable MOD_CP_ENABLED config setting

  • Bastiaan van der Kooij

    You should not use InitConnectApi in the Customer Portal as Connect is already loaded for you. Your Controller should look something like;

    namespace Custom\Controllers;
    use RightNow\Connect\v1_3 as RNCPHP;
    class AjaxCustom extends \RightNow\Controllers\Base
        function __construct()
        function sendMail()
            // your code here
            // Call this function like: /ci/ajaxCustom/sendMail
  • Bastiaan van der Kooij

    yeah the issue you're seeing is that the Constants are only defined in Production on what you're using so that would explain that building them dynamically is not working and they do not exist. As an alternative you can always use; 

    RNCPHP\MessageBase::find("LookupName = '".$messageName."'");
  • Rajan Davis

    Hi Janusz,

    To be very frank, I think what you are asking for is a lot bigger than just the ConnectPHP API. The API itself can be used in multiple scenarios:

    1. As a Custom Process Model (CPM) script -  I am not 100% sure, but I think these are custom scripts that are hosted through the console that are accessible through a specific URL. I haven't really used it in this way, but I am aware of it. You can find more information here
    2. In Analytics Reports - the reports have the ability to utilize the ConnectPHP API and regular PHP scripts. This is a really cool way to do some data manipulations, but I find that this is incredibly difficult to debug as script errors will fail silently (or you have to specify to a log which I am not sure how to access). I prefer to use the custom scripts with vanilla PHP only or, if I have a complex report, use the ConnectPHP API to use report results and then run them in another report so I can run multiple reports in one report.
    3. In Custom Controllers - this is where I have used the ConnectPHP API the most. I would venture to say that the majority of how the customer portal works (at least for CP 2.0) is through AJAX with controller endpoints. I have used controllers to generate JSON, perform complex but predictable automations, as well as create HTML templates that can be accessed via AJAX.
    4. In Custom Models - this is basically a nice way to create reusable code across the customer portal as it relates to business objects. I will often tie in very complex, object specific logic into a custom model so that it can be called from a custom controller when I am passing information in via AJAX.

    If it is preferable to you, you can send me a message and we discuss this a bit further outside of the forums. Again, to be very frank, the way the customer portal works was very cutting edge in it's inception but, in my opinion, is very much a legacy application. How things apply in terms of MVC is arguably outdated and can be a little convoluted.

    I would strongly suggest reading through the code examples in the ConnectPHP API specific to an object. I would pick one and try to work through creating an Answer using the example code; this was how I familiarized myself with this information.

    For the most part, you do not need to write custom code but rather utilize existing functionality; however, it took me several months to "get" how the customer portal internals work. 

    Additionally, I would read through the source code; there is a ton of information in there and it should give you more insight on how sessions are created and destroyed as well as how the customer portal "works". I would use the Fiddler chrome extension and trace which controller methods are being called via AJAX and then read the source code.

    If you are on CP3, you will have a hard time reading the internal libraries as they are restricted from WebDav access, but I have a way around that. The only issue is that you cannot make use of these libraries in custom code, there are restrictions in place that limit you.

    Kind Regards,


  • Bastiaan van der Kooij

    Ok Oracle considers it a bug and they'll fix it. In the meantime no child widgets ...:(

    This issue has been identified as a software defect which has been assigned to our product development department. The defect will be scoped and corrected in an upcoming version of Oracle Service Cloud.
    The issue occurs when one custom widget is used inside another custom widget.
    As a workaround, we should not include custom widgets inside a custom widget.
    After scoping the fix, Development will schedule the work and determine the target release. The target release depends on the severity of the defect and the significance of the necessary code changes.
    We do not yet have a date on which you can expect a fix in a new release but we will update this service request again in the future when the solution has been included in a new production release that is available for upgrade. 
  • Barrilito van Dijk

    Hi Marco,

    You can not add classes to the <rn:widget /> tags. These are OSC widgets which only can take some (optional) parameters. In a widget there is a reference to some specific styling for that widget. As you are probably working with a standard widget (an not a custom one), it would be easier and quicker to add some styling to the site.css file in your themes folder which is located in the assets folder.

    If you are not that familiar with customer portal development, perhaps look here first to learn about everything related to the customer portal.

    Important for you is to know:

    • on which page do you use the widget
    • which template does it use
    • which theme is used in that template
    • change the site.css of that theme and deploy the changes
    • Or, if you have a lot of styling to add, include it in the template as a link to a file

    Hope this helps. Regards.

  • Nisar

    Hi Kalaimagal,

    You can use the following to fetch the IDs and Values:

    $menuItemValues = RightNow\Connect\v1_2\ConnectAPI::getNamedValues("RightNow\\Connect\\v1_2\\Incident.CustomFields.c.custom_field_name"); 
  • Tim M


    The following worked for me on Windows 7 and it looks like it works.


    On Windows 7 try the following:


    1)     Click Start and click Computer.
    2)     Click Map network drive.
    3)     Click the link “Connect to a Web site that you can use to store your documents and pictures”, then click next
    4)     Click Choose a custom network location
    5)     Enter your WebDAV URL
    6)     Click next
    7)     Enter your user name and password when prompted.


    Only the secure connection appears to work with https:// on the 443 port with Windows 7.


  • DustinTuft

    LOL was that a hint hint?


    well so I wrote this very simple widget, my SQL call is a bit bloated, but it worked, I feel RNT could sup it up a bit and add the base engine for the nice scripting that Standard Texts support (hint hint)..


    I did decide this was easer becasue we have two interfaces that are both really the same except one is SSL and one is non SSL (non SSL is connected to our Lithium forum, so we could avoid the security notices when authenicating)


    Widget Call:


    <rn:widget path="custom/pgpstandardtext" standardtextid="1" />




    <rn:meta controller_path="custom/pgpstandardtext" /><?=$standardtext?>



    <?php if (!defined('BASEPATH')) exit('No direct script access allowed'); class pgpstandardtext extends Widget { function pgpstandardtext() { parent::Widget(); $this->attrs['standardtextid'] = new Attribute(msg_get_rnw(RNW_FILE_NAME_LBL), 'STRING', msg_get_rnw(FILE_NAME_ANNOUNCEMENT_DISP_PATH_MSG), '0'); } function generateWidgetInformation() { $this->info['notes'] = msg_get_rnw(WIDGET_DISP_CONTENTS_HTML_FILE_MSG); } function getData($data) { $data['standardtext'] = ""; $pgp_SQL = "SELECT val from std_content where (sc_id = '" . $data['attrs']['standardtextid'] . "' )"; $pgp_sla = sql_prepare( $pgp_SQL ); sql_bind_col( $pgp_sla, 1, BIND_NTS, 4000 ); while ($iisrow = sql_fetch($pgp_sla)) { $data['standardtext'] = $iisrow[0]; } sql_free($pgp_sla); return $data; } }


  • Dietrik

    I'd advice these people to invest in some proper training, Have a trainer or experienced consultant over for a couple of days to show the basics and guide them through the initial stages.

    This will get them up to speed fast and save them the frustration to try to find out themselves.

  • Gursimran Singh Saini

    Checking on Development Mode?

  • Bastiaan van der Kooij

    Hey John,

    the constant you are providing resolves to an ID of the message itself, so you should remove the apostrophes. You can also just use the shorthand;

    $message = getMessage(CUSTOM_MSG_DASHTEXT_STATUSCODE_14195);