✨ Hide visibility of check-ins for individual users

[VXGP]

This new feature allows you to prevent individual users from seeing specific check-ins. This can be customized for each check-in individually. Users added to a check-in via this feature's menu will not be able to see that check-in on the user's "En Route," "Dashboard," or "Profile" pages.

see #4242

[VXGP]

Ich sehe, dass der Test unter anderem wegen der Datenbank fehlschlägt. Bei meinem lokalen Test hat allerdings alles funktioniert. Wie ist dieses Problem zu lösen? MfG.

[MrKrisKrisu]

Did you push all the files? At least one file is missing, e.g., the migration.

[VXGP]

e.g., the migration.

Possibly I forgot it! I will look for the missing files as soon as I am back home. :)

[VXGP]

All files should now be uploaded. @MrKrisKrisu

[VXGP]

I see that a check is still failing, which is strange since everything starts normally in my local instance. What can I do? @MrKrisKrisu

[VXGP]

I've added the last missing file that I have forgotten, sorry!

[VXGP]

I think everything should be okay now. @MrKrisKrisu :)

[VXGP]

With the last commits I fixed all "quality standard" issues. @MrKrisKrisu

[MrKrisKrisu]

With the last commits I fixed all "quality standard" issues. @MrKrisKrisu

Unfortunately, I won't be able to review this PR over the holidays. Perhaps someone else here has time, or you will need to wait until next year.

[VXGP]

I won't be able to review this PR over the holidays

All good, I have no problem waiting. I wish you happy christmas days. ^^

[MrKrisKrisu]

Just dropping some screenshots of the current state here:

[MrKrisKrisu]

This is explicitly not a review yet, I just skimmed through it, but here are a few comments:

1. In my opinion the UI is a bit toooo overloaded with this big component at the bottom. Even before, I thought it was chaotic, but now even more so. It takes up too much space.

2. Did you test your PR before requesting a review? The feature don't work for me at some points.
   -> for example: The model structure doesn't match the migration, so we cannot save to the table of hidden users. The Model try to save an uuid (which is good!) and the migration creates an id with unsigned big integer.

[VXGP]

Thank you for informing me about the UUID/ID issue, I will fix it as soon as possible. Of course I test the PR before submit it, but on my local machine the testing possibilities are slightly limited.

I will try to make the UI more minimalistic and to integrate it better in the empty space.

[VXGP]

Hey @MrKrisKrisu, I think now the PR is ready for review again.

[VXGP]

With the last commit I fixed the missing spaces at line 75 in "DashboardController.php". Now all "quality standards" should have been met. @MrKrisKrisu

[VXGP]

If I may ask @MrKrisKrisu, how long does it take to review a/the change? It has now been a week since I submitted the final commit. Since then, there has been no response from your side. And please don't get me wrong, I don't want to put any pressure or anything, but I'm just personally wondering how long the review will take. 😅

[MrKrisKrisu]

Hello @VXGP... Please note that Traewelling is a leisure project, which is why I cannot guarantee anything.

This pull request continues to be unmotivating for me because I personally do not want this feature. See discussion #4242, where I have already made it clear that I do not want this feature, but that you are free to create a pull request if you wish.

So far, apart from your request, I have only seen negative feedback about this feature, so I currently assume that there is no demand for this specific feature within the community. (see comments from @HerrLevin and reactions via thumbs up on the comments in the discussion #4242)

[VXGP]

Thanks, I understand that this can take time. However, I think there might be a misunderstanding here, and I want to clarify it to avoid talking past each other.

As I currently understand it, the pull request will not be reviewed at all. Please correct me if that’s wrong. My assumption was that it would be reviewed once you have the time, even if that happens later.

Initially, my understanding was that @HerrLevin considered this feature too complex and the UI too overloaded. Based on that, I was honestly surprised when I ended up implementing a fully functional feature anyway. I developed this entirely in my free time, which required significant effort and caused quite a bit of extra work and problem-solving on my side.

I proceeded with this because I was explicitly told that I am free to open a pull request. My assumption was that if I take full responsibility for the backend and the general implementation, the feature would at least receive a proper review for potential merging. If this feature is fundamentally unwanted, I’m struggling to understand why I was encouraged to create a pull request and invest roughly two weeks of work into it.

Regarding the feedback: the thumbs-up reactions currently come from only three users, including you, @MrKrisKrisu. As we both know, the Traewelling community is significantly larger, and I strongly believe that many more users would find this feature useful once they are aware of it.

IMPORTANT NOTE: This is not meant as a personal criticism or attack in any way, but purely to clarify expectations and avoid misunderstandings on both sides.

[MrKrisKrisu]

I'm sorry, my communication really wasn't good there. I'm not the only one who can review or merge here. Maybe others can also leave feedback here, including from the community.

I still maintain that I personally don't need this feature and tend to assume that it would further worsen Träwelling's performance (which is already very poor at the moment). I haven't validated this yet, but the query for the dashboard, for example, is already really... bad.

[VXGP]

All good, I understand. Regarding performance, I believe the feature is implemented in a relatively lightweight way and should not have a significant impact on overall performance.

I still hope that this feature can be merged into Traewelling, as I invested a considerable amount of time and effort into its development. If possible, perhaps another reviewer may be able to take a look at this pull request.

Feedback from others would also be very welcome and helpful. :)

[poeticpenguin]

Another friend of actually asked me a while ago, if something like that was possible. Kind of a similar situation to the Gamescom example VXGP provided. Let's just say, that some relationships cannot be dealed with otherwise.
As someone who knows what doxxing can feel, i am glad that this pull request exists - even though I personally currently (luckily!) do not need it.

Basically, it can be interpreted as a secondary "friends list" - a one-sided one; rather "non-friends".
Like in real life, where one would differentiate between buddies and friends. You might call someone a friend due to reasons, but in reality, that person should not know where your family lives for example; Only close friends.

What this should accomplish, is the opposite of "trusted users", but freely editable for every-checkin.

So far the philosophical side.

While i have no idea about the server structure, neither do i fully understand PHP code optimization yet, I do have food for thoughts:

Every user who opens the dashboard or a profile, will trigger a query, checking whether you are blacklisted for viewing specific check-ins or not. How would that exactly work?

One "showerthought" idea i had, was to only run the query, if a user has ever appeared on a blacklist. Thus, not every user will trigger that blacklist check, but only those who are already "critical". That would however mean, that a cronjob would need to mark those users reliably in a timely manner. That is not going to happen.
And in the grand scheme of things, we are dealing with private matters.

Maybe we should limit this feature to "friends" and followers for now to keep the amount of queries as low as possible. Allowing this PR for blocking any user (no matter if the person is a follower or "friend") might probably be indeed "overkill" and in the long term (not right away) cause more performance issues.

In short,
I suggest,

• Only friends and followers can be blocked from individual check-ins
• Take inspiration from the way the type box is designed and keep it as sleak/slim
• remove explanation and insert it into the insert/enter field itself
• Think, whether the "Trusted Users" feature, an existing filter, might come handy here

[VXGP]

The concept presented by @poeticpenguin is, on the whole, quite commendable. My only concern pertains to the configurability of the setting, which is currently limited to followers and "friends." What if the individual from whom you wish to conceal your check-in is not following you? Perhaps it would be more beneficial if users you follow were also included in the selection options. Also, it would be necessary for the selection on one check-in to remain, even if the user no longer follows you and you no longer follow the user, in case the user removes you as a follower.

Also, an important point is that the query doesn't only have to run if a user opens a profile or the dashboard, but also if a user who should not be able to see the check-in opens this check-in via a direct link or looks at the "En Route" section.