When pulling the username from Plex, it's using the wrong field.

[roadkingvrod]

When I run the api call on Overseer (/api/v1/request) I see that the correct user name is shown in the field 'plexUsername', however immediatelly following it shows that "username":null which means that when I set up a rule to delete a movie watched by the user that requested it, it fails since null doesn't match the original username.

This is confirmed by testing the rule and it always returns null in the rule.

[jorenn92]

The behavior depends on the 'userType' value of the media item. When the usertType is 2, Overseerr uses the 'username' field. If it's anything else, Overseerr uses the 'plexUsername' field. This value needs to be transformed to the correct Plex username.

When userType is not 2, Maintainerr will search through all the users in your Plex instance for a matching username. If no match is found, it will return null.

Could you verify that the value in plexUsername exactly matches one of your users usernames? Is there anything unusual about the user, such as a different display name?

[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 https://github.com/jorenn92/Maintainerr/pull/1231. If anyone could try it out with the main/develop image, that would be a great help!

[roadkingvrod]

For the admin account I can confirm that it is using plexUsername. I'll try with a non admin account.

[jorenn92]

For the admin account I can confirm that it is using plexUsername. I'll try with a non admin account.

Are you able to try the "develop" image tag from Docker Hub or the "main" tag from GitHub? It would be helpful if you could confirm whether the fix is sufficient.

[roadkingvrod]

yes, i can do that tag. trying now.

[roadkingvrod]

I'm running:

Maintainerr Develop b6151c5

And the username is still pulling null. output of "Test Rule" below:

• plexId: 349024 result: false sectionResults:
  • id: 0 result: false ruleResults:
    • operator: OR action: equals firstValueName: Overseerr - Requested by user (Plex or local username) firstValue:
      • struchot secondValueName: text secondValue: xxxx result: true
    • operator: AND action: contains firstValueName: Plex - [list] Viewed by (username) firstValue: [] secondValueName: Overseerr - Requested by user (Plex or local username) secondValue:
      • xxxx result: false

[jorenn92]

It is successfully populating the ‘Overseerr - Requested by’ values this time, is it not?

[roadkingvrod]

It was before. What's always been missing is the firstValeuName: Plex 0 {list} Viewed by (username).
firstValue: []

The firstValue is always null so it never matches the Overseer Requested by. The Overseer Requested by was populated in the main release as well. I'm happy to post the test results side by side if that helps.

[roadkingvrod]

Just to provide as much info as possible:

I've created a simple rule saying if a specific user requests via Overseer and then watches via Plex, to put it in the collection:

mediaType: MOVIES rules:

• "0":

  • firstValue: Overseerr.addUser action: EQUALS customValue: type: text value: xxxx

  • operator: AND firstValue: Plex.seenBy action: CONTAINS lastValue: Overseerr.addUser

    In running it via the developer version, these are the test results from a movie that should match that filter:

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

    • operator: AND action: contains firstValueName: Plex - [list] Viewed by (username) firstValue: [] secondValueName: Overseerr - Requested by user (Plex or local username) secondValue:

      • xxxx result: false

      When I run it on the main release:

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

    • operator: AND action: contains firstValueName: Plex - [list] Viewed by (username) firstValue: [] secondValueName: Overseerr - Requested by user (Plex or local username) secondValue:

      • xxxx result: false

      Same results.

      I'm not a coding expert whatsoever, but it seems that we're still pulling username, not plexUsername (though display name seems to be new).

      In running the overseer api call, i do see the following:

      "modifiedBy": { "permissions": 2, "id": 1, "email": "xxxx@gmail.com", "plexUsername": "xxxx", "username": null, "recoveryLinkExpirationDate": null, "userType": 1, "plexId": 43047, "avatar": "https://plex.tv/users/1c282b97c2ad6d5e/avatar?c=1724646725", "movieQuotaLimit": null, "movieQuotaDays": null, "tvQuotaLimit": null, "tvQuotaDays": null, "createdAt": "2024-06-24T18:37:34.000Z", "updatedAt": "2024-08-26T04:32:06.000Z", "requestCount": 76, "displayName": "xxxx"

[jorenn92]

Oh, I see—I misunderstood your issue. The fix I applied was for the "Overseerr - requested by" rule, as more users were encountering problems with it.

Regarding the "Plex - viewed by" rule, it relies on data from the Plex item's watch history. Have you confirmed that the watch history is populated? You can check this in Plex Web.

Are you testing this with an item that has actually been watched? Keep in mind that this rule won't work if the item was simply marked as watched manually—this is a limitation on Plex's end, and unfortunately, there's nothing I can do to change that.

[roadkingvrod]

I didn't know about the limitation of watched manually. I'll try with another file that I can say for sure was watched and get back to you.

[roadkingvrod]

It appears to work when the movie is actually watched, vs marked read. Thanks for your help!

[jorenn92]

It appears to work when the movie is actually watched, vs marked read. Thanks for your help!

No problem! I’m glad we figured it out.