✨ Hide visibility of check-ins for individual users #4246
Conversation
|
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. |
|
Did you push all the files? At least one file is missing, e.g., the migration. |
MrKrisKrisu
changed the title
Possibly I forgot it! I will look for the missing files as soon as I am back home. :) |
|
All files should now be uploaded. @MrKrisKrisu |
|
I see that a check is still failing, which is strange since everything starts normally in my local instance. What can I do? @MrKrisKrisu |
|
I've added the last missing file that I have forgotten, sorry! |
|
I think everything should be okay now. @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. |
All good, I have no problem waiting. I wish you happy christmas days. ^^ |
|
Just dropping some screenshots of the current state here: 
|
|
This is explicitly not a review yet, I just skimmed through it, but here are a few comments:
|
|
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. |
Added the option to hide a check-in for a user directly at the check-in itself, and not only in the window where you can edit the check-in.
The bug that you were able to select yourself in the hidden user menu.
|
Hey @MrKrisKrisu, I think now the PR is ready for review again. |
|
With the last commit I fixed the missing spaces at line 75 in "DashboardController.php". Now all "quality standards" should have been met. @MrKrisKrisu |
|
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. 😅 |
|
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) |
|
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. |
|
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. |
|
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. :) |
2 participants
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