Skip to content

Add search, filter, order, and paginate capabilities to admin results view#7048

Merged
mrcasals merged 54 commits intodecidim:developfrom
liquidvotingio:feature/add-search-capabilities-to-result-in-the-admin
Jan 15, 2021
Merged

Add search, filter, order, and paginate capabilities to admin results view#7048
mrcasals merged 54 commits intodecidim:developfrom
liquidvotingio:feature/add-search-capabilities-to-result-in-the-admin

Conversation

@jinjagit
Copy link
Copy Markdown
Contributor

@jinjagit jinjagit commented Dec 18, 2020

🎩 What? Why?

Feature request (from: meta-decidim proposal #15783)

Summary: Make the admin results view searchable (by ID or title), filterable (by scope or category), orderable (by ascending or descending column values), and paginated (to 15, 50, or 100 results per page).

These features are implemented by this PR.

In addition, the results are now also filterable by status.

📌 Related Issues

This PR is related to issue #6988

📌 Related PRs

Related documentation changes PR #34.

Testing

As an Admin, select 'Processes', 'Assemblies', or 'Conferences' from the left-hand sidebar, and then select an individual 'process', 'assembly', or 'conference', respectively. Click on 'Accountability'. Results should now be listed and can be searched (by ID or title), filtered (by scope, category, or status), ordered (by ascending or descending column values), and paginated (to 15, 50, or 100 results per page). Note: To check pagination, you may need to create a number of new results until the results list contains more than the pagination amount(s) you wish to test.

Also, run the tests in decidim-accountability/spec/controllers/decidim/accountability/admin/results_controller_spec.rb, decidim-accountability/spec/system/admin/admin_manages_results_spec.rb, and decidim-accountability/spec/system/admin/filter_results_spec.rb.

📋 Checklist

🚨 Please review the guidelines for contributing to this repository.

  • CONSIDER adding a unit test if your PR resolves an issue.
  • ✔️ DO check open PR's to avoid duplicates.
  • ✔️ DO keep pull requests small so they can be easily reviewed.
  • ✔️ DO build locally before pushing.
  • ✔️ DO make sure tests pass.
  • ✔️ DO make sure any new changes are documented in docs/.
  • ✔️ DO add and modify seeds if necessary.
  • ✔️ DO add CHANGELOG upgrade notes if required.
  • ✔️ DO add to GraphQL API if there are new public fields.
  • ✔️ DO add link to MetaDecidim if it's a new feature.
  • AVOID breaking the continuous integration build.
  • AVOID making significant changes to the overall architecture.

📷 Screen-captures

  1. Search results by ID or title:
    search

  2. Filter results by scope, category, or status:
    filter2

  3. Order results by (ascending or descending) column values:
    order

  4. Paginate results to 15, 50, or 100 results per page:
    paginate

♥️ Thank you!

davefrey and others added 12 commits December 10, 2020 19:44
This renders the search elements on the accountability components results page.
We can action the elements but they don't have a filtering effect; so not broken but not doing anything.

Co-authored-by: Simon Tharby <jinjamail@gmail.com>
Search box, Filters, Pagination work, but when we try to write our own `@collection` query,
we get a broken SQL query. May need analogue to `ParticipatoryProcessesWithUserRole.for(current_user)`.

Co-authored-by: Simon Tharby <jinjamail@gmail.com>
This is the way to sort the columns, and it does sort, but is not
alpha-sorting on the translated titles (maybe on the translate key?)
Pushing what was left after our call; probably we'll ditch ResultsWithUserRole
To get the correct pre-search, filter, etc collection, we're reusing the `results` helper method.
We confirmed it's the right subset, against `develop` and comparing the emitted SQL.

We're talking about this action:
 # GET "/admin/participatory_processes/et-id/components/16/manage/"

#Co-authored-by: Simon Tharby <jinjamail@gmail.com>
Not working yet, copied from elsewhere

Co-authored-by: Simon Tharby <jinjamail@gmail.com>
Add both the column, and make it sortable

Co-authored-by: Simon Tharby <jinjamail@gmail.com>
This sorts, but not alpha on the values we see in the table -- same problem as Title
@jinjagit jinjagit marked this pull request as draft December 18, 2020 16:46
Add both the column, and make it sortable
@jinjagit jinjagit force-pushed the feature/add-search-capabilities-to-result-in-the-admin branch from ff48e79 to db6496d Compare December 18, 2020 16:57
This enables sorting by titles of results, in the different language versions of the title that can be supplied in json form in this field.
@jinjagit jinjagit force-pushed the feature/add-search-capabilities-to-result-in-the-admin branch from a260579 to df8dcfe Compare December 20, 2020 13:47
@jinjagit jinjagit changed the title Feature/add search capabilities to result in the admin Add search, filter, order, and paginate capabilities to admin results view Dec 22, 2020
@virgile-dev
Copy link
Copy Markdown
Contributor

@jinjagit this is looking really good (judging by the gif screencasts) ! Congrats 👏
I was wondering do you think we could add a filter by status or would it add a lot of complexity ?
Capture d’écran 2020-12-24 à 13 27 17

We're still trying to figure out where to build specs in the decidim project;
will hang onto this file for the moment
Reworking our approach to specs for the new features.
Now simply checking controller index action renders the index template, in results_controller_spec.rb.
Basic format of some capybara tests developed in admin_manages_results_spec.rb.
Custom context 'when managing results as an admin' created in shared_context.rb,
but may not be necessary/desired.
The fact that the development_app seeds use identical name values
for the different language values was masking the lack of
language specific ordering by scope.name.

The setup for the relevant caypara test now includes scope values
with different strings for different languages, to properly test
ordering by translated scope.name.
Add initializer to Decidim::Accountability::AdminEngine to use overrides.
Add scope.rb and category.rb overrides using class_eval in
decidim-accountability/app/overrides/models/decidim/core dir.

This avoids making changes to models outside of the Accountability context.
Rename files with more accurate and descriptive names.

Test of all results being listed was redundant, since
every test of ordering also implicitly tests this fact.

Refactor string concatenation to string literal (linting).
Insert a needed '/' in path, where Rubocop autocorrect created a
string literal from a concatenation.

Also move override files to dir that mirrors parent file locations.
@jinjagit
Copy link
Copy Markdown
Contributor Author

jinjagit commented Jan 7, 2021

Documentation: We have created a new screenshot and edited the text description in the online documentation for accountability. Please see #34.

armandfardeau
armandfardeau previously approved these changes Jan 8, 2021
@jinjagit jinjagit marked this pull request as ready for review January 9, 2021 12:39
Since this functionality will be useful in other contexts,
the ransacker filters are now available globally, rather
than only via overrides within the Accountability context.
@jinjagit
Copy link
Copy Markdown
Contributor Author

jinjagit commented Jan 14, 2021

@oriolgual Ransacker filtering moved into category.rb and scope.rb models, from overrides in Accountability, as discussed.

@jinjagit
Copy link
Copy Markdown
Contributor Author

jinjagit commented Jan 14, 2021

@oriolgual, @carolromero This PR code-instance is now staged @ https://decidim-staging.liquidvoting.io/


def collection
parent_id = params[:parent_id].presence
@collection ||= Result.where(component: current_component, parent_id: parent_id).page(params[:page]).per(15)
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jinjagit the description says the user can change the amount of results per page (15, 50 100), but the number is hard-coded here to 15?

Did you forget about this? Or should the description be updated?

Copy link
Copy Markdown
Contributor Author

@jinjagit jinjagit Jan 15, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mrcasals I believe this means it will, initially, display 15 results per page, but that the user can then select 50, 100 or return to 15 per page, and this can be seen in the screen-cast gif in this PR.

I will experiment with removing the hard-coded limit, to see if this improves the user experience, but I think the description is correct in either case (but could perhaps be more detailed).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jinjagit sorry, you're absolutely right!

As a side note, GIFs are a little hard to deal with, but now GitHub allows uploading videos, which are easier to control from the viewer side 😄

@mrcasals
Copy link
Copy Markdown
Contributor

Apart from that comment, code looks good!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants