app
app copied to clipboard
Festify
Co Admin / Host
Add authenticated user(s) as Co Admin/Host.
An authenticated user, which can be a Festify user, but also a user authenticated by Google/Facebook/Apple/OAuth. Can act like the host of the party.
Deleting songs from the queue is doable, but controlling Spotify is harder I guess..
Because the browser app of the Admin could not be reachable, (firewall.NAT etc), you could send Spotify app-commands to a db table (tblSpotifyActions) Use it like a queue, read by the app instance of admin, then execute the action; like [next song], [pause]. You'll have to add data like [current song], [server timestamp] to get this to work. And real Admin actions takes
It would be fairly easy to implement, because the playback state is already stored in Firebase. However, I don't know if there are many situations in which this feature would be needed. Could you provide some examples there? :)
When you host a party you don't want to be DJing all the time that is why you would use Festify in the first place.
By having some trusted guests help you keeping the playlist 'clean' you can focus on hosting / partying yourself. You don't want to give your Spotify credentials to someone for this.ergo..
As another example. Where I work, we usually open a festify session so everyone can input their own songs, but the problem is that we are not always at the office (working from home or something) and thus, not always available to play, pause and control the music.
It'd be really nice if we could transfer the admin privileges or add some co-admins for the whole company, maybe implementing some role control to avoid people from having full control in some cases (large companies). But this is REALLY necessary.
We use festify at the office, and we love it! But, sometimes, the admin doesn't want to use they're computer and wants to listen to their music instead, or simply can't manage the party It'd be awesome if we could co-host, trasnfer the admin role, or even create a party using the songs from a previous one, just so we don't lose the music we've already added
We're devs here, so, if you guys thinks it's a good first contribution, we'd gladly try and send a PR
We're devs here, so, if you guys thinks it's a good first contribution, we'd gladly try and send a PR
PR's are always welcome. :D
Awesome! We were taking a look at the code but we're really lost. Could you give us some lead on where to begin?
My biggest question is actually how we can see the users who joined the party and which of them have connected their spotify accounts and how we can get that data to add into some "admin list" array or something.
My biggest question is actually how we can see the users who joined the party and which of them have connected their spotify accounts and how we can get that data to add into some "admin list" array or something.
Currently this is not saved anywhere in the database. Joining a party is simply a matter of resolving the real party ID (the long one) in Firebase and writing votes to the relevant part in the DB. You'd have to write the list to Firebase somewhere. :)
It would probably help if you set up an instance of Festify for yourself. We have some basic instructions in the Readme that should help you. Currently this requires registering accounts with quite a lot of different services (Namely Firebase, Spotify (obviously), fanart.tv and all the OAuth providers. Sentry is optional, iirc), but it can be done ;)
Regarding the feature: I think it would be great if the co-admin functionality wouldn't require a Spotify account to be connected, but instead work with any type of connected OAuth account. Administrating a party doesn't require playback capabilities per-se, so Festify shouldn't mandate that. We already do account-merging based on email addresses (so that logging in with different OAuth providers "just works", as long as these accounts use the same email), so this shouldn't be a problem.
See https://github.com/Festify/app/blob/9e370b4fa1671f178c00b86cfbcd07ee0809af45/functions/lib/spotify-auth.ts#L190 and https://github.com/Festify/app/blob/develop/src/sagas/auth.ts for more info on auth. It is quite complicated. :D
Maybe a good first step (and a great base for future features that require more data about party guests) is to keep a list of users that voted on a specific party. Using that list, it would be possible to grant specific guests co-admin rights. In the future, that data could be used to ban specific users or to display user-specific statistics. We already have a user_parties that contains information about which parties a user has opened.
Creating a new key that contains reverse information shouldn't be too hard. It would be necessary to generate pseudonyms for anonymous guests though (like in Google Docs) so they can be identified better.