allow sync direction to be set per user

[Splinter7914]

I have not tested this yet. Just wanted to see if the approach looked feasible. This would implement #150.

User would define an optional env var: USER_SERVER_SYNC_MAPPING=['jellyfin']

This essentially says which servers do we want to sync to.

sync_users method then returns an updated list of users we want to sync based on this variables.

If this approach looks good I will work on validating it and documenting it.

Current approach is not ideal as ideally if we are not going to sync from Plex to Jellyfin then we can avoid collecting the matched data for that user as well. But I wanted to avoid too much change.

In future if we plan on re writing this then I would suggest a more complex setting for users config where we also capture the name and servers to sync etc. Something like

{

  "user": {
    "name": "xyz",
    "sync": {
      "plex": ["jellyfin", "emby", "jellyfin2"]
    }
  },
  "servers": {
    "plex:": {
      "token": "xx",
      "url": "xx",
      "type": "plex"
    },
    "jellyfin:": {
      "token": "xx",
      "url": "xx",
      "type": "jellyfin"
    },
    "emby:": {
      "token": "xx",
      "url": "xx",
      "type": "emby"
    },
    "jellyfin2:": {
      "token": "xx",
      "url": "xx",
      "type": "jellyfin"
    }
  }
 
}

Something like above could allow one to explicitly decide what servers to sync and in what direction for each user. This way one could any number and types of servers and be able to control what to sync to as well.

[Splinter7914]

hmm not working as expected. Need to do a deeper dive into the code.

[luigi311]

I am fine with creating a new structure for a feature like this as long as we dont break the old one. We can create a new env like advanced_servers or something that takes a json structure like you pointed to

{
    "Plex": {
        "token": "xx",
        "url": "xx",
        "type": "plex",
        "users": {
            "1stuser": ["*"] # Wildcard so it syncs to all servers
            "2nduser": ["Jelly"] # 2nduser only syncs to Jelly
         }
    },
    "Jelly": {
        "token": "xx",
        "url": "xx",
        "type": "jellyfin",
        "users": {
            "*": ["*"] # Wildcard so it syncs all users to all servers if the user exists
        }
    },
    "Plex2": {
        "token": "xx",
        "url": "xx",
        "type": "plex",
        "users": {
            "2nduser": ["Plex"]
         }
    },
    "Emby": {
        "token": "xx",
        "url": "xx",
        "type": "plex",
        "users":{} # Empty so it doesnt sync outwards
    }
}

End result would be

1stuser will be synced between Plex and Jelly and then a one way from Plex to Plex2.
2nduser will be synced between Plex and Jelly and then one way from Plex2 to Plex.

The emby server is only a receiver so it will accept syncs going in but will not sync anything out so in this case Jelly will sync one way to Emby for all matching usernames.

What are your thoughts on something like that?

[Splinter7914]

So my suggestion on the more complex structure was only if there are future plans for a significant re write. If we want to remain backwards compatible that is doable. Something along the lines of:

• new code understands the new configuration object only.
• At startup we determine if new config object is present. If not we take existing env vars and dynamically create the expected config and pass that to the code to run.
• Eventually we would retire the old configs and ask users to migrate to the new object.

I was thinking of keeping sync settings separate from server so the user could define any direction. For example

{
    "sync": {
        "plex": [
            "emby"
        ],
        "Jelly": [
            "Plex2",
            "Plex"
        ]
    },
    "users": {
        "user1": {
            "sync": {
                "Jelly": [
                    "Plex2",
                    "Plex"
                ]
            },
            "plex": "my name in plex",
            "plex2": "my name in plex2",
        }
    },
    "servers": {
        "plex": {

        },
        "plex2": {
            
        },
        "emby": {
            
        },
        "jellyfin": {
            
        }
    }
}

So at the top level we could define the global sync options and then be able to override per user. The key name of the user could be the default name and we could also provide a different name for each server.

I feel this way the code itself could avoid checks like "should sync server2 to sever1 etc" and instead just read everything from the config and sync it as its determined by the config.

At this time i don't know how we currently manage users as user names could be different for each user in each of the systems. So in your suggestion of using * for user name would that mean user names in all the servers had to be be same?

Anyways my current changes are not working so I need to spend some time going through the code to see if I can figure out how I can get this to work with minimal change using the new env var :).

[luigi311]

Hmm i see, your structure would be better. On mine it would have to be the same usernames across all servers or it would have to use the user mapping but that would only be for a single mapping and some people want multiple user mappings like in #127. With your stucture they can map to different usernames per server. We should also make some of those parts of the structure optional so its still easy for people to setup something similar to the current structure where they want all matching users from plex to jellyfin.

i wonder if it would be worth making the user mapping a list so people can match across multiple accounts.
user1 syncs
user1 -> username1 and username 2

At some point it sounds like it would be needlessly complicated lol. We are probably better off without the list for now.

[luigi311]

Can you open a ticket requesting your structure as the configuration that way i can work on it later

[Splinter7914]

I agree on complicated, I was thinking how one would specify block and allow set of users, library mappings and it did seem to be getting too complicated lol.

The reason I prefer explicitly setting the username per server is because it would make the code easier to write. Briefly from what I have read we try to find the mapped user in the keys and the values to see if it exists etc.

So at a high level I think of what would make the code easier to write and then come up with the config :).

Logged #198 we could iterate over that. I will close this PR out as current code is not functional. Once I have it working I will send a PR or may be Ill just wait for #198 :)