Repository: oppia/oppia

Issue:
Consolidate CollectionBackendApiService and WritableCollectionBackendApiService
There are two services used for communicating collection objects between the backend and frontend:
- `CollectionBackendApiService`, which is used to retrieve, and cache, collections in the frontend
- `WritableCollectionBackendApiService`, which allows saving collections to the backend

These were setup as an experiment to try and minimize the duplication of getters for collection data. However, this approach is not very RESTful and it's a bit confusing. Instead, there should be two backend API services based on intended functionality:
- `ReadOnlyCollectionBackendApiService`, this only exposes GET functionality to the `collection_viewer` backend controller
- `EditableCollectionBackendApiService`, this exposes both GET and PUT functionality to the `collection_editor` backend controller

Essentially, the following needs to happen:
- `CollectionBackendApiService` needs to be renamed to `ReadOnlyCollectionBackendApiService`
- `WritableCollectionBackendApiService` needs to be renamed to `EditableCollectionBackendApiService`
- `WritableCollectionBackendApiService` needs to have getter functionality added, similar to the current `CollectionBackendApiService` except it will be calling into `collection_editor` instead of `collection_learner`
- GET support needs to be added to the [backend collection data controller](https://github.com/oppia/oppia/blob/8eab07b7b2dd6be4bc32b28a2eaa942489ea911d/core/controllers/collection_editor.py#L130) (and it should probably be renamed), similar to the [CollectionDataHandler](https://github.com/oppia/oppia/blob/8eab07b7b2dd6be4bc32b28a2eaa942489ea911d/core/controllers/collection_viewer.py#L82) in the collection viewer backend controller, except the leaner dict isn't needed by the backend editor. `collection_services.get_learner_collection_dict_by_id` may need to be refactored slightly. We may need 2 functions in `collection_services`, one for representing the core elements of the collection and another (`get_learner_collection_dict_by_id`) which adds the playthrough information to that core representation for use by the viewer.
- Tests need to be added for the new `EditableCollectionBackendApiService`
- Tests may need to be added/updated for `collection_editor`'s changed backend controller

Add a fixed footer to the exploration learner view which highlights the contributors and sharing buttons.
We want to make it easy for students to see who created an exploration, and to share the exploration with others. This information actually exists in the learner view, and can be accessed by clicking the small "i" button at the top of the page in the navbar. However, this isn't particularly discoverable, so we would like to show this information in a fixed footer at the bottom of the page instead.

The following mock (thanks to @markhalpin) shows the sort of thing that should be implemented:

![learner-view-mock](https://cloud.githubusercontent.com/assets/10575562/18823961/7c813cb4-8373-11e6-84db-d4e29651ed48.png)

Some notes:
- For the purposes of this issue, **please ignore** the parts of the mock besides the footer.
- The apple at the bottom left should be replaced with the authors' profile pictures.
- Clicking on any profile picture should go to that author's profile page.
- "Author profile" should be "Author profiles" if the exploration has more than one author.
- The share buttons on the bottom right are the same as those that you see when clicking on the "i" button in the navbar.



Discussion:
@BenHenning I would like to work on this. Do I have to work on collection-editor branch or proceed with a new branch?

@umeshksingla -- I believe @BenHenning will be merging collection-editor into develop on Wednesday. So, if you can do this by Wednesday, I suggest doing a PR into collection-editor; otherwise, it might be better to wait until after Wednesday and then start a PR into develop. Please let us know which you prefer! 

@BenHenning It may take me time to finish this one. I can't really say that it'll be done by Wed. So please merge collection-editor into develop and then I'll start working on it. Meanwhile can you help in finding some similar issue?

@BenHenning  Hey, I have submitted a PR for my earlier task. If it's okay with @umeshksingla I wanted to work on this. Can someone assign me?

Hi @gvishal -- see my [earlier response](https://github.com/oppia/oppia/issues/1556#issuecomment-193228852) to @umeshksingla. Basically, if you can do a full PR into the collection-editor branch by Wednesday, then feel free to start now, but otherwise it's probably better to wait until @BenHenning has merged collection-editor into develop.

@gvishal @umeshksingla A quick update: collection-editor has now been merged into develop, so you can now work on this issue in develop. Which of you would like to take it?

@seanlip I am almost done writing the one-off job and can surely take this up!

Sounds good, thanks! I've assigned you.

(NB: @BenHenning will be your point of contact for this review.)

Excellent, that's great to hear @gvishal! If you have any questions moving forward, feel free to reply to this issue. We can schedule some time to meet if there are any major concepts or concerns which need to be discussed. Thanks!

Hey @BenHenning, I have my mid-terms this week, so I won't be able to put in a sufficient amount of time working on it. Please feel free to assign someone else or, I can pick it up in 2-3 days, if that's fine.

Hi @gvishal,

Given my own late reply on this issue, don't worry about not getting to
this issue this week. If you're still interested in working on it, then I
think keeping it assigned to you still makes sense. Please let me know if
that changes at all.

Thanks!

On Sun, Mar 13, 2016 at 6:58 AM, Vishal Gupta notifications@github.com
wrote:

> Hey @BenHenning https://github.com/BenHenning, I have my mid-terms this
> week, so I won't be able to put in a sufficient amount of time working on
> it. Please feel free to assign someone else or I can pick it up in 2-3
> days, if that's fine.
> 
> —
> Reply to this email directly or view it on GitHub
> https://github.com/oppia/oppia/issues/1556#issuecomment-195961449.

@gvishal -- are you still planning to work on this? If so, please let me know, and I'll reassign you. Thanks!

Hi @gvishal -- would you still be interested in taking a look at this at some point?

@seanlip -- Yes, I'd be able to work on it next week! A little preoccupied right now. If necessary, I could take it up earlier?

Ah, sorry, I dropped this -- catching up on email now after the release :-)

Yep, it would be great to sort this out. I've assigned you; thanks!

Unassigning @gvishal so that he can ramp up on his GSoC project. :)

Hi @joshuacano -- would you still be interested in looking into this?

Sure thing, I'll give it a shot.

Hi @wxyxinyu I should be able to get to this over the weekend, sorry for the delay.

Just an update, I'm working my way through the issue. I have added a few tests for EditableCollectionBackendApiService, still need to add other features requested. 

That sounds great, thanks for the update @joshuacano! 

Hi @joshuacano , how has this been going?

Have been on hold for the last few weeks helping some students finalize their final projects. School has finished and am getting started again today and should have tests written and finalized by the end of the week. 

Joshua Cano

> On Aug 20, 2016, at 11:58, Jacob Davis notifications@github.com wrote:
> 
> Hi @joshuacano , how has this been going?
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.

Sounds good -- thanks @joshuacano! 

I'm gonna need some help looking at this? Can someone or @BenHenning take a look at my changes and help me parse out what's left to do?

https://github.com/joshuacano/oppia/commit/111673a34eaf5fcce3108ed14035d0ab2732866e

I believe I have done the following:
1. CollectionBackendApiService needs to be renamed to ReadOnlyCollectionBackendApiService
2. WritableCollectionBackendApiService needs to be renamed to EditableCollectionBackendApiService
3. WritableCollectionBackendApiService needs to have getter functionality added, similar to the current CollectionBackendApiService except it will be calling into collection_editor instead of collection_learner
4. Tests need to be added for the new EditableCollectionBackendApiService

Still TODO (This is where I will need some help): 
1. GET support needs to be added to the backend collection data controller (and it should probably be renamed), similar to the CollectionDataHandler in the collection viewer backend controller, except the leaner dict isn't needed by the backend editor. collection_services.get_learner_collection_dict_by_id may need to be refactored slightly. We may need 2 functions in collection_services, one for representing the core elements of the collection and another (get_learner_collection_dict_by_id) which adds the playthrough information to that core representation for use by the viewer.
2. Tests may need to be added/updated for collection_editor's changed backend controller

Hi @joshuacano -- are your changes as they are mergable to develop (i.e. do things still work when your changes are included?) If so, I suggest making a PR, so that this will be easier to review/comment on.

Actually, even if they are not mergable, making a PR is still a good idea so the reviewer can look at the changes as a whole, and suggest next steps.

Gotcha, thanks will double check my code and create a pr.

Joshua Cano

> On Aug 23, 2016, at 22:45, Xinyu Wu notifications@github.com wrote:
> 
> Hi @joshuacano -- are your changes as they are mergable to develop (i.e. do things still work when your changes are included?) If so, I suggest making a PR, so that this will be easier to review/comment on.
> 
> Actually, even if they are not mergable, making a PR is still a good idea so the reviewer can look at the changes as a whole, and suggest next steps.
> 
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub, or mute the thread.

(Also, @markhalpin, please let me know if I've got any of the above wrong!)

Also /cc @Arunabh98, who I believe originally suggested this.

Hi all,

SGTM except that I actually think we should use the apple, for a few reasons:
1) photos used in an application that small are going to be unappealing -- detail is scrunched and it's difficult to make out the content of the photo.
2) per a comment on a different matter, we might or might not actually have photos of a given author, or the authorship might spread out over multiple collaborators. I'm not sure how to handle this issue elsewhere -- it needs discussion I think -- but in this case the simple fix is to use an icon instead. Note that we could use a _different_ icon, but as things like pencils are already being used as icons elsewhere, the apple seemed apt.
3) I think the style of the graphic provides a good balance to the similarly styled and colored graphics at the right side of the footer.

