reactions: Extract check_add_reaction from add_reaction.

zerver/lib/actions.py

@@ -2188,6 +2188,76 @@ def notify_reaction_update(
     send_event(user_profile.realm, event, list(user_ids))
 
 
+def check_add_reaction(
+    user_profile: UserProfile,
+    message_id: int,
+    emoji_name: str,
+    emoji_code: Optional[str],
+    reaction_type: Optional[str],
+) -> None:
+    message, user_message = access_message(user_profile, message_id)
+
+    if emoji_code is None:
+        # The emoji_code argument is only required for rare corner
+        # cases discussed in the long block comment below.  For simple
+        # API clients, we allow specifying just the name, and just
+        # look up the code using the current name->code mapping.
+        emoji_code = emoji_name_to_emoji_code(message.sender.realm, emoji_name)[0]
+
+    if reaction_type is None:
+        reaction_type = emoji_name_to_emoji_code(message.sender.realm, emoji_name)[1]
+
+    if Reaction.objects.filter(
+        user_profile=user_profile,
+        message=message,
+        emoji_code=emoji_code,
+        reaction_type=reaction_type,
+    ).exists():
+        raise JsonableError(_("Reaction already exists."))
+
+    query = Reaction.objects.filter(
+        message=message, emoji_code=emoji_code, reaction_type=reaction_type
+    )
+    if query.exists():
+        # If another user has already reacted to this message with
+        # same emoji code, we treat the new reaction as a vote for the
+        # existing reaction.  So the emoji name used by that earlier
+        # reaction takes precedence over whatever was passed in this
+        # request.  This is necessary to avoid a message having 2
+        # "different" emoji reactions with the same emoji code (and
+        # thus same image) on the same message, which looks ugly.
+        #
+        # In this "voting for an existing reaction" case, we shouldn't
+        # check whether the emoji code and emoji name match, since
+        # it's possible that the (emoji_type, emoji_name, emoji_code)
+        # triple for this existing rection xmay not pass validation
+        # now (e.g. because it is for a realm emoji that has been
+        # since deactivated).  We still want to allow users to add a
+        # vote any old reaction they see in the UI even if that is a
+        # deactivated custom emoji, so we just use the emoji name from
+        # the existing reaction with no further validation.
+        emoji_name = query.first().emoji_name
+    else:
+        # Otherwise, use the name provided in this request, but verify
+        # it is valid in the user's realm (e.g. not a deactivated
+        # realm emoji).
+        check_emoji_request(user_profile.realm, emoji_name, emoji_code, reaction_type)
+
+    if user_message is None:
+        # Users can see and react to messages sent to streams they
+        # were not a subscriber to; in order to receive events for
+        # those, we give the user a `historical` UserMessage objects
+        # for the message.  This is the same trick we use for starring
+        # messages.
+        UserMessage.objects.create(
+            user_profile=user_profile,
+            message=message,
+            flags=UserMessage.flags.historical | UserMessage.flags.read,
+        )
+
+    do_add_reaction(user_profile, message, emoji_name, emoji_code, reaction_type)
+
+
 def do_add_reaction(
     user_profile: UserProfile,
     message: Message,