Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ISSUE-463: The ADO to ADO JOIN filter #464

Open
wants to merge 20 commits into
base: 1.5.0
Choose a base branch
from
Open

ISSUE-463: The ADO to ADO JOIN filter #464

wants to merge 20 commits into from

Conversation

DiegoPino
Copy link
Member

@DiegoPino DiegoPino commented Sep 9, 2024

See #463

Note: this also includes commits from #461 . But that one will be merged first and the list will become "automagically" cleaner when that happens. It just makes testing easier while I work in parallel *using a single core brain with 8 good bits *

Filters the theme and ajax page state from the query, better checking if something is actually there and successfully updated, etc.
… driven

The idea here is that we also collect for all facets the other views present in the page and if they have pagers we also (not sure yet how) do a "refresh" either partial (reloading the attached behavior for the paging) or complete (easier but also more server intensive?) to make sure the facet selection does not get lost between paging but also the page itself (*current one) is re-used for those views so the view does not fully fully reset .

@alliomeria more to come. Not ready yet
Persist session and ajax page state too (breaking also in 10.3, facets actually need to be manually patched or will also break on ajax)
Another commit will also mimic back (update) the hash when people decide to search from 0 or again.
That way navigating between canvases won't break the URL
I need to still figure out if "flexibility" here is more important than speed. Why?
I can save (as in the code) the Solr Field name exactly the way i need if for the JOIN (or multiple) by allowing the Settings to use that instead of the Search API one, but... if the user decides to re-index an already setup field by changing the type the filter will break. But also, having to calculate the proper Solr name on every query is expensive. What will it be, what @alliomeria ?
@DiegoPino DiegoPino added enhancement New feature or request UX Like UI but with an X Search and Discovery Mess around and find out Drupal Views Ask and you should receive Search API Sub Modules When you need more .info.yml files to keep life organized Drupal 10 Upgrade economy Events and Subscribers get 2 printed issues for free labels Sep 9, 2024
@DiegoPino DiegoPino added this to the 1.5.0 milestone Sep 9, 2024
@DiegoPino DiegoPino self-assigned this Sep 9, 2024
When using Archipelago and Ajax views. Why? @alliomeria pleas read:
If you have more than one view on a screen, and if some views are loading automatically via Ajax (and/or depend on arguments of another) each one will compete for adding their own arguments to the Browser, breaking e.g an initial search set by the page level one. This new setting can be found under Advanced, Ajax. It is an opt out one, so people already using this don't need to change anything
Need to test more. Not ready yet
I did not count for the mutliple indexes option, and fixed it to its_nid ... bad boy here @alliomeria
Allow a dynamic loading View to also act on resets (which was hard gosh)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Drupal Views Ask and you should receive Drupal 10 Upgrade economy enhancement New feature or request Events and Subscribers get 2 printed issues for free Search and Discovery Mess around and find out Search API Sub Modules When you need more .info.yml files to keep life organized UX Like UI but with an X
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant