Customer Portal

Get Involved. Join the Conversation.

Topic

    Shiloh Madsen
    Filter on language?Answered
    Topic posted April 10, 2009 by Shiloh MadsenBronze Trophy: 5,000+ Points, last edited October 29, 2011 
    4377 Views, 34 Comments
    Title:
    Filter on language?
    Content:
    One of the fields in our knowledge conent items is Language. I would like to be able to use syndication to constrain on that, but I am not sure if that is possible. Are we limited to the few listed in the documentation, or can I filter by any field? If so, how do I do that? 

    Best Comment

    Anthony Arnone
    You're on the right track, but you will need a bit more information in that filter. You would be better served looking at the section of the opensearch controller that deals with the custom $filters['os_filter' . $filter_num]. Here's a modification of that code:

    $temp_filter = $this->Report_model->getFilterByName('access_id');

    $filters['my_filter']->filters->fltr_id = $temp_filter['fltr_id']; // alternately, this can be "<table_name>.<filter_name>"
    $filters['my_filter']->filters->oper_id = $temp_filter['oper_id']; // this is optional. if you're not changing it ever, you can leave this off*
    $filters['my_filter']->filters->rnSearchType = 'custom_search_type'; // this can be anything as long as it is not null or 0 or 1 (or true or false).
    $filters['my_filter']->filters->report_id = $this->report_id;
    $filters['my_filter']->filters->data[]  = $value; // this is the tricky part, and is dependent on what your filter is. For language, it would just be the language ID, but for access ID, it's the full 40 character access mask number (it's a length 128 bitmask).

    You can have multiple filters, just name the next one 'myfilter2' and so on.


    The correct way to set this up is using "report hooks", which will allow for proper customization of your filters by adding the code in hooks.php. Check the regular documentation for report hooks for more details (versions 9.2+). There may be hooks-specific requirements in addition to the regular filter code.


    Anthony

    * if you want to change the operator, you need to chose from this list. These should be the same ones that are defined for the xml api and are defined in rnwintf.php
    //define(OPER_EQ, 1);
    //define(OPER_NEQ, 2);
    //define(OPER_LT, 3);
    //define(OPER_LT_EQ, 4);
    //define(OPER_GT, 5);
    //define(OPER_GT_EQ, 6);
    //define(OPER_LIKE, 7);
    //define(OPER_NLIKE, 8);
    //define(OPER_RANGE, 9);
    //define(OPER_LIST, 10);
    //define(OPER_NLIST, 11);
    //define(OPER_IS_NULL, 12);
    //define(OPER_IS_NOT_NULL, 13);
    //define(OPER_NE_OR_NULL, 14);
    //define(OPER_NLIKE_OR_NULL, 15);
    //define(OPER_REGEXIZE, 19)
     

    Comment

    • Anthony Arnone

      There are only a few contraints you can put on opensearch output (parameter names in parenthesis):

       

      search terms (q or kw)

      number of results (count)

      first result number (startIndex)

      sorting (sort)

      product filters (p)

      category filters (c)

       

      There are no other constraints you can pass in.

       

      There is a reason for this: the opensearch report does not actually have any filters other than those. If you'd like to change that, here's what you'd do:

       

      1. make a copy of the opensearch report in the reports explorer
      2. add any filter you'd like (interface ID or language or whatever)
      3. note the name of the filters, and the report number of the new report
      4. make a copy of the opensearch controller (this is possible in 9.2 and later)
      5. change the line that has the report ID defined to your new report number


      call this new controller, and pass in your filters like so:
         <site>/ci/new_opensearch_controller/q/<search terms>/f_<filter_name>/<filter_value>/...

       

    • Shiloh Madsen
      hm...does this still work if we haven't deployed CP on the interface in question yet? I don't know that we are using the MVC version of Syndication yet. 
    • Anthony Arnone

      If you're talking about classic enduser pages, then it's much harder: you would need to highly customize the opensearch.php page.

       

      This is mainly becuase there is no "f_* parameters --> filters" functionality in the classic version of the page. Also, classic opensearch runs off of the default answer report, as opposed to CP, where it has its own report.


       

    • Shiloh Madsen
      Hm...We might be able to use it on a different interface where we are looking at turning on CP. If that were the case, I still have the problem that I cant actually find the code for the syndication widget itself in the widgets folder...where is it?
    • HT

      Depending on your Rightnow version, you can download from one of the following sites:

       

       

      August'08

       

      November '07
    • Shiloh Madsen

      Yes...this is the front end code we would put on a page. I already have that. 

       

      What I need to know is where I go on the back end to make the controller changes so that it can


      A: Direct to my new report which has filters in place for my new passed parameters

       

      B: Add in logic for those passed parameters so that it will return the expected values.

       

      I am pretty sure that this is going to require that I copy the built in controller into a custom controller area. If that is the case, what page/view in RNT refrences the opensearch controller so that I might direct it to my new custom controller? I did a search for the page that the front end code for nov08 is directing to, but I cant find that page.  

       

       

       

    • Shiloh Madsen

      Ok, I found the built in controller, though I still need an answer to how best to customize it. I assume I cannot change the built in rnt one, nor should I, but I have begun building the logic locally. I am not sure what some of the items here do however. I used a lot of the kw logic to get me started, and here is what I have now for one of my two filters:

       

      if (isset($params['p_access']))

      {

      $access_filter = $this->Report_model->getFilterByName($this->report_id, 'access_id');

      $filters['searchType']->filters->report_id = $this->report_id;

      $filters['searchType']->type = 'searchType';

        }

       

      I already have a report created which has this filter of access_id in it. Is there anything that I either have in that I don't need for logic, or anything that I am missing for logic? Again, I wasn't certain what the purpose of a number of the lines of code were for the if logic on KW so I am pretty sure I missed something here.  

    • Anthony Arnone
      You're on the right track, but you will need a bit more information in that filter. You would be better served looking at the section of the opensearch controller that deals with the custom $filters['os_filter' . $filter_num]. Here's a modification of that code:

      $temp_filter = $this->Report_model->getFilterByName('access_id');

      $filters['my_filter']->filters->fltr_id = $temp_filter['fltr_id']; // alternately, this can be "<table_name>.<filter_name>"
      $filters['my_filter']->filters->oper_id = $temp_filter['oper_id']; // this is optional. if you're not changing it ever, you can leave this off*
      $filters['my_filter']->filters->rnSearchType = 'custom_search_type'; // this can be anything as long as it is not null or 0 or 1 (or true or false).
      $filters['my_filter']->filters->report_id = $this->report_id;
      $filters['my_filter']->filters->data[]  = $value; // this is the tricky part, and is dependent on what your filter is. For language, it would just be the language ID, but for access ID, it's the full 40 character access mask number (it's a length 128 bitmask).

      You can have multiple filters, just name the next one 'myfilter2' and so on.


      The correct way to set this up is using "report hooks", which will allow for proper customization of your filters by adding the code in hooks.php. Check the regular documentation for report hooks for more details (versions 9.2+). There may be hooks-specific requirements in addition to the regular filter code.


      Anthony

      * if you want to change the operator, you need to chose from this list. These should be the same ones that are defined for the xml api and are defined in rnwintf.php
      //define(OPER_EQ, 1);
      //define(OPER_NEQ, 2);
      //define(OPER_LT, 3);
      //define(OPER_LT_EQ, 4);
      //define(OPER_GT, 5);
      //define(OPER_GT_EQ, 6);
      //define(OPER_LIKE, 7);
      //define(OPER_NLIKE, 8);
      //define(OPER_RANGE, 9);
      //define(OPER_LIST, 10);
      //define(OPER_NLIST, 11);
      //define(OPER_IS_NULL, 12);
      //define(OPER_IS_NOT_NULL, 13);
      //define(OPER_NE_OR_NULL, 14);
      //define(OPER_NLIKE_OR_NULL, 15);
      //define(OPER_REGEXIZE, 19)
       
    • Shiloh Madsen

      Ok, I understand much of what you are saying in your code, but the second half totally threw me. Is simply instituting the code as you have described going to be enough, or do I need to be doing things with the report hooks that you talked about? If so, I am in trouble as I don't know the first thing about that. 

       

      I am also a little fuzzy about the last variable where you mention the mask of the filter...not sure what you mean there.  

    • Shiloh Madsen
      I also don't know what you mean when talking about changing the operator...can you elaborate?
    • Anthony Arnone

      Sorry for the confusion.

       

      Hooks are the 'preferred' way of doing filter customization, usually so you can intercept the existing connections to report model. However, if you're creating your own controller, and it calls report model itself (ala getDataHtml), the code I posted should do what you want.

       

      As for the actual data inputs for your filters, that depends on what kind of filters they are. Access levels is a tricky thing, but most other things (interface, language, a custome field) are self-explanitory. If you want to do answer access levels and you can't figure it out, let me know (a new thread would be good, so we can keep the issues separate).

    • Anthony Arnone

      Operators:

       

      Here's where filter operators come from:

      • When you're editing your report in the reports explorer
      • Go into the filters popup (just click 'Filters' on the ribbon)
      • Select your filter
      • Select 'Edit filter'
      • In the Definition section, you'll see a dropdown for operator.

       

      Whatever is selected is the default operator for that filter, but you can change that at runtime to something else (it must be valid - ergo something in that dropdown list). If you do want to change the operator, then you need use one of those defines that I posted.If you don't want to change it, then either use what you got back from getFilterByName():

       

      $filters['my_filter']->filters->oper_id = $temp_filter['oper_id'];

       

      or leave out that line altogether.

    • Shiloh Madsen
      Ok, that cleared pretty much everything up. I will do what you said about starting the thread on dealing with access level as it is an important thing that I will need. 
    • Shiloh Madsen

      Oops...I did still have an outstanding question. 

       

      So, I make these changes to the controller like you suggest...actually I DON'T make the changes to the controller, its a built in RN widget, so not savable. What I would need to do is make a copy of the controller, right? Given that, where would I save this copy? Finally, how do I get this new controller to be used over the out of box one? 

    • Anthony Arnone

      There's a place for custom controllers. Also, there's a sample custom contoller in there to work from. You can't copy a controller, but you can make a new one. Check here formore info:

       

      http://www.rightnow.com/help/crm/february09/Output/wwhelp/wwhimpl/common/html/wwhelp.htm?context=crm&file=cp_appendix_developer_resources.77.6.html#1143668