Skip to content
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

Add context menu action to "open file in browser" to sync protocol and server activity #6121

Closed
ckamm opened this issue Oct 25, 2017 · 7 comments
Assignees
Labels
Design & UX Enhancement ReadyToTest QA, please validate the fix/enhancement
Milestone

Comments

@ckamm
Copy link
Contributor

ckamm commented Oct 25, 2017

Follow up from #5023.

What hasn't yet been implemented is to use private links to navigate from the sync protocol or server activity pane of the client to the web user interface.

Users should be able to right-click file entries in these views to get access to a "Open in browser" action.

There were also other tickets that suggested adding a context menu to the sync protocol view: #5982

@ckamm ckamm added this to the 2.5.0 milestone Oct 25, 2017
ckamm added a commit that referenced this issue Nov 8, 2017
To do this conveniently a bunch of functionality that's common to
IssueWidget and ProtocolWidget is moved to ProtocolItem.

Also the convenience function to asynchronously retrieve the private
link url is moved from the socket api to the network jobs.
ckamm added a commit that referenced this issue Nov 21, 2017
To do this conveniently a bunch of functionality that's common to
IssueWidget and ProtocolWidget is moved to ProtocolItem.

Also the convenience function to asynchronously retrieve the private
link url is moved from the socket api to the network jobs.
ckamm added a commit that referenced this issue Nov 21, 2017
To do this conveniently a bunch of functionality that's common to
IssueWidget and ProtocolWidget is moved to ProtocolItem.

Also the convenience function to asynchronously retrieve the private
link url is moved from the socket api to the network jobs.
@ckamm ckamm added the ReadyToTest QA, please validate the fix/enhancement label Nov 21, 2017
@ckamm ckamm self-assigned this Nov 21, 2017
@SamuAlfageme
Copy link
Contributor

@ckamm
Copy link
Contributor Author

ckamm commented Nov 29, 2017

Not yet, we'll need to do that when we're done with the shell integration additions of the same function for #5903

@guruz
Copy link
Contributor

guruz commented Apr 12, 2018

Works for me in protocol.
I guess it can't work in server activity as this is a text-only activity log with no real references to files..

@SamuAlfageme
Copy link
Contributor

It's about time to close this one as well 👍 this works great now.

@jnweiger
Copy link
Contributor

jnweiger commented Aug 9, 2018

@guruz Improvement idea:
In the sync protocol view, double click on a File brings up the file browser. A right click opens a menu with one entry. 'Open in browser'.
But for some files no clicking whatsoever works. It is not apparent when and why.

I suggest to make both 'open in local file browser' and 'open in web browser' part of the right click context menu. Would be much clearer which is which.
Files that were deleted currently do not react to neither double click nor right click. The context menu should also open for them, with grayed out entries, so that the user knows the right click itself is reliable.
Files in the 'not synced' tab could have the same context menu for consistency, but with either the local or remote entry grayed out as appropriate.

@guruz
Copy link
Contributor

guruz commented Aug 10, 2018

@jnweiger I agree with you about the graying out etc. Maybe create a new issue?
Which operation though would the double click be if there is no operation? Just no operation like currently?

@ckamm
Copy link
Contributor Author

ckamm commented Aug 14, 2018

@jnweiger That makes a lot of sense, I'll move it to an issue!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Design & UX Enhancement ReadyToTest QA, please validate the fix/enhancement
Projects
None yet
Development

No branches or pull requests

4 participants