-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Epic 2: Collections #1084
Comments
@jmakowski1123 @bradenmacdonald Do we have a story for deleting collections? I don't see it in any of the frontend tickets yet. Also asking because openedx/modular-learning#225 introduced an |
I'm not sure. @jmakowski1123 or perhaps @lizc577 or @sdaitzman can answer. |
@jmakowski1123 @lizc577 @sdaitzman I've created an issue for this question, please see openedx/modular-learning#231 @bradenmacdonald could you please add that issue to this ticket? I don't have access to edit this. |
Hi @jmakowski1123 CC @bradenmacdonald -- is it possible for me to get edit access to issues for this epic? I've made a few notes in comments, but it would be helpful if I could edit them directly. |
Searching/filtering/sorting a list of Collections@jmakowski1123 @bradenmacdonald CC @lizc577 @sdaitzman @marcotuts I can't find any frontend tickets in this epic to handle searching/filtering/sorting the Collections lists shown on the Home page and the Collections tab. Note that this is different from sorting/filtering the Collection's Components, which will be done when viewing a single Collection, and is handled by these tickets:
If we need to be able to do this, we'll need some frontend tickets. Option 1: Index only the Collection metadata This option is simpler, and ignores the Collection Components' metadata, i.e
The backend work to support this is already being handled by openedx/modular-learning#229, but we need to add some simple frontend tickets. Option 2: Include the Collection Components metadata in the indexed Collection Whenever a Component is added/removed from a Collection, the search metadata for the Collection is updated to reflect this change. Since there can be many Components in a Collection, this could result in very large indexes and performance issues. But we gain the following features:
The frontend work is still straightforward with Option 2. But it's a more difficult lift for the backend, and requires planning for performance and search data usability, and to guard against race conditions. |
I think that will be covered by #1102 . Maybe we can explicitly add it to the scope, but I think that since we've already implemented the keywords search and the sorting and filtering for "components" and "home", I think it should mostly be already implemented on the components tab. Re your other questions, I feel pretty clearly that we should go for Option 1 for the MVP at least; I think it's not only simpler, but it also makes more sense to me. However, there is a simple and clear product question that affects either option: when we modify a component that's part of one or more collection(s), do we consider that collection(s) to have been modified too? Should both the component and the collection(s) then show up as "Recently Modified"? |
OK: answer to the above from Slack seems to be that modifying a component should modify the collection(s) too. |
Noted, will do ^ as part of openedx/modular-learning#227 |
@jmakowski1123 @bradenmacdonald Some additional tasks to consider adding to the scope here:
|
Thanks @pomegranited - I put those into the description now. But I'll let @jmakowski1123 decide what's in scope. |
Added to original scope:
Potential missed requirements (are these in scope for MVP?)
The text was updated successfully, but these errors were encountered: