- In the "Screening Rooms" tab of the admin section of the Catalogue, there exists a dropdown to filter which type(s) of screening rooms are shown.
- Drop-down options are: All, Full, Basic
- If All is selected, then each screening room should have a label above the name of the screening room to indicate the type of screening room: Basic or Full
- In the "Screening Rooms" tab of the admin section of the Catalogue, the search feature interacts with this screening room type drop-down menu (so I can search and filter simultaneously).
- For basic screening rooms, admin users can do the following
- Edit an existing screening room
- Edit the name of the screening room
- Edit the carousel order of videos in the screening room
- Remove videos from the screening room
- Add/remove users to/from an existing screening room (see CC-147 TO DO for requirements)
- Duplicating an existing screening room (the duplication will also be a "Basic" screening room)
- Deleting an existing screening room
The feature matches the spec (see attached mock below, and InVision Prototype here: https://projects.invisionapp.com/d/#/console/10463333/245526839/preview)
turn and face the strange - David Bowie
Need to write a migration to define a types field for a Collection model.
Update the CollectionsController#index route to handle search like we've done with the Users#index route, which includes coming up with a route param to pass for filtering on Collection type.
First we need to add /src/app/views/partials/screening-room-table.hbs filtering markup to a new partial which we will call within /src/app/views/partials/screening-room-list.hbs. An example of how this should be reformatted would be /src/app/views/partials/user-dashboard.hbs, where a filters are called in a partial on line 19. We also need to create a unique id for the div element that will be wrapped around this filter partial, ( We'll use this id later for the rendering of the filtering system within src/javascripts/screening-room.js)
Speaking of which...
Within /src/javascripts/screening-room.js, we will need to separate out the collectionsParser(L38-L56) handling within the resultModalRender(L19-L57) function. We are doing this because we need to move this searching function outside of the main redux store subscription function, this is a similar path I've taken with the user search.
We will need to declare our id we set in the /src/app/views/partials/user-dashboard.hbs filters partials refactor. An example of how this is done can be found on L20-L24 of /src/javascripts/screening-room.js. This is done so we can use the templateLoader to render the handlebar templates inside a mounted DOM element. We will use it in the new function that includes the collectionsParser code from the previous step.
Inside of that new function, we will declare a new templateLoader.render which will be passed in with our filters partial. a good example of what we are trying to achieve here can be found in /src/javascripts/usermanagement.js:L41-L61 in the resultRender function, basically we take data from both the redux store and the results from the collectionsParser's request and pass them into the templateLoader.render callbacks, where the compiledTemplates will replace the html of the id's we set to wrap around the partials, like we declared at the beginning of this task.
This should give us a scenario when if we were to call this function after updating the redux store, we would be able to have both the screening room table update and the filters section update.
So event handling... Currently in /src/javascripts/screening-room.js:L65-L73 aka the key up handling and /src/javascripts/screening-room.js:L75-L85 and change of input filter boxes, we have an event fires, then we dispatch to the screeningRoomStore a redux action, which is automatically handled by the screeningRoomStore.subscribe(/src/javascripts/screening-room.js:L59) callback, where then we call our handlebars rendering to handle the updated data.
We need to slightly decouple this process, as research with the users-dashboard search stuff has taught me, the subscription of this store can be costly to the user search experience. Instead we are going to preserve the dispatch to the screeningRoomStore, but as we have done in the previous step, call that new function that makes the collectionsParser call after the dispatch has been made. See /src/javascripts/usermanagement.js:L76-L88 to get an idea of what this looks like for a users search.
After this is done, we need to create a new action within the redux reducer to storing the collection type, that reducer is found in /src/app/reducers/screening-room-reducer.js. We should also update the default reducer here with a value for the collection filter type. This will be a string value in the param passed CollectionsController#index in media-api.
We also need to now modify our collectionsParser to use that collection type as a parameter when requesting. The actual parser itself lives in /src/adapters/apiparser.js:L145-L156, we should add a new param in here for collection type and probably set a default for it, if it hasn't been passed.
From here we test to see where we're at, hopefully the desired result will be that you are able to utilize the filter, make searches and have handlebars re-render results into areas defined on the page. Assuming not much else has changed in the previous handling of the other functionality, we should be able to also complete the other requirements for this.