Listable hides results when changing between tables.

Issue #346 resolved
Ryan Bottema created an issue

To reproduce:

1) Go to 'View All Service Events' from 'Service Log' menu.

2) Filter 'Service Status' to show only events that don't have the default service status.

3) Go to 'View <default service status name>' from 'Service Log' menu.

4) No service events displayed. The filter on 'Service Status' is still set to show only events that don't have the default status.

Reason:

'View All Service Events' and 'View <default service status name>' are actually the same Django view with get_queryset and get_page_title overridden to account for added url query. Therefore they share cookies.

Solutions:

A) Have Listable's cookies account for url queries. I can't seem to find a nice way to do this. @randlet , maybe you would have better luck.

B) Use separate Django views. This would also affect the 'Service Events Needing Review' menu option.

Note: Return to service menu items use a similar strategy.

Comments (15)

  1. Randle Taylor

    Hmmm, I'm not sure that using url query parameters is the right solution for the general case since a single page may have url parameters which change independent of what is shown in the data table. I'll see if I can come up with a better solution.

  2. Ryan Bottema reporter

    Something is still not right. Select widgets are not displaying stickied choices, e.g.:

    1) Navigate to 'View All Service Events'

    2) Select an option from any drop down filter, say 'Accelerator' from 'Service Area'.

    3) Reload page. Filters appear to not be sticky, but the queryset has clearly been filtered as only service events with service area 'accelerator' are displayed.

  3. Randle Taylor

    Not having much luck...it's an issue with the name of the cookie...if I set the cookie name in a similar way to the table id, you end up with multiple datatables cookies on one page which is causing issues. Not sure exactly why that's causing problems though. I think the safest move at this point is to use separate views.

  4. Randle Taylor

    Refactor ServiceEventsBaseList into multiple views

    See issue #346. Split ServiceEventsBaseList into multiple separate views which allows filtering of datatables to work.

    Also changed some of the urls to be a bit more consistent with qa urls.

    → <<cset 4a37bc2136d3>>

  5. Randle Taylor

    Got through refactoring the ServiceEventsBaseList but not the RTSQA. Not sure if I'll get to it later this weekend or not but if not you can tackle it on Monday. I am working on py34_sl_views branch.

    One question, for the review require list, should it show ServiceEvents with is_review_required=True and service_event__is_review_required=True or is_review_required=True or service_event__is_review_required=True as I have it now? i.e. do service events need both flags set to show up here or just one?

  6. Randle Taylor

    Ok think it's all working now and I think I answered my own question (even if a service event has is_review_required=True it should not show up if it has a service_event_status__is_review_required=False). Please double check things are working as they should and then that branch can be merged into py34

  7. Log in to comment