CiviCRM
  1. CiviCRM
  2. CRM-9534

Contact Search record selection storage irrespective of previous / next page visits and improvement in current behavior

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed/Completed
    • Affects Version/s: 4.1.0
    • Fix Version/s: 4.2.0
    • Component/s: None
    • Labels:
      None
    • User friendly description:
      Hide
      this looks good.
      the only minor improvement to consider is that we auto-select the "selected records only" radio button when someone clicks a checkbox. but that selection is lost when we navigate to another page. we arguably should retain it (though an argument could also be made for the contrary)
      Show
      this looks good. the only minor improvement to consider is that we auto-select the "selected records only" radio button when someone clicks a checkbox. but that selection is lost when we navigate to another page. we arguably should retain it (though an argument could also be made for the contrary)
    • Is MIH?:
      No
    • Code Sprint:
      No

      Description

      1) If we do a contact search which results yielding 300 records, they'll span multiple pages. If we wanted to go through each page & select specific records to add to a group, for example, I'm only able to add them one page at a time because as soon as I proceed to the next page, the record selections from the previous page(s) are lost.

      2) This new feature will able user to traverse accross different search pages and select muliple contacts and then perform action tasks like : add to a group.

      we can remember the checkbox selection using AJAX, store the selection in table prev/next_cache table by adding "is_selected" column to pre/next_cache table and using that to identify selected contacts , and whenever user traverse accross serach pages the selection whould be maintained, by checking for the record selected through checkbox inside the table prev/next_cache .

      3) We can have a "reset selection" link on serach form , so that all selections can be reset .

      4) Also a page can be built which screens the selected records and a link to this page can appear on Tasks pages (eg Add Contact to Groups) , same can be done for CiviMail where we give the total number of contacts selected for a mailing.

        Activity

        Hide
        Donald A. Lobo added a comment -

        1. I suspect we might want to add a new column to civicrm_prev_next_cache table to store if the contact is selected

        2. We should also add a option to reset ALL selections for that search (so user does not have to go thru each page etc)

        3. We should modify the task code (in future pages) to use this cache rather than run the query again. This will probably improve performance a fair bit. But i would do this after ensuring the above works etc

        4. Yes adding a popup window to see all the people selected is good. However do ensure that this will scale for large number of contct selections (like in CiviMail). so you want to add a pager from the very beginning. Maybe use a really simple data widget which binds to a table given a key?
        Show
        Donald A. Lobo added a comment - 1. I suspect we might want to add a new column to civicrm_prev_next_cache table to store if the contact is selected 2. We should also add a option to reset ALL selections for that search (so user does not have to go thru each page etc) 3. We should modify the task code (in future pages) to use this cache rather than run the query again. This will probably improve performance a fair bit. But i would do this after ensuring the above works etc 4. Yes adding a popup window to see all the people selected is good. However do ensure that this will scale for large number of contct selections (like in CiviMail). so you want to add a pager from the very beginning. Maybe use a really simple data widget which binds to a table given a key?
        Hide
        Deepak Srivastava added a comment -
        #1, #2, and #3 are done. Passing on for final round of QA.

        #4 is not done yet. Scalable contact name selector driven from a table could be part of the sprint.
        Show
        Deepak Srivastava added a comment - #1, #2, and #3 are done. Passing on for final round of QA. #4 is not done yet. Scalable contact name selector driven from a table could be part of the sprint.
        Hide
        Deepak Srivastava added a comment -
        logged 25 hrs for #1, #2 & #3 in http://senatedev.senate.state.ny.us/issues/show/4519.
        Show
        Deepak Srivastava added a comment - logged 25 hrs for #1, #2 & #3 in http://senatedev.senate.state.ny.us/issues/show/4519 .
        Hide
        Eileen McNaughton added a comment -
        Hi,

        Just wondering on this ....

        I found that when looking into inaccurate counts on searches (caused by a join in a where clause added by an ACL hook) that the search was doing an expensive query to count the results (inaccurate in this case) & then later filling all the results into the prev_next_cache table.

        It seemed that in this case a more efficient approach was to query the prev_next cache table to get the result - did anything along these lines get incorporated into the fixes in this ticket?
        Show
        Eileen McNaughton added a comment - Hi, Just wondering on this .... I found that when looking into inaccurate counts on searches (caused by a join in a where clause added by an ACL hook) that the search was doing an expensive query to count the results (inaccurate in this case) & then later filling all the results into the prev_next_cache table. It seemed that in this case a more efficient approach was to query the prev_next cache table to get the result - did anything along these lines get incorporated into the fixes in this ticket?
        Hide
        Deepak Srivastava added a comment -
        Eileen, There hasn't been any work done on that part. And this requires some major restructuring.

        However "no of selected contacts" count on which a task has to be performed is now computed based on the prev-next cache.
        Show
        Deepak Srivastava added a comment - Eileen, There hasn't been any work done on that part. And this requires some major restructuring. However "no of selected contacts" count on which a task has to be performed is now computed based on the prev-next cache.
        Hide
        Brian Shaughnessy added a comment -
        this looks good.
        the only minor improvement to consider is that we auto-select the "selected records only" radio button when someone clicks a checkbox. but that selection is lost when we navigate to another page. we arguably should retain it (though an argument could also be made for the contrary)
        Show
        Brian Shaughnessy added a comment - this looks good. the only minor improvement to consider is that we auto-select the "selected records only" radio button when someone clicks a checkbox. but that selection is lost when we navigate to another page. we arguably should retain it (though an argument could also be made for the contrary)

          People

          • Assignee:
            Brian Shaughnessy
            Reporter:
            Pratik Joshi
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - Not Specified
              Not Specified
              Remaining:
              Remaining Estimate - 0 minutes
              0m
              Logged:
              Time Spent - 1 week, 2 days, 7 hours
              1w 2d 7h

                Development