I absolutely agree that it would be great if we can swap out "Author Profile"/"Author Profiles" as appropriate.

I've placed an .svg for the apple in this folder: https://drive.google.com/open?id=0B4A9S7Ym8W0CUmdjUG9kQ0VsMW8

Thanks,
Mark

Ah, ok, but then we would need a mock for what happens when the apple is clicked on, otherwise people still can't see the authors or click through to their profile pages. Would we just have a popup that displays them -- maybe with contents that look something a bit like this? 
https://github.com/angular/material/blob/master/CHANGELOG.md#contributors

@seanlip I'm not quite sure what you're getting at: why would the experience of clicking on the apple (or other icon) be different from that of clicking on a photo? My assumption would have been that in either case it links directly to a profile page. But, since there might be multiple authors, I do like the idea of (in either case) a popup that displays them as you link to above, with each of those being links to individual creator pages. Seeing photos at that size is much nicer :)

Right, I was thinking mainly of the multiple author case -- and since that's possible, we'd want clicking on the apple to be a consistent experience in either case (so we shouldn't have it do a direct-link sometimes and a popup at other times). In addition, a direct-link would be a bit unsettling -- with a profile picture you have a sort of preview of where you're going to. So I think having the popup in both cases is a good idea.

Do you think you'd be able to add a mock for what the popup looks like on the page (after the user clicks on the bottom left apple/text)? Then I think we can implement that.

Thanks!

ah, I think that's a nice idea. Yep, I'll do a mock for that.


Resolving patch:
diff --git a/core/domain/summary_services.py b/core/domain/summary_services.py
--- a/core/domain/summary_services.py
+++ b/core/domain/summary_services.py
@@ -296,6 +296,10 @@ def get_displayable_exp_summary_dicts(exploration_summaries):
             'last_updated_msec': utils.get_time_in_millisecs(
                 exploration_summary.exploration_model_last_updated
             ),
+            'human_readable_contributors_summary': (
+                get_human_readable_contributors_summary(
+                    exploration_summary.contributors_summary)
+            ),
             'status': exploration_summary.status,
             'ratings': exploration_summary.ratings,
             'community_owned': exploration_summary.community_owned,


Test patch: