Replies: 20 comments
-
I did something like this over in #1926: [link] + def safe_params
+ request.query_parameters.slice *::ActiveAdmin.application.safe_params
+ end
+ helper_method :safe_params
+
+ def default_url_options
+ super.merge safe_params
+ end But that was for a completely different goal |
Beta Was this translation helpful? Give feedback.
-
But to answer the question, I'd really like to see something like what you describe. I'm just not sure what the scope of this functionality should be. |
Beta Was this translation helpful? Give feedback.
-
That is similar.. I'm not taking into account what params to persist (just everything except for the controller and action), but I probably should. Really the best use of this feature is on the index pages, we have some users that always use a particular scope or filter and instead of always leaving a tab open of their search while they work they can now go back and forth and not loose their spot. I can see more use for this if there is some configuration for the interface (like showing/hiding a column). Arguably this state info could get persisted in the database to work across multiple user sessions. Would you like me to write up a cucumber test or something to demonstrate this more formally? |
Beta Was this translation helpful? Give feedback.
-
Maybe provide a previous search link above the filters that could fill in the search options and submit the form? |
Beta Was this translation helpful? Give feedback.
-
The standard solution is to use a destination parameter in your URLs that can override the default redirection. Ensure that the proper query params are set in that paremeter and you're good to go. |
Beta Was this translation helpful? Give feedback.
-
Passing parameters intended for future use in the url params links seems like a limited solution, because if you want to retain those params for more than one page you'll need to pass them around all over the place. If its a one page and then back kind of workflow then it could work, but what about between other index pages? index -> view -> edit -> view -> index is the typical workflow I've observed for most of my Active Admin applications. Passing the index's query parameters along to all these views seems like a lot of work when the session is a reasonable place to put and retrieve this. A previous search link, does sound like good idea, that would enable us to store a history of previous searches. Why stop there, what about "saved" or "favorited" searches for each user? |
Beta Was this translation helpful? Give feedback.
-
@rraub This is not intended to be carried across several requests, so you are correct in your assessment that that kind of workflow will not lend itself to what I suggest. The destination param in my experience is intended for one off situation in your workflow. For instance, you've filtered an index and clicked on 'edit', the param will point to that index filtered and on save you will return to that index filtered. If you click 'show' on the other hand, then on edit, you will NOT get the destination param and the redirection will be back to the show action |
Beta Was this translation helpful? Give feedback.
-
I'd really like to see this as well - I find it counter-intuitive that when I edit something from an index page, when I get redirected my previous filters / sorts no longer apply. |
Beta Was this translation helpful? Give feedback.
-
Maybe instead of trying to make the server remember the user's filters, it'd be better to store it with HTML5 Web Storage, and fallback to a cookie for IE < 8. [ref] |
Beta Was this translation helpful? Give feedback.
-
We could store the users filters on the client, however that would potentially require a page reload with the new filters since the only way to get at the stored values is using javascript. I still think storing them in the session isn't that bad of an idea. I would like to find an excuse to use HTML5 Web Storage for something.. |
Beta Was this translation helpful? Give feedback.
-
It wouldn't be that difficult to implement.
|
Beta Was this translation helpful? Give feedback.
-
Wouldn't that mean an extra request though? |
Beta Was this translation helpful? Give feedback.
-
Hmm, yeah you're right. I guess this would have to be handled by the server. |
Beta Was this translation helpful? Give feedback.
-
Here's an approach I came up with that saves filters between different renderings of a given resource's index page in AA: https://gist.github.com/tinynumbers/7235594 This only saves filters, it does not persist the last page you were viewing. |
Beta Was this translation helpful? Give feedback.
-
@tinynumbers that is a nicer implementation than I've been using. Have you thought about expanding the saved filters to include sort and maybe the current page? On a related note, does anyone consider modifying the params hash bad practice? You are kind of side stepping strong_parameters, but it is a simple use case and it does provide good feature isolation.. |
Beta Was this translation helpful? Give feedback.
-
I don't see any problem with it. I wouldn't say this is side stepping strong_parameters, because these specific params aren't destructive. While we might want to store the current sort, I'm not sure it makes a lot of UI sense to keep the current page. |
Beta Was this translation helpful? Give feedback.
-
I agree with @seanlinsley - I can see cases where saving the current page might actually be annoying (for example when doing a bulk delete, the page you were previously on might not exist anymore). Saving the sort order would be a pretty simple extension of what I've done for saving the filters. On a user-experience note, another feature I added to my current usages of this filter-saving is a CSS class that highlights currently-applied filters. The class is applied via some JS as follows: # Add an 'active' class to sidebar filters that were selected when the
# page was loaded.
$('#filters_sidebar_section').find('select[id],input[type="text"]').each ->
unless $(this).attr('id') is ''
if $(this).val()
$(this).parent('.filter_form_field').addClass('active') Then I can make the active filter fields pop visually (make them bright green or something), which helps avoid user confusion when coming back to the index page with re-applied filters. |
Beta Was this translation helpful? Give feedback.
-
Related: #2122 |
Beta Was this translation helpful? Give feedback.
-
I ran into this quandary and I have applied my own special band-aid. I've used a combination of the active_admin.js.coffee file for some javascript magic, combined with a little session magic on the server side in my Rails file. My objective:: Persist the user's filters from the index page to the edit page, so that when a record is edited, they can return to their filtered list. In active_admin.js.coffee:: What I achieve::
Here is the code I used to achieve the above:: CODE FROM ACTIVE_ADMIN.JS.COFFEE FILE::
CODE FROM APP/ADMIN/MY_ADMIN.RB FILE
Nuthin' to it! Probably not the most elegant solution, but it works for me :-) |
Beta Was this translation helpful? Give feedback.
-
I strongly support making this the default behavior, or at least making it settable in an initializer. |
Beta Was this translation helpful? Give feedback.
-
For a few of my Active Admin applications I've found that persisting the parameters for the index pages in the session gives the users a more persistent interface.
Heres what I've been doing to hack this in:
https://gist.github.com/rraub/6735432
Not the most elegant solution, but seems to work well.
What drove me to do this was seeing users use the index filters to narrow down the resource list, then edit one of the results and return back to the index page of the resource list without any of their filters they had just set.
I'm wondering if this is a feature others might want to, or if there are other use cases for this kind of feature.
Beta Was this translation helpful? Give feedback.
All reactions