-
Notifications
You must be signed in to change notification settings - Fork 182
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Support for Emoji Reactions (Replaces #1980) #2127
Conversation
Not a review, but this reintroduces some of the deleted js locale files, which have been replaced with json files. |
Oops! Thought I fixed that in the rebase...
…On Wed, Mar 8, 2023 at 5:24 AM Plastikmensch ***@***.***> wrote:
Not a review, but this reintroduces some of the deleted js locale files,
which have been replaced with json files.
—
Reply to this email directly, view it on GitHub
<#2127 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABA3WHYUCJQHIREABXF4M23W3CCB5ANCNFSM6AAAAAAVTLJXFU>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
--
Brian "Neatchee" Resnik
|
This pull request has merge conflicts that must be resolved before it can be merged. |
Highly suggest this e4c411e to be added. |
Ah, I messed that commit up. Apply 9c4e060 afterwards. |
Hmh. Maybe something went wrong while porting, but Edit: Not important anymore, since "e" doesn't cause any errors anymore |
Apologies if this should be obvious, as I'm not really a Ruby/React dev: I'm not sure if I agree with exposing this setting to the end-user. Certainly not without enforcing a server-supplied maximum value. I am generally opposed to any changes that will fragment user experience without a clear advantage to the end-user. This also increases the test surface area as we'll need to make sure nothing breaks visually across any of the UI - desktop and mobile - regardless of what the user sets this value to. Can you make a compelling argument for why a user would want to make fewer reactions visible? More than a single line of reactions visible? |
@neatchee this was part of the original patch, I merely ported it. |
Oh. Huh. Okay. I'll get it merged when I can
…On Mon, Apr 3, 2023, 3:28 PM Jeremy Kescher ***@***.***> wrote:
@neatchee <https://github.com/neatchee> this was part of the original
patch, I merely ported it.
—
Reply to this email directly, view it on GitHub
<#2127 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABA3WH2OUIHQTCE5B27V6PDW7NFKNANCNFSM6AAAAAAVTLJXFU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
ff157b2
to
59848e2
Compare
This pull request has resolved merge conflicts and is ready for review. |
This doesn't seem to work on Husky. I would like to be able to add emoji reactions from Husky. |
Husky has to implement the ability to add reactions. |
I think Husky has this ability - but since it's a fork of Tusky specifically for Pleroma, it would need adjustment for this PR. |
Yes, most likely they don't check Mastodon instances for availability of this feature. |
It doesn't check. It just displays the emoji reaction button on every post, on every instance. I was hoping that this PR could implement the endpoint that Husky uses for emoji reactions, for compatibility's sake. |
It is not the server's responsibility to implement the API as the client expects for another software's implementation. |
Would it be possible to implement the ability to see who reacted to a post? Not showing what users reacted with while also showing who boosted/liked a post can cause confusion in quite a few contexts. |
That has been discussed as a separate change. It's desired. Just not done
…On Sat, Apr 29, 2023, 8:45 PM Essem ***@***.***> wrote:
Would it be possible to implement the ability to see who reacted to a
post? Not showing what users reacted with while also showing who
boosted/liked a post can cause confusion in quite a few contexts.
—
Reply to this email directly, view it on GitHub
<#2127 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABA3WH5LCXPHBCFFAQ4N7NDXDXN6LANCNFSM6AAAAAAVTLJXFU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
This pull request has merge conflicts that must be resolved before it can be merged. |
Fedibird uses the value "emoji_reaction" in the "fedibird_capabilities" key in the "/api/v1/instance" response to notify the client of the feature |
Ah, it's missing the margin. // line 1034
&--in-thread {
border-bottom: 0;
.status__content,
.status__action-bar,
.reactions-bar {
margin-left: 46px + 10px;
width: calc(100% - (46px + 10px));
}
} (This also needs to be done in vanilla styles) |
There's a bug in this in which someone can react to a post that's not visible to them (for example, a blocked account) |
Couple questions about that:
* Via direct API call? Or also via UI if the user was blocked after seeing
the post?
* Does the user receive a notification that the blocked user reacted to
them?
Will need to think about ideal behavior in that scenario since a "post does
not exist" page isn't feasible
…On Sat, May 6, 2023, 9:24 PM Emma ***@***.***> wrote:
There's a bug in this in which someone can react to a post that's not
visible to them (for example, a blocked account)
—
Reply to this email directly, view it on GitHub
<#2127 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABA3WH3ND6FHJDMUANYVGNLXE4PYXANCNFSM6AAAAAAVTLJXFU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Yes via the API, however I see no reason it wouldn't work via UI so long as the client hasn't received the updates that lead the post to disappear when blocked.
No.
The /:id/favourite and /:id/reblog endpoints return a 404 for any post you can't see, for any reason (block, post privacy, etc) - I assume that would be the behaviour to replicate here as well. |
..........What the hell did I do.... |
oh ok. I see. The custom_emojis_controller commit was pulled in because it was apparently also missed on this side? As for broken version.rb that's just a mistake on my part during conflict resolution. Are there other commits you see in there that shouldn't? |
yeah, 34f9e54 should not be in this PR, either (because it was another Catstodon specific commit) Actually, it wasn't a bunch, it was mostly the same commit from multiple rebases being shown after each other lol. |
I'm not gonna deal with rewinding the log again >.> Just reverting. |
This pull request has merge conflicts that must be resolved before it can be merged. |
This pull request has resolved merge conflicts and is ready for review. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is only a surface level review for now.
Gawd this one is too big and went through too many changes...
Another thing:
reaction
should be added to NON_EMAIL_TYPES
in app/services/notify_service.rb
as e-mail notifications for reactions are currently not supported.
@@ -2,6 +2,7 @@ | |||
|
|||
class Api::V1::CustomEmojisController < Api::BaseController | |||
vary_by '', unless: :disallow_unauthenticated_api_access? | |||
skip_before_action :require_authenticated_user!, unless: :whitelist_mode? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Isn't this also a catstodon specific thing to allow anyone to copy custom emojis? (@kescherCode )
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is and should not be in here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why is visibleReactions
missing from this file?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This file should have the .jsx extension (or better yet rewritten for .tsx)
import AccountContainer from 'flavours/glitch/containers/account_container'; | ||
import Spoilers from '../components/spoilers'; | ||
import Icon from 'flavours/glitch/components/icon'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wrong merge conflict resolution?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
visibleReactions
is also missing here.
@account.reacted?(original_status, name) | ||
|
||
custom_emoji = nil | ||
if name =~ /^:.*:$/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if name =~ /^:.*:$/ | |
/^:.*:$/.match?(name) |
return false if name.nil? | ||
|
||
custom_emoji = nil | ||
if name =~ /^:.*:$/ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if name =~ /^:.*:$/ | |
if /^:.*:$/.match?(name) |
Fabricator(:status_reaction) do | ||
account nil | ||
status nil | ||
name "MyString" | ||
custom_emoji nil | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fabricator(:status_reaction) do | |
account nil | |
status nil | |
name "MyString" | |
custom_emoji nil | |
end | |
# frozen_string_literal: true | |
Fabricator(:status_reaction) do | |
account | |
status | |
name '👍' | |
custom_emoji nil | |
end |
At least making the fabricator usable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmh this seems to cause a failure:
1) The status_reaction factory is valid
Failure/Error: expect(factory).to be_valid
expected #<StatusReaction id: 1, account_id: 110339817053204859, status_id: 110339817053191929, name: "👍", custom_emoji_id: nil, created_at: "2023-05-09 17:06:33.686302000 +0000", updated_at: "2023-05-09 17:06:33.686302000 +0000"> to be valid, but got errors: Limit of different reactions reached
# ./spec/fabricators_spec.rb:9:in `block (3 levels) in <top (required)>'
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, that's odd indeed. I'll not apply this for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I don't know how to fix that.
The fabricator itself works, it's just the fabricators_spec which fails
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This migration should only be needed for people who already merged this into their forks.
Though, that is basically everyone working on this ^^
This pull request has merge conflicts that must be resolved before it can be merged. |
Would either of you like to take over this PR? :) As mentioned above, I'm
not really a Ruby dev, I just wanted the feature and it was stagnant. Happy
to keep applying feedback but figured I'd offer it up :D
…On Tue, May 9, 2023, 11:22 AM Jeremy Kescher ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In app/controllers/api/v1/custom_emojis_controller.rb
<#2127 (comment)>:
> @@ -2,6 +2,7 @@
class Api::V1::CustomEmojisController < Api::BaseController
vary_by '', unless: :disallow_unauthenticated_api_access?
+ skip_before_action :require_authenticated_user!, unless: :whitelist_mode?
It is and should not be in here.
—
Reply to this email directly, view it on GitHub
<#2127 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABA3WH4O7DIOQF6BWBPDN53XFKDOXANCNFSM6AAAAAAVTLJXFU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I really shouldn't put more work upon myself, but I would be willing to take over. |
As I actively maintain this in my own fork, I'd be happy to take over. |
If @kescherCode can't take it, would it be easier on you if you provide
instruction and I implement to the best of my ability? Even if that means a
longer review? I don't mind at all, I just don't want to make this harder
than it needs to be
…On Tue, May 9, 2023, 11:53 AM Plastikmensch ***@***.***> wrote:
Would either of you like to take over this PR? :) As mentioned above, I'm
not really a Ruby dev, I just wanted the feature and it was stagnant. Happy
to keep applying feedback but figured I'd offer it up :D
I really shouldn't put more work upon myself, but I would be willing to
take over.
Already considered it when the old PR became stagnant.
—
Reply to this email directly, view it on GitHub
<#2127 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ABA3WHZLKQNGR35L5OXCH7DXFKHCFANCNFSM6AAAAAAVTLJXFU>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
I actually don't know, though it can be hard for me to give instructions sometimes. |
I won't really split this into backend and frontend because that would really mess with the history of the existing commits... |
Yeah... :/ |
One more migration that didn't belong here in the first place: |
We're off to PR number three. #2221 Closing this one out. <3 |
Originally #1980
This has been running in production without issue at https://urusai.social for several weeks now.
Urusai's repo is here: https://github.com/neatchee/mastodon