Closed brine0m closed 1 week ago
I think there are two issues here, correct me if I'm wrong:
config.toml
The config file it's some kind of "low level" interface that allows anyone to mess with about everything that Wolf does without having to touch the code. It's an amazing tool for us when debugging issues and it's useful for some power user that want to achieve something that Wolf isn't supporting with the defaults.
It's not a small commitment to expose all those options in an admin web page, we should start with an API first but we've got plenty of other things going on at the same time; if anyone is willing to help I'll be happy to guide the effort in building this.
I mapped a couple devices to a single state folder today and I though an alias would be plenty useful. If when entering the pin I could also enter a device alias that's stored in the config.toml
that would already make remapping much easier. Or the alias is already used as the state folder name.
I see what you mean with adding an alias to a user, and we could easily add that to the pairing screen.
I'm not sure how you are planning on using that in the config file. Is this about mounting the same folder for N users?
Yeah the purpose was to have 1 user to many devices relationship and result in using the same state folder.
I agree that this could be added to the pairing screen. What probably needs to happen is to front the pairing screen with a user authentication screen. When pairing a device the session info could be used to delineate what profile the device would go against.
Ultimately this capability is probably a little more than just simple change as it would actually require a user management system to do it properly.
Superseeded by https://github.com/games-on-whales/wolf/issues/80
Today when a client is registered it will have its own app_state_data and the default action is to create a new profile under /etc/wolf for each session.
As a feature enhancement would be good to be able to goto an admin portal created multiple profiles and associate registered devices to that profiles so that app_state_data is shared across devices. This portal could also be a means to more easily serve the device pin page when trying to register the device.
While today is possible to just go into the config.toml and set the app_state_data to be the same for all clients you want this shared, was thinking this could be a better way to more easily set this up.