tags: Product --- # Playlist CRUD ## use cases/edge cases to test - Doubling - somehow adding a boost to a dao that already has it (SHOULD BE FIXED) - Vanilla minion playlist vs. Vanilla minion classics. - add an old id field to dev suite - Adding a minion that has a playlist to a dao that already has that type (SHOULD BE BLOCKED NOW) ## data structure trees or keys - Possible option, Keys Only: Biggest barrier is playlists, which require customized data. It is possible to 'record' changes to playlists, and render out the results. This might help with the change log that we would need to build anyways. However this is not simple and would have it's own set of challenges. On the bright side, we could only use keys for everything. This would cut down on storage and help keep everything up to date. - Another option: Still use keys. Do not allow users to edit boost playlists. Boost playlists are always rendered from boost data in metadata.boosts. User can still edit favourites or custom playlists. Not simple either. - A path forward could be to disable editing entirely at first. Would allow us to move to keys only and give us time to figure out how to properly track editing/adding/deleting for favs and custom playlists. ## backfill todo 1. create playlists from boosts - give daos with minions the dev suite for payroll and minion simple forms [SHOULD BE FIXED] 2. Update old boostKey to new - can we have booth for now and eventually switch the keys and update the FE? 2. convert customTheme from a boost into general metadata. Enable by default in settings. - add field - customThemeConfig - pull all active boosts - update dao record for each with the data - add as seconds field in dat meta - rerunable job at anytime - front end: - link next to (or in) edit metadata - flip the switch to new field in the front end ## Go to launch - Discuss system for handling arbitray callbacks for API calls (similar to TX, to be used in FormBuilder) - I have an idea for a TX submit style system for doing arbitrary API calls (including metadata) would like to discuss. Might smooth some of the painpoints around non-minion boosts. We could also use this for DAOconfig/settings style calls. - Build form disable - jord (Done) - settings page links (Done) - update MINION_NETWORKS in minions.js - DONE - hide neapolitan for now - nifty is on all but rinkeby - double check - hide uberhaus - shouldn't need this in the minion summoner - test test test - need to retest the vanilla and nifty erc20/721 and 1155 forms from the vault section - share categorization and playlist organization with team - some current boosts are not showing due to having the old ID. i didn't change those in the database yet because it would mess with the production app. so i'm trying to figure out a decent way to handle that on the back end since it looks like the front end only looks for the new IDs. i might be able to duplicate them - but that'll mess with the playlistbackfill we need to run again before final deployment... I'll figure something out. - still need to bring the custom theme form up so it's accesible from the setting page (not in a boost) and adjust all the theme stuff look write to a new field and look at a new field - SAM in progress - migrate configs into a separate repo - TBD - means these are now async - define a flow for testing/cr - github action to sync one repo to another?