[bug] Impossible to search for a blocked user

[mirabilos]

Describe the bug with a clear and concise description of what the bug is.

After having (accidentally) blocked someone, it’s hard to unblock them, because even if you know their full @user@domain syntax, they don’t show up when searching for that string. (I run a regular DB export of followers and followees (see below for extra info), so I have that information, if nothing else.)

I’m not sure whether this is purely a client issue in multiple clients, and have already reported this to FediText and, if so, will also need to report it to Semaphore, or whether this is indeed a GtS issue.

(Clicking on a mention in Semaphore works to get to a blocked-user profile view sufficient enough to unblock, even if it throws alerts about failing requests towards the bottom of the screen in panic.)

What's your GoToSocial Version?

0.11.1 git-c7a46e0

GoToSocial Arch

amd64 binary

What happened?

I unblocked someone but (due to a FediText bug) the wrong someone, then wanted to revert that and had a really hard time doing so.

What you expected to happen?

When I search for a user using the full @user@domain syntax (or, probably, their full profile URL (e.g. https://domain/@user or web+ap://domain/@user for GtS; other instances’ formats differ), but I tend to have the “@” syntax at hand), I expected to be able to see that such a user account exists, select it, then see in the clients’ profile view that I blocked them, but unblocking and most of the other interaction possibilities are still there, even if e.g. posts need not be there.

Ideally, GtS should also not cause the clients to throw errors/warnings about requests failing in that case.

How to reproduce it?

• block someone from FediText or I guess Semaphore
• go to either client’s search tab
• type in the full @user@domain syntax of the blocked user
• see there is no result

For the second half, it needs a bit of preparation: to have a status in your own timeline, written by someone else (third) that @-mentions the to be blocked user. After blocking, click on that mention (in Semaphore; FediText doesn’t show it in-äpp but defers it to a webbrowser instead) to open up that user’s profile. (Or fix the first half of the bug first, then use the search feature to get there.)

Anything else we need to know?

I regularily run the following job by the postgresql user’s crontab:

#!/bin/sh
set -e
cd "$(dirname "$0")"
psql -A gotosocial >/path/to/export/follows.txt <<\EOF
WITH followees AS (
	SELECT '@' || username || '@' || COALESCE(domain, 'gts.example.com') AS acct
	FROM accounts, follows
	WHERE follows.account_id='01_MY_OWN_ACCOUNT_ID'
	  AND accounts.id=follows.target_account_id
	)
SELECT acct FROM followees ORDER BY UPPER(acct);
EOF
psql -A gotosocial >/path/to/export/subscribers.txt <<\EOF
WITH followers AS (
	SELECT '@' || username || '@' || COALESCE(domain, 'gts.example.com') AS acct
	FROM accounts, follows
	WHERE follows.target_account_id='01_MY_OWN_ACCOUNT_ID'
	  AND accounts.id=follows.account_id
	)
SELECT acct FROM followers ORDER BY UPPER(acct);
EOF
psql -A gotosocial >/path/to/export/mutuals.txt <<\EOF
WITH followees AS (
	SELECT '@' || username || '@' || COALESCE(domain, 'gts.example.com') AS acct
	FROM accounts, follows
	WHERE follows.account_id='01_MY_OWN_ACCOUNT_ID'
	  AND accounts.id=follows.target_account_id
	),
    followers AS (
	SELECT '@' || username || '@' || COALESCE(domain, 'gts.example.com') AS acct
	FROM accounts, follows
	WHERE follows.target_account_id='01_MY_OWN_ACCOUNT_ID'
	  AND accounts.id=follows.account_id
	)
SELECT followees.acct FROM followees, followers
WHERE followees.acct=followers.acct
ORDER BY UPPER(followees.acct);
EOF
psql -A gotosocial >/path/to/export/contacts.txt <<\EOF
WITH followees AS (
	SELECT '@' || username || '@' || COALESCE(domain, 'gts.example.com') AS acct
	FROM accounts, follows
	WHERE follows.account_id='01_MY_OWN_ACCOUNT_ID'
	  AND accounts.id=follows.target_account_id
	),
    followers AS (
	SELECT '@' || username || '@' || COALESCE(domain, 'gts.example.com') AS acct
	FROM accounts, follows
	WHERE follows.target_account_id='01_MY_OWN_ACCOUNT_ID'
	  AND accounts.id=follows.account_id
	),
    merged AS (
	SELECT acct FROM followees
	UNION
	SELECT acct FROM followers
	)
SELECT acct FROM merged ORDER BY UPPER(acct);
EOF

The /path/to/export directory is writable by postgresql and readable by my normal user, so I can access it. It’s also backed up, and, thanks to the sorting, diff(1)able.

In case that helps anyone…

[tsmethurst]

Heya, think this is an issue on our side indeed. I think our 'can you see this person' logic is a bit too strict in cases like this.