Maintainerr icon indicating copy to clipboard operation
Maintainerr copied to clipboard

Overseerr - requested by user is null.

Open kernelkaribou opened this issue 1 year ago • 8 comments

Describe the bug When using rules that look at the overseer requested by user, it will return null for any requests that are not mine (owner). This looks to be an old closed issue, #995 that was suggested fixed in #1070. Hoping not user error.

To Reproduce Steps to reproduce the behavior:

  1. Create Rule that looks for a specific user.
mediaType: MOVIES
rules:
  - "0":
      - firstValue: Overseerr.addUser
        action: EQUALS
        customValue:
          type: text
          value: OWNER
  1. This will return results of any of my requests in the collection
  2. Change to any other user, collection will be empty.
  3. Doing test media shows null for all media not requested by owner but, however populated if requested by owner.

Broken:

- plexId: 47296
  result: false
  sectionResults:
    - id: 0
      result: false
      ruleResults:
        - operator: OR
          action: equals
          firstValueName: Overseerr - Requested by user (Plex or local username)
          firstValue:
            - null
          secondValueName: text
          secondValue: OWNER
          result: false

Working:

- plexId: 47315
  result: true
  sectionResults:
    - id: 0
      result: true
      ruleResults:
        - operator: OR
          action: equals
          firstValueName: Overseerr - Requested by user (Plex or local username)
          firstValue:
            - OWNER
          secondValueName: text
          secondValue: OWNER
          result: true

Expected behavior Media would show the user who requested it for comparison.

Device (please complete the following information):

  • OS: Docker
  • Version 2.0.4
  • Overseerr Version: 1.33.2

Additional context Even using the community rules, like the "Seen by Overseer requester & older than 30 days OR not watched by requester and older than 90 days" will populate only with movies requested by myself and none others (can guarantee there are 'eligible' ones)

kernelkaribou avatar Jul 10 '24 02:07 kernelkaribou

Enabled debug on the container and only new information that was visible when executing the rule was.

[maintainerr] | 10/07/2024 07:04:06  [DEBUG] [RulesService] Cannot read properties of undefined (reading 'props')

Not sure if relevant.

kernelkaribou avatar Jul 10 '24 12:07 kernelkaribou

Hmm, this is an odd one, especially since it works for your own user. Just to be sure, Maintainerr is authenticated with the account that also owns the Plex server, right?

What kind of users are you using within Plex? Normal users, or local users? And how are your users setup within Overseerr? Are they also using Plex oauth, or are you utilizing local sign in?

jorenn92 avatar Jul 16 '24 13:07 jorenn92

Hmm, this is an odd one, especially since it works for your own user. Just to be sure, Maintainerr is authenticated with the account that also owns the Plex server, right?

Correct.

What kind of users are you using within Plex? Normal users, or local users?

While I do have a handful of family members, it is a mixture of both local and true Plex users. The ones that I am concerned about are added Plex users.

And how are your users setup within Overseerr? Are they also using Plex oauth, or are you utilizing local sign in?

Overseer users are setup as part of Plex.

image

They are using Plex oauth for authentication.

As a side note in answering these questions and maybe you can answer this. These users are NOT friends in Plex. I had simply added them to have access to my Plex server. I had originally had them as friends but removed that. Would that have any impact on this? I am not sure how but could be one caveat that may not be immediately visible. They clearly have access to make requests on overseerr, be visible to overseerr as to who made the request and Plex showing the watch activity, not sure the disconnect otherwise. Thanks.

kernelkaribou avatar Jul 18 '24 12:07 kernelkaribou

You don't need to be friends with someone for Maintainerr to fetch them. All users known by the server should be fetchable. It does matter for stuff like watchlists. You'll only be able to fetch the list if you've got access to it. So if the user has this set to 'friends only', you can't fetch it.

Additionally, it shouldn't matter if a user is locally added.

Could you try running the image with the tag 'ghcr.io/jorenn92/maintainerr:main' and enable debug logging? This will, hopefully, provide some extra helpful logs.

jorenn92 avatar Jul 22 '24 09:07 jorenn92

You don't need to be friends with someone for Maintainerr to fetch them. All users known by the server should be fetchable. It does matter for stuff like watchlists. You'll only be able to fetch the list if you've got access to it. So if the user has this set to 'friends only', you can't fetch it.

Makes sense, was just a thought but wasn't convinced.

Could you try running the image with the tag 'ghcr.io/jorenn92/maintainerr:main' and enable debug logging? This will, hopefully, provide some extra helpful logs.

[maintainerr] | 23/07/2024 18:38:07  [INFO] [RuleExecutorService] Executing rules for 'Test'
[maintainerr] | 23/07/2024 18:38:07  [WARN] [RulesService] Couldn't determine if rulegroup with id 4 requires a cache reset
[maintainerr] | 23/07/2024 18:38:07  [DEBUG] [RulesService] Cannot read properties of undefined (reading 'props')
[maintainerr] | 23/07/2024 18:38:07  [INFO] [RuleExecutorService] Execution of rules for 'Test' done.

Seems to make no difference. I am testing a movie that I know has been watched and I know the person who watched it was the requester on overseer.

  sectionResults:
    - id: 0
      result: false
      ruleResults:
        - operator: OR
          action: contains
          firstValueName: Plex - [list] Viewed by (username)
          firstValue:
            - ri*********30
          secondValueName: Overseerr - Requested by user (Plex or local username)
          secondValue:
            - null
          result: false

Overseerr: image

Not sure where to go from here but appreciate the help.

kernelkaribou avatar Jul 23 '24 23:07 kernelkaribou

Hello, I have the same issues, as per my comment in another open issue: https://github.com/jorenn92/Maintainerr/issues/1188#issuecomment-2295870706

davidebonavita avatar Aug 19 '24 07:08 davidebonavita

For what it's worth, I'm seeing the same issue as well.

hernicus avatar Aug 20 '24 19:08 hernicus

There was a mismatch when a Plex user used a 'display name'. I don't know when this changed, since it used to work with display names, but this should be handled in PR #1231. If anyone could try it out with the main/develop image, that would be a great help!

jorenn92 avatar Aug 26 '24 09:08 jorenn92

using version 2.1.2 (docker) and overseer user reuqester is null for all items (it used to work before...)

  • plexId: 19195 result: false sectionResults:
    • id: 0 result: false ruleResults:
      • operator: OR action: contains_partial firstValueName: Plex - [list] Users that watch the show/season/episode firstValue:
        • "the correct user from plex" secondValueName: Overseerr - Requested by user (Plex or local username) secondValue: null result: false

same in latest and develop

imrman avatar Oct 08 '24 17:10 imrman

i had the same problem in v2.8.0 so i rebuild the container and deleted all saved data. After that 2.8.0 suddenly shows correct data again.

Hobbabobba avatar Jan 28 '25 17:01 Hobbabobba

Revisiting this. I am running 2.12.0 stable and the issue seems to not exist anymore. I will close as I am showing it resolved.

kernelkaribou avatar Mar 23 '25 22:03 kernelkaribou