Timeline for Deny location based access to nodes
Current License: CC BY-SA 3.0
8 events
when toggle format | what | by | license | comment | |
---|---|---|---|---|---|
Apr 9, 2015 at 20:43 | comment | added | Daniel | exactly, the problem with the pager leads me to another solution. But nevertheless I was not able to get it work with hook_query_TAG_alter() in an elegant way. But it was much easier with hook_views_query_alter(). Check my answer, if you are interested link.Thanks for the tip with some query_alter hooks! | |
Apr 9, 2015 at 18:03 | comment | added | AdamS | No the tag alter isn't an extra query. It allows you to alter the query that is run to generate the view. The default query will have something like "WHERE sine XXX cosine YYY blah blah < 30". Possibly you can rewrite it to swap the 30 (or whatever hard-coded threshold you had set) for the actual field value. If you can get it to work it's likely to be lots faster - with the pre_render approach, you fetch a lot of nodes then throw some away. Also not sure how pre_render would interact with paging (the query fetch say 20 results for a page - if you throw away some, it's not a full page) | |
Apr 8, 2015 at 17:19 | comment | added | Daniel | Thanks for this idea. But that would means, that I should run an additional query to get the distances for all nodes, calculate the distance to user and then pass an array with all relevant nids to the original query. So that would be some kind of double load right? I think the best solution is to use hook_views_pre_render to clean up the results. | |
Apr 7, 2015 at 20:24 | comment | added | AdamS | Ah sorry I hadn't appreciated that the distance was different for each node. Yes that's tricky. It might be possible to add a tag to the view (see under "Query Settings"), then implement hook_query_TAG_alter, and somehow tweak the SQL to compare against the field. Good luck! | |
Apr 7, 2015 at 17:01 | comment | added | Daniel | Yes, but imagine the following example: let's say I have three nodes. And I want, that the first one should be listed for all users within a proximity of 20km, the second one within 30km and the third one should be listed for all users within 60km. These distances are stored in a field of the node. If a user has a distance of 25km to all three nodes, he should just see the second and third one. And Views is just able to know these values after the query and cannot change the result afterwards right? | |
Apr 6, 2015 at 20:29 | comment | added | AdamS | The proximity filter relies on an origin point. In order to pick up the output of the Smart IP module as the origin, you would need a contextual filter with "Provide default value". If the Smart IP module doesn't provide this, it's not too hard to write one: you need a simple Views plug-in. | |
Apr 6, 2015 at 20:26 | comment | added | Daniel | Hi thanks for your answer. Location module also provides a proximity filter, but I can just enter a static distance. I think it is the same in Geofield. Regarding option 2: I also thought about a similar approach, but unfortunately it is not very flexible and scalable and it needs a lot of work... in the moment both options don't fit the requirements. But thanks for your ideas! | |
Apr 6, 2015 at 20:14 | history | answered | AdamS | CC BY-SA 3.0 |