Accepting movie/tv requests on overseer/jellyseer using discord reactions 👍/👎 ✅/❌

[tacoroumen]

im not sure if this is the best way but this seemed to do the trick for me #40

Lets you set the admin discord id via the ui

[thomst08]

Hey @tacoroumen,

I'll have to have a look at the feature, from the code... It looks OK, I will test it and get back to you.

[thomst08]

Hmmm, OK, I see what you've done here, so here are a few notes:

• The default way requests are made is the message is private in the channel and sent to the user who made the request, so, only that user sees the message but not other users despite it being on a server, if the request is auto approved, it works no problem, if not, it shows the react info, the issue is this type of message cannot be reacted to and the admin cannot see it, this might work if it is shown to all users, however, the message might not show what move was selected for other users, as I think it sometimes only shows the select drop a movie drop down, but I would have to check that.
• What would be wise is for the bot to send a message directly to the "admin" or a dedicated group of admins or guild, then their reaction would allow the approval.
• I am unsure how this would work if the bot disconnects, resets or if the message times out, there would have to be something to checks the message status later or if Discord auto sends status changes of a message to the bot (this just needs to be checked), the bot then needs to react according to the change.

The overall process is right, just not quite there yet. There are some edge cases it would be good to handle/check.

[tacoroumen]

About the 3rd bullet in the footer there is a request id this would do the trick (by my testing) the other 2 I didn't think of that haha

[tacoroumen]

This would also handle the other feature request of a message for multiple servers as a single admin channel would then also do this trick if I have time I will look into this tmr

[tacoroumen]

Hey @thomst08 i have updated the code i have implemented the admin channel and a toggle to "Send all requests to admin channel(s), not only pending ones." in the ui #69 you can aprove from the request channel if hide slash is disabled or from the admin channel always

[thomst08]

@tacoroumen, Nice!
I'll check it out when I can, but it might be a little while. I'll let you know when I've had a look :)

[thomst08]

Ok, I have had a chance to look at the branch.

First of all, @tacoroumen, good work, this is very nice, it pretty much works as expected. I haven't looked into how things are done in the code too much right now, but the functions work fine. I think this is pretty good to be merged, but I think we can improve it just a bit better to improve the flow and user experience.

I did a bit of a stress test and these are some of the things I found/my thoughts (in no particular order)

