Skip to content

Private links in share dialog and shell integrations#5763

Closed
ckamm wants to merge 0 commit into
owncloud:masterfrom
ckamm:local_links
Closed

Private links in share dialog and shell integrations#5763
ckamm wants to merge 0 commit into
owncloud:masterfrom
ckamm:local_links

Conversation

@ckamm

@ckamm ckamm commented May 10, 2017

Copy link
Copy Markdown
Contributor

This is an initial draft for comment.

Mostly the patch is quite straightforward. The exception is that storing the fileid in addition to the id adds some complications, see 875b9bb . In particular

  1. We need to initially-populate the new column from the full id column. That shouldn't cause problems though.
  2. PUT/MKCOL only give us the full id, not the fileid. If we extract the fileid by doing .left(8), we might as well not add the new column and just do that whereever needed.

The other option would be to have a transition plan where the server also replies with a new OC-FileIdLocal: <oc:fileid> header. Then oc:id and oc:fileid would be truly decoupled.

Opinions?

The last thing is that of course the OSX and Windows integrations also need to be updated to include the new action. Note that while I only added one action to the context menu for now, we might desire more, see discussion in #5023.

(I wonder whether we should generalize and have the socket api give a list of context menu commands and menu titles to the integrations - similar to GET_STRINGS - then we could adjust context menus without touching the integrations in the future)

@ckamm ckamm added this to the 2.4.0 milestone May 10, 2017
@ckamm ckamm self-assigned this May 10, 2017
@ckamm ckamm requested review from guruz and ogoffart May 10, 2017 07:54
@ckamm ckamm mentioned this pull request May 10, 2017
3 tasks
Comment thread csync/src/csync_update.c Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Man that was confusing.. :)

Comment thread src/libsync/syncjournaldb.cpp Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yay for doing this in SQL :)

@guruz

guruz commented May 10, 2017

Copy link
Copy Markdown
Contributor

Would you have a way to autotest the migration step? Maybe in tx.pl or so?
(..basically make sure that if the old id is set, the new one should also be set).

@guruz

guruz commented May 10, 2017

Copy link
Copy Markdown
Contributor

FYI @PVince81 @DeepDiver1975 to keep you in the loop

@guruz

guruz commented May 10, 2017

Copy link
Copy Markdown
Contributor

Code wise it looks good.
But we should probably indeed have the server also return the fileid on the operations (like MKCOL) where it now returns the ID.

I just wonder how decoupled this can be. Could we merge this PR here and just schedule something for the server?

@ckamm

ckamm commented May 11, 2017

Copy link
Copy Markdown
Contributor Author

@guruz Will look at tests.

The idea for decoupling id/fileid would be that we check for the presence of the new fileid header, and use left(8) of the full id if the new header isn't present. That way it works for old servers and future servers can have completely different id/fileid.

