Deses
August 26, 2020, 2:28am
1
So, since the new update if you want to filter anything in the query logs you have to press control + click or shift + click.
That's all fine while I'm using my desktop... But..
The thing is... What do I do if I'm using my phone?
jfb
August 26, 2020, 2:46am
2
On mobiles you need to type the search term in the search window.
Searching and filtering do not behave exactly the same way. Searching is inclusive while filtering is exclusive.
See the screenshot where I searched for "Google.com"
There is an open issue ticket on github, maybe you have a good idea how to design the UI to include all the searching, filtering, selecting on desktop and mobile?
opened 09:17PM - 14 Aug 20 UTC
### Versions
- Pi-hole: 5.1.2
- AdminLTE: 5.1.1
- FTL: 5.2
### Platfo… rm
- OS and version:
- Platform: RPi
### Expected behavior
In a mobile browser, I should be able to click on an item in the query list to filter with. This was previous behavior prior to AdminLTE 5.1
### Actual behavior / bug
Clicking does nothing on mobile now. This is a consequence of this change: https://github.com/pi-hole/AdminLTE/pull/1222
### Steps to reproduce
Steps to reproduce the behavior:
1. On a MOBILE device, go to admin portal > Query Log > try to click anything as you could before to filter by that item.
2. Clicking does nothing other than highlight the item.
## Debug Token
- URL: https://tricorder.pi-hole.net/83rew407ff
<!--
Token generated by running `pihole -d`. https://docs.pi-hole.net/core/pihole-command/#debugger
The token is displayed at the end of the debug process if you allow for uploading the log file.
[✓] Your debug token is: https://tricorder.pi-hole.net/wim5hft4rq
Debug logs are visible ONLY to developers and support staff. They are not publically accessible and all logs are automatically deleted after 48 hours.
-->
### Screenshots
<img width="940" alt="Screen Shot 2020-08-14 at 2 00 09 PM" src="https://user-images.githubusercontent.com/41453087/90293325-aff7aa00-de38-11ea-807c-fe8346bdb8ec.png">
### Additional context
_Add any other context about the problem here._
Coro
August 26, 2020, 12:42pm
4
Yes, this is needed. Mobile devices lack certain inputs.
In my world, this does not mean that devices with more input capabilities (like a mouse and keyboard) should refrain from offering such features in addition just for the sake of everything is impossible even if you have only a fat finger as the sole input.
Deses
August 26, 2020, 12:49pm
5
yubiuser:
There is an open issue ticket on github, maybe you have a good idea how to design the UI to include all the searching, filtering, selecting on desktop and mobile?
The old UI worked fine in both computers and mobile devices, right? I could agree that having to uncheck a box to select the text was a bit clunky, but at least we had full functionality in both types of devices.
Coro
August 26, 2020, 1:23pm
6
We have an open ear (and eye!) for un-clunky suggestions
Deses:
The old UI worked fine in both computers and mobile devices, right? I could agree that having to uncheck a box to select the text was a bit clunky, but at least we had full functionality in both types of devices.
The old UI did not have the ability to filter at all. You can see the steps the development took here:
When using the Query Log Search field, I can't seem to search explicitly, even with quotation marks. For example I want to filter/search for IP 10.0.1.6, but instead I'm getting 10.0.1.6*, where the * is all other numbers as well.
Is there a way to do this through the admin console or must I use the terminal? Thanks.
Deses
August 26, 2020, 3:28pm
8
We may be talking about different things, but I used to click on a device or a hostname and it filtered just that.
I think I can see the confusion. On the older UI, clicking on a domain (or client) would populate the search box with the domain (or client) clicked. @yubiuser is technically correct, filtering did not exist on the previous UI, rather a shortcut to populating the search box, did.
Coro
August 27, 2020, 9:24am
10
So we add this check box back but leave it disabled by default?
Mobile users can then tick the box and auto-copying of the stuff into the search field would happen.
It's more of an issue of storing state. Any ticks and toggles have to be stored somewhere unless you want to tick and toggle every time you load the panel.
Gave this some thought this morning, and came up with the following proof of concept:
pi-hole:devel
← pi-hole:tweak/queryfilters
opened 07:41AM - 28 Aug 20 UTC
**By submitting this pull request, I confirm the following:**
- [x] I have r… ead and understood the [contributors guide](https://github.com/pi-hole/pi-hole/blob/master/CONTRIBUTING.md), as well as this entire template.
- [x] I have made only one major change in my proposed changes.
- [ ] I have commented my proposed changes within the code.
- [x] I have tested my proposed changes, and have included unit tests where possible.
- [x] I am willing to help maintain this change if there are issues with it later.
- [x] I give this submission freely and claim no ownership.
- [x] It is compatible with the [EUPL 1.2 license](https://opensource.org/licenses/EUPL-1.1)
- [x] I have squashed any insignificant commits. ([`git rebase`](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html))
---
**What does this PR aim to accomplish?:**
- Allows mobile users to be able to use the new filtering options as well as desktop users
- Removes need to hold down a modifier key to add or remove to/from the filter. Simply click the field to toggle it on/off
- Utilises the ctrl/meta modifier keys for desktop users to copy domain to the clipboard (mobile users can long-press the domain and use native browser functionality to copy highlighted text)
**How does this PR accomplish the above?:**
**What documentation changes (if any) are needed to support this PR?:**
Possibly docs, I've not checked. This may need to be replicated to long term tables?
Should allow both desktop and mobile users to enjoy the new filtering, with or without a keyboard.
Keep in mind, this is still a draft/WIP but just to give an idea.
Initial testing on dektop and mobile worked very well.
ADD
Does not go well with the link for "Blocked (regex blacklist)
Ah, yes, it probably does not. This was probably the thinking behind the modifier key. Back to the thinking room....
Can you distinguish if users click directly on the link text or only in the surrounding box?
Yeah I was just thinking something along these lines. One would have to be very accurate with their clicking, which can be a pain on mobile.
Yeah right...
Adding a small button/icon in the regex box which links to the regex list? Then the easy "default" would be the filtering, and only for detailed regex info users had to aim very precisely.
Coro
August 31, 2020, 9:17am
18
Keep it as it is. Do not make it harder to use this on the desktop where real research into things may happen.
system
Closed
September 21, 2020, 9:17am
19
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.