• If you don't have anything in "Admin user ids for approval" or "Admin channel ids for request", this works exactly as you expect for hidden and non hidden requests
• If you have something in the "Admin user ids for approvals", it will show a message saying you can add an emoji to approve the request for non hidden requests, but hidden ones don't have this.
• If you have something in "Admin channel ids for request" but not something in "Admin user ids for approvals" then the message will be sent to that channel as expected, but no one can approve/decline the request. I think it might be wise to have a warning on the webpage if this happens as it contains all the info it needs to know this would happen.
• "Admin user ids for approvals" is great, but you would have to put in every users id, if this is a team of users, that's a lot of users.... would it be a better idea for a Discord role? That way the admins can setup a role for approvals that also connect with the channel, plus it works better with roles for movie/tv/music requests as well.
• A weird quirk I noticed, if you have requests as non hidden, and it goes to a admin channel for approval, an admin can approve a request in both the request channel and the admin channel, maybe we make it aware to only do the admin channel in this case. Also, if you approve/decline the request in the request channel, it will update the message on the request and admin channel, however, if you approve/decline the request in the admin channel, it only updates the message on the admin channel.
• If you approve a request, you can decline it, this will then change Overseerr to decline, this can be repeated switching back and forth, but if the request is already approved, it will have pushed it to Radarr/Sonarr, so this doesn't do much apart from changing the message and the request status in Overseerr, but it might be in Radarr/Sonarr regardless... should we handle deleting the message or ignoring it after the first approval/decline?
• If a request is removed from Overseerr, but the message is still there, you can approve/decline it again, this causes a crash (soft one, doesn't take down the bot) in the bot with an error message, this is when calling the Overseerr API for a request ID that does not exist.... So....should we check for changes in the request messages and the status with Overseerr when the bot is running/starting? Then we could update the message or delete it as needed to keep it synced.
• If "Admin channel ids for request" setting is changed or cleared, you can still approve the request or not and the bot will react, I think we should ignore it.
• The bot ignores non admins, it also ignores all emoji's that aren't what its waiting for...but it will clear all emoji's when an approve or decline one is given. Should we clear them all the time?
• Does not react to replies to a request message, fair enough, I don't know if we can stop users from doing that? Outside of scope. :P
• Can we make the emoji's as a button or emoji already done by the bot itself? This way its quicker to click the button instead of finding it in your emoji's
• We could make the emoji's any emoji and use the defaults otherwise, but this isn't too important. Just a nice to have for people, without changing the JSON files. Oh, that's static in the code... Ok, future thing.
• Not sure what the "Send all requests to admin channel(s), not only pending ones." does..... had a request in Overseerr outside the bot, when it was off, didn't add a message on startup...removed messages didn't get re-added, not sure.
• If you approve/decline a request while the bot is off line, it does not know about it on startup. So, can we make a trigger to check past messages? Along with updating them, check their status, might be a next feature thing.

I DO NOT expect you to have an answer for everything here (unless you want to), I also DO NOT expect you to add any new code for these (unless you want to). These are just notes one when I have found to improve things. I think a couple of the nice to have things and this is pretty much ready then the other things can we handled in time at other stages.
Have you got any thoughts or ideas you would like to add?

[thomst08]

Hey @tacoroumen,

I've had more of a think, this is what I've come up with.
Maybe we should focus on these idea's for the moment:

• I think changing the admin approval Id from User Id's to role Ids is a good idea.
• Lets ignore messages once a response is given, I don't thing it is be a good idea to allow flip-flopping on the request, it might be a bit misleading, especially if it goes through the first time and it was not meant to.
  • Side note to this, might be wise to check the request status from Overseerr before changing the request status, do we want to accidentally change a request?
• It would be really cool if we could check changes to the messages when the bot is off line, but I do not know if this is doable. Might have to ignore this if we cannot.
  • If we can detect the messages from above, while checking the statuses, check Overseerr to see if they have been manually approved, then update the messages.
• I think it would be very wise to have a message in the admin panel to indicate if something is a miss, e.g., if approvals is setup, but if the messages are hidden, or if there is no admin approval roles as no one can approve requests, just a little warning, but not a stopping form it happening (or maybe we should?). I think these options should be in their own section, I was thinking behind a tick box, but I don't think that is necessary.
• We might want to double check for request messages that are shown, keep the status of the request "in sync" with the admin message if there is one, but this depends on if it can be found.

Notes: (nice to have, but ignore them for now)

• Removing a message when a request fails with Overseerr might be over kill, if Overseerr is down or has an issue it might remove a request that isn't really resolved yet. We could update the message to have a "failed" status in it, but I think a silent fail is enough with a message on console logs.
• Emoji's on the message/buttons is a nice to have, but can wait if too complex to add, lets ignore this (unless its easy)
• Removing all emoji's is nice to have, but kind of just nice, not needed. Lets ignore this less its easy.
• Custom emoji's is nice, lets ignore this completely, but leave the door open to make this changeable in the future.

What are your thoughts? Am I overthinking things? Is this adding too much complexity?

[tacoroumen]

It would be really cool if we could check changes to the messages when the bot is off line, but I do not know if this is doable. Might have to ignore this if we cannot.

• If we can detect the messages from above, while checking the statuses, check Overseerr to see if they have been manually approved, then update the messages.

I dont think this would be possible but there might be a way to fetch when the bot starts all replies to messages that it hasnt processed yet not entirely sure about this

• I think it would be very wise to have a message in the admin panel to indicate if something is a miss, e.g., if approvals is setup, but if the messages are hidden, or if there is no admin approval roles as no one can approve requests, just a little warning, but not a stopping form it happening (or maybe we should?). I think these options should be in their own section, I was thinking behind a tick box, but I don't think that is necessary.

you mean in the UI right? then yeah seems like a good idea

• We might want to double check for request messages that are shown, keep the status of the request "in sync" with the admin message if there is one, but this depends on if it can be found.

you mean if you aprove in the request section it also updates in admin and the other way around or?

• I think changing the admin approval Id from User Id's to role Ids is a good idea.

yeah seems a good idea pretty easy to also implement

Lets ignore messages once a response is given, I don't thing it is be a good idea to allow flip-flopping on the request, it might be a bit misleading, especially if it goes through the first time and it was not meant to.

• Side note to this, might be wise to check the request status from Overseerr before changing the request status, do we want to accidentally change a request?

Seems like good idea

[thomst08]

It would be really cool if we could check changes to the messages when the bot is off line, but I do not know if this is doable. Might have to ignore this if we cannot.

• If we can detect the messages from above, while checking the statuses, check Overseerr to see if they have been manually approved, then update the messages.

I dont think this would be possible but there might be a way to fetch when the bot starts all replies to messages that it hasnt processed yet not entirely sure about this

I was thinking if when a message is made, we might be able to store a unique Id for that message, and the request Id, if it is possible, then we could use that maybe to recall the message for checks/status updates, we could also check back on requests in Overseerr as well without querying through all of them, we have something to track each thing. This is just a thought, but you are right, I do not know if we can. If we can't, then that's OK, will just have to deal with things as they happen. :)

• We might want to double check for request messages that are shown, keep the status of the request "in sync" with the admin message if there is one, but this depends on if it can be found.

you mean if you aprove in the request section it also updates in admin and the other way around or?

I guess this comes back to what I mentioned above here, if we can sync the message on startup with Overseerr, or say, if the user manually changes the request and approves it on Overseerr, then, later, someone declines the message, the bot will just change the status on Overseerr, so, maybe we check to see if it has been changed on Overseerr first, and handle the request based on that, if its already answered, don't change the status, and change the message to indicate that happened.

I think that gives as a target to hit! :)
You have done an awesome job so far, and this helps out a lot. If you want to do any of this, you are welcome to, but I wont be offended if you want to work on something else, I don't want you to think I'm nit picking on anything here, you have done awesome!
I will look into some of this when I have time and pull it in when everything's ready. :)