Customer Portal

Get Involved. Join the Conversation.

Comments

  • Ryan Peterson

    Hi Bastiaan:

    This is a great catch, and an unfortunate slip-up on our part! We definitely should have done better.

    I'm grateful you brought this to our attention and understand this is an issue for you and probably others. I've kicked-off our internal process here at Oracle to get this fixed!

    Regards,

    Ryan Peterson

  • Bastiaan van der Kooij

    You can target the columns by the classes of the td's. This however comes down to basic inspecting the code using Chrome Dev tools and see which class / id you can hook your css to. Something like this should work;

    .rn_GridColumn_1 {
      width: 15%;
    }


    Bastiaan

  • Pramod Vasudeva Murthy

    After 14 hours of fight, finally found a way to programmatically create a file and use it in the file attachment. Remember following are the hurdles I faced and why:

    • File pointer error - If you are reading and writing to the same file at a time. It is called "Concurrent modification" exception this occurs because there can only be one resource acting(resource lock) at a time and we cannot have another resource acting at the same time.
    • Invalid file attachment - This occurs because of mime type mismatch - expected CSV but given text(and viceversa). This also occurs if you are writing to a CSV without iterating each row. You have to iterate them and enter row-by-row.
    • Skipping header: If your CSV has headers then that needs to be skipped, you could use a simple $is_skip flag. There are many ways but this is the simplest of all I found.
    • Infinite for loop execution: This occurs when you are writing to a file and you misconfigure indexes; yes you cannot use file_get_contents all at once and just dump it, it will not work.

    Many simple things like this need to be discovered and educated around.

    One point that could have improved during this quest is Quality of Custom script Editor. It is close to impossible if you want to find out what went wrong. For Syntax errors and compilation fails, run-time errors - took a long time to understand what went wrong. If this is improved, we can progress much faster.

    Marking my answer as "best" as I hope it will help others and to close this post...

    - VIP

  • Bastiaan van der Kooij

    well if you can improve it a bit by not having your controller spit out its guts, while trying to send a mail is always nice :)

  • Bastiaan van der Kooij

    Actually this is not as hard as you might think. The first levels are prepared by the controller and all sub items are requested via Ajax. So it is just a matter of excluding items in the logic file in the constructor and then in the ajax response callback. I tested this, so might as well just attach the custom widget here.

    Just drop the widget in the folder custom/input/ and call it in the ask page like so;

    <rn:widget path="custom/input/ProductCategoryInput" exclude="28,10,2" name="incidents.product" />
    

    You can add parents and children to the exclude list.

    Bastiaan

  • Barrilito van Dijk

    Hi  J Smith,

    Of course you can do this. The osc widgets standard will place all the error messages together on top of the page. This is probably done out of simplicity of coding the widgets. You can alter anything you like, but you need some skills and understanding of the working of the widgets before starting a change like this.

    In general all the widgets in your form are forminputs, which in effect will load a text input widget or selection input or other input widgets. All those widgets will do a same kind of little trick. In the logic file of the widget a listener is set to the form like this:

    this.parentForm().on('submit', this.onValidate, this);

    If a submit is detected the onValidate function will be called, and that function will validate the input (depending if the field is required or not) and call a function to display an error, which is this function:

    this._displayError(errors, this.lastErrorLocation);

    The _displayError function will only look for a little div (or whatever html element) in the webpage that is assigned to display the error message, which is the one on top of the page. As this is a general standard input widget and the widget can be used several times in one page/form, the widget works like this on all fields, and therefore the widget works kind of "simple" by just adding the error message at the end of the element so that all errors end up line by line under each other.

    This is where you can hook in and change the way you set the error. You need to customize the widget and select any place in the page where you want to display your error. As the widget can be re-used many times throughout the page, try to do it smart. Perhaps add a parameter to your widget where you can define the error div name. So that your customized widget knows from that parameter what the div or span ID is where to display your error message. (in your case the area under the input).

    Makes sense? Good luck.

    Regards

     

     

  • Bastiaan van der Kooij

    CUSTOM_MSG_POPUP_TITLE_64 is a constant and its value is 1000288, so if you loose the apostrophes you should be fine.  Alternatively you can just use getMessage(CUSTOM_MSG_POPUP_TITLE_64), which comes from \RightNow\Utils\Config::getMessage()

  • Carl Elliott

    You found one of the hidden gems in the system that if you don't know how it works you will never figure it out.    

    Basically the conditional statement in your rule controls where SA is display using the Source field.    If you ever take the certification exam this is one of the questions on it.  

    This answer will show you how to set it up.  

    https://cx.rightnow.com/app/answers/detail/a_id/6081

  • Bastiaan van der Kooij

    There should be no need to load the base model in your extending model, since that is what the whole extensions config file is about. Just make sure you indent the extensions under modelExtensions with 4 spaces, since those yml files are super picky about that;

    modelExtensions:
        Incident: IncidentCustom

  • Andrew Rowse

    Having IDE based code completion for ConnectPHP can really help with the learning curve. My company has a free tool out there than can generate PHPDocs for a site's ConnectPHP API that has pretty complete coverage. If you use an IDE that supports PHPDocs, such as NetBeans (and I think Eclipse), this can speed things up significantly.

    New version of the toolkit is available here: http://cxdeveloper.binpress.com/product/cxdev-toolbox/3941

    Details on the PHP Stub generator here: http://cxdeveloper.com/article/cxdev-toolbox-php-stub-generator

  • Walid Sarkis

    Hello Sachin,

    there is 1 way to do that, you must develop an add-in using C# and integrate it with the desktop agent, i did that but using the CISCO IP phone:

    1- you need to make a webserver using the C# code , the following url will be helpful : https://www.codeproject.com/Articles/1505/Create-your-own-Web-Server-using-C

    2- the ip phone can handle http requests , so when the agent picks up the phone , you need to trigger the http request to the webserver by sending the caller's number in the url using HTTP GET : localhost:<port>?phoneNumber=123434

    3- after that, when the call came thru and the http request is done, use the screenpop feature of rightnow : the documentation is found after clicking the "?" button in the agent on the far right corner.

    Do note also that you can control the contact page using javascript API and the C# code so you will the caller's number in the phone number field

     

    Regards,

    Walid

  • Scott Harwell

    This problem exists in and outside of OSvC.  Your password and salt are only as secure as access to this script; the password is helpful when data is in transit making the key harder to derive, but access to the password negates that security.  Even if the password were calculated, hashed, or stored elsewhere, someone with access to this script will have access to the password either by directly viewing the script or injecting alternative code to get the password if calculated or from somewhere else.

    I think you have a few options:

    1. Keep the password in the file, as in the example, and limit any admin or developer account to only the most trustworthy individuals.  Harden your OSvC environment permissions as much as possible.
    2. Keep the password elsewhere, either in a separate file, configuration, or server, and import it when needed.  (But, people with access to your script will likely have access to the external source).  There isn't a hardened place to do so; this is minimal obfuscation.
    3. Create a calculated password that changes variables often which can be recreated at source and end points to randomize the password; though, again, if someone has the calculation then they can break your code.

    Alternatively, you could use web services so that the encryption happens at the transport layer and since you process the data as you require, then there is no need to encrypt.

  • Scott Harwell

    You should be able to create a custom version of the proactive chat widget and then you can alter the CSS at the widget level to change sizes and hide/show elements that you need.  Alternatively, you could make CSS-only changes at the theme or site CSS levels, but since this is specific to a widget, the widget CSS is probably the right place to put your changes.

    I think the window popup is controlled in logic.js using a window.open command.  You can alter the size of the popup by changing the parameters of that method call.

  • Dietrik

    Ask Oracle by a service ticket to have that enabled.

  • Barrilito van Dijk

    Hi Vitali,

    Within PHP use IS_PRODUCTION, IS_STAGING, IS_DEVELOPMENT.

    So your code would be something like:

    if (IS_DEVELOPMENT) {

      //do something...

    }

    Regards