Comment thread src/libsync/owncloudpropagator.cpp Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any special reason to use reference for a qobject which was on heap before? (i don't think we do that anywhere else in the client)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, I did this automatically because it can't be 0. But yes, it's not the style we use and will adjust it.

Comment thread src/libsync/propagateremotemkdir.cpp Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should all the .left(8) magic (it's in other commits too right?) be moved to a function that has a fat comment to remove the whole stuff in a year or two?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had it in a function, but then removed it when there was only a single use left. Then I later found this corner case (PropFind is only sent for servers <= 7.0.0). Yep, will put it into a function again.

Comment thread src/libsync/propagateuploadng.cpp Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we assume that (future) servers will continue to always emit both "local" and full IDs?
@PVince81

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The client at least needs both for now.

@ckamm ckamm force-pushed the local_links branch 2 times, most recently from a9d6cf1 to e2c7305 Compare May 12, 2017 08:39
@ckamm

ckamm commented May 12, 2017

Copy link
Copy Markdown
Contributor Author

Rebased now that the logging PR was merged.

Comment thread src/gui/owncloudgui.h Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How local is the local path? "local local" ;)

@ckamm

ckamm commented May 12, 2017

Copy link
Copy Markdown
Contributor Author

@guruz This looks good to me now

@ckamm ckamm changed the title Local links (now: Private Links) Private links in share dialog and shell integrations Jun 8, 2017
@guruz guruz added the p2-high Escalation, on top of current planning, release blocker label Jun 15, 2017
ckamm added a commit to owncloud/core that referenced this pull request Jun 23, 2017
Users of the 'id' property would like to be able to deduce the 'fileid'
property from it. To allow that the 'id' property is now required to
be made up from two parts: a purely numeric one, plus one that starts
with a letter. The first part shall be the (potentially padded) fileid.

The background is that clients need the fileid to be able to create
private link urls, but they currently only have the full 'id' property
available.

See owncloud/client#5763
@ckamm

ckamm commented Jun 23, 2017

Copy link
Copy Markdown
Contributor Author

@guruz @davivel To move this forward I've created this PR against core: owncloud/core#28193 - ideally we can drop the discovery and storage of the short numeric ids.

ckamm added a commit to ckamm/owncloud-client that referenced this pull request Jun 23, 2017
ckamm added a commit to ckamm/owncloud-client that referenced this pull request Jun 23, 2017
ckamm added a commit to ckamm/owncloud-client that referenced this pull request Jun 23, 2017
ckamm added a commit to ckamm/owncloud-client that referenced this pull request Jun 23, 2017
ckamm added a commit to ckamm/owncloud-client that referenced this pull request Jun 23, 2017
ckamm added a commit to ckamm/owncloud-client that referenced this pull request Jun 23, 2017
@ckamm

ckamm commented Jun 23, 2017

Copy link
Copy Markdown
Contributor Author

I've updated this PR to remove the fileid discovery and storage and instead generate the fileid from the id we store already! From my point of view this is ready to merge.

Note: Since I rebase-dropped a bunch of unnecessary commits now, the remainder doesn't compile individually anymore. Let me flatten and merge this once it is approved.

@jturcotte jturcotte left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've pushed a few commits to refactor and make the branch work on macOS and Windows, feel free to rebase, squash (like the build fixes) or edit commits. Feel free to give feedback on those and I can fix them too.

To be able to fix an issue on Windows I added GET_STRINGS:BEGIN and GET_STRINGS:END messages, the linux code might have to be adjusted.

Comment thread src/gui/socketapi.cpp Outdated
{ "APPNAME", Theme::instance()->appNameGUI() },
{ "CONTEXT_MENU_TITLE", Theme::instance()->appNameGUI() },
{ "COPY_PRIVATE_LINK_TITLE", tr("Copy private link to clipboard") },
{ "EMAIL_PRIVATE_LINK_TITLE", tr("Send private link by email...") },

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since I also name variables to match those, it would be nice if the _MENU_TITLE suffix was consistent.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed!

Comment thread src/gui/socketapi.cpp Outdated

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this string going to be used?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not right now, it seemed like a string we might need - can drop for now.

Comment thread src/gui/socketapi.cpp Outdated
void SocketApi::command_GET_STRINGS(const QString &, SocketListener *listener)
{
static auto map = std::initializer_list<std::pair<const char *, QString>>{
{ "SHARE_MENU_TITLE", tr("Share with %1...", "parameter is ownCloud").arg(Theme::instance()->appNameGUI()) },

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Putting the appName in both the submenu title and the share entry looks a bit redundant now:
screen shot 2017-07-04 at 13 37 16

Maybe we could name it just "Share..."?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes

@guruz

guruz commented Jul 5, 2017

Copy link
Copy Markdown
Contributor

@SamuAlfageme The contents should now also be in local_links branch in normal client repo..

@ckamm

ckamm commented Jul 6, 2017

Copy link
Copy Markdown
Contributor Author

@jturcotte I think I have addressed the remaining issues and tests look good (dolphin only tomorrow though).

@SamuAlfageme I also updated the local_links branch in the main client repo in case you want to test early.

@jturcotte jturcotte left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Went through the changes again and everything looks good. If you can also go through my commits I guess it's legal that I approve this PR.

return []

# Currently 'sharable' also controls access to private link actions,
# and we definitely don't want to show them for IGNORED.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nit: 'sharable' -> 'shareable'

@ckamm ckamm closed this Jul 7, 2017
@ckamm ckamm deleted the local_links branch July 7, 2017 08:52
@ckamm

ckamm commented Jul 7, 2017

Copy link
Copy Markdown
Contributor Author

Merged manually, squashing various review and fixup commits together.

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

Labels

p2-high Escalation, on top of current planning, release blocker

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants