Closed (fixed)
Project:
Domain
Version:
8.x-1.x-dev
Component:
- Domain Source
Priority:
Normal
Category:
Feature request
Assigned:
Unassigned
Reporter:
Created:
15 Nov 2017 at 10:13 UTC
Updated:
22 Jan 2018 at 10:22 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
frank.schalkwijk commentedI tried to make this work, but I can't get the last part to work. When I try to view a view with a domain source filter I get an error saying domain_source field is undefined.
Also the hook_view_data_alter doesn't appear in the core modules so I think they solved their needs with the YAML files, but I don't see how.
Comment #3
agentrickardI don't understand. Views provides this support by default.
What are you trying to do with the filter?
Comment #4
agentrickardComment #5
agentrickardThis patch actually works fine for me. Did you rebuild the cache
drush crwhen testing?What I don't understand is this part:
What does this try to do?
Comment #6
spadxiii commentedJust did a re-roll (against latest dev) with a small fix for the '_active_domain' value as it wasn't filtering properly for the active domain.
The default domain_source filter seems to be an input field and not a select. This patch changes that filter to a select.
I don't know why there is a views.filter_value.domain_source entry in the domain_source.views.schema.yml file. Even after removing that (and drush cr), I could still use and configure the filter in the view.
ps. I found out what the problem was with the error as describe by Frank: it was custom code that was changing the options list.
Comment #7
spadxiii commentedAnd of course I forgot to attach the new patch ... :)
Comment #8
spadxiii commentedFound another typo in the last patch; correct in a new patch.
Comment #9
agentrickardThanks for the notes.
I have this mirrored at https://github.com/agentrickard/domain/pull/383 for testing, but have not updated the patch there.
Comment #10
spadxiii commentedIf there is no value for the filter, it is an empty string. That triggers a nice error with an array_search in the filter.
Corrected that in a new patch :)
Comment #11
agentrickardI haven't written any automated tests for Views yet. Have you nay ideas about how to test this?
Comment #12
spadxiii commentedI did a manual test where I added 2 domains, made a few nodes with each a different domain source, created a view with a domain source filter and when filtered saw the correct nodes in the view :)
This might take a bit of setup-code to test, but should be doable. I haven't done that either just yet, but I could look into that.
A few thoughts: the contents of the filter is not filtered by your permissions? Might be something worth adding.
What still feels 'wrong' is that a hook_views_data_alter is used to set the correct field/filter id.
Comment #13
agentrickardYou have to use hook_views_data_alter() because these are defined as "field UI fields" and therefore get default Views handlers assigned to them on creation.
Comment #14
agentrickardJust revisiting this patch. The domain.loader service has been deprecated. It's all moved to regular entity storage now.
Comment #15
agentrickardI've fixed the above and am looking at the filter now. I think we can commit this and worry about restricting the list later.
Both this filter and the Domain Access filter will need an option to "restrict" the list to assigned domains.
Comment #16
agentrickardThis has been committed!
I opened #2928354: Add filter options to domain_access and domain_source views as a follow-up.
Comment #18
spadxiii commentedMade a new pull-request: https://github.com/agentrickard/domain/pull/400
From the comitted patch, the domain_source.views.schema.yml seems to be missing. Without this file, views doesn't know what to do with a field_domain_source_target_id filter.
(ps. I can't re-open this issue)