Overseerr - requested by user is null.

[kernelkaribou]

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

3. This will return results of any of my requests in the collection
4. Change to any other user, collection will be empty.
5. 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]

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.

[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?

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?

[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?

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.

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.

[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.

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.

[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.

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:

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

[davidebonavita]

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

[hernicus]

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

[jorenn92]

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!