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

Show favorites indicator in the list for the Shared with you / others / by link views #19753

Closed
jancborchardt opened this Issue Oct 13, 2015 · 4 comments

Comments

Projects
None yet
5 participants
@jancborchardt
Member

jancborchardt commented Oct 13, 2015

Even when an element is favorited, in the 3 share views the star indicator column does not show. It should though, so you can quickly see which items are favorited, and to be able to unfavorite or favorite elements just as you can do in the All files and Favorites views.

@PVince81 @MorrisJobke @schiesbn @owncloud/designers

@jancborchardt jancborchardt added this to the 9.0-next milestone Oct 13, 2015

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Oct 14, 2015

Member

There are three possible approaches:

  1. Make the OCS share API should return the favorite info (and later tags?) along with its response. Might not fit with the API. But we might want to have the share API return the full file info anyway (like a PROPFIND)

  2. If not, then the web UI will need to make additional ajax calls to retrieve the favorite/tag information for every file in the list, bad for performance.

  3. Provide an additional (private?) endpoint that gets a list of file ids as input and returns the favorite/tag info for each of them. This is also not nice as it's very specific to this use case and also a private call.

Other ideas ?

(also CC @rullzer)

Member

PVince81 commented Oct 14, 2015

There are three possible approaches:

  1. Make the OCS share API should return the favorite info (and later tags?) along with its response. Might not fit with the API. But we might want to have the share API return the full file info anyway (like a PROPFIND)

  2. If not, then the web UI will need to make additional ajax calls to retrieve the favorite/tag information for every file in the list, bad for performance.

  3. Provide an additional (private?) endpoint that gets a list of file ids as input and returns the favorite/tag info for each of them. This is also not nice as it's very specific to this use case and also a private call.

Other ideas ?

(also CC @rullzer)

@PVince81

This comment has been minimized.

Show comment
Hide comment
@PVince81

PVince81 Oct 14, 2015

Member

CC @karlitschek @cmonteroluque @DeepDiver1975 for triaging/scheduling

Member

PVince81 commented Oct 14, 2015

CC @karlitschek @cmonteroluque @DeepDiver1975 for triaging/scheduling

@rullzer

This comment has been minimized.

Show comment
Hide comment
@rullzer

rullzer Oct 15, 2015

Contributor

Mmm I'm not a big fan of any of those actually. But option 1 seems like the lesser evil. It just conflicts with my plan to cleanup the Share API output to contain a lot less info.

Let me think how we can solve this properly wihtout to much calls to the server.

Contributor

rullzer commented Oct 15, 2015

Mmm I'm not a big fan of any of those actually. But option 1 seems like the lesser evil. It just conflicts with my plan to cleanup the Share API output to contain a lot less info.

Let me think how we can solve this properly wihtout to much calls to the server.

@cmonteroluque cmonteroluque modified the milestones: 9.1-next, 9.0-current Feb 22, 2016

@PVince81 PVince81 modified the milestones: 9.1-current, 9.2-next Jun 14, 2016

@DeepDiver1975

This comment has been minimized.

Show comment
Hide comment
@DeepDiver1975

DeepDiver1975 Nov 10, 2016

Member

fixes with #26583

Member

DeepDiver1975 commented Nov 10, 2016

fixes with #26583

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment