syncdaemon creates "view, copy" shares only

[Roman Yepishev]

STR:
1. Share something via Nautilus extension checking Allow Modification.
2. Check the created share:
id=a1f3ad6c-545d-4ef3-9a7b-2f48002f008d name=Default accepted=True access_level=View to=openiduser19154 path=/home/rtg/Ubuntu One/[...]

Result:
Share is in View-only mode (view and copy, in terms of Web UI if it had that displayed)

Expected result:
Share is in Read/Write mode (change, view and copy in terms of Web UI)

Caused by:

ubuntuone-nautilus.c:
ubuntuone_nautilus_share_dialog_response:
   allow_mods = gtk_toggle_button_get_active (GTK_TOGGLE_BUTTON (data->allow_mods));
   modify = g_strdup_printf ("%d", allow_mods);

    dbus_g_proxy_begin_call (data->uon->u1_shares, "create_share",
    ...
        G_TYPE_STRING, modify,
        G_TYPE_INVALID);

syncdaemon/dbus_interface.py:
@dbus.service.method(DBUS_IFACE_SHARES_NAME, in_signature='ssss', out_signature='')
def create_share(self, path, username, name, access_level):
 """ Share a subtree to the user identified by username.
 ...
 @param access_level: 'View' or 'Modify'
 """
 ...
 self.vm.create_share(path, username, name, access_level)

syncdaemon/volume_manager.py:
def create_share(self, path, username, name, access_level):
        """ create a share for the specified path, username, name """
 self.m.action_q.create_share(mdobj.node_id, username, name, access_level, marker)

syncdaemon/action_queue.py:
def create_share(self, node_id, share_to, name, access_level, marker):
  ...
  return CreateShare(self.meta_queue, node_id, share_to, name, access_level, marker).start()

[sorry, skipped]

def _create_share_http(self, node_id, user, name, modify, deferred):
  """Create a share using the HTTP Web API method."""
 data = dict(offer_to_email = user,
                    read_only = modify != True,
                    node_id = node_id,
                    share_name = name)

Summmary:
modify = "0" or "1" (strings) and they both != True.

[Roman Yepishev (rye)]

First of all, the problem is in syncdaemon.
Simple read_only = modify != "1" fixes the problem but it does not fix the real reason.

access_level=True or access_level=False do not make much sense to me. Yes, later on this is transformed to "modify" and then "read_only" True/False but how about the command line routine u1sdtool which says:

  --offer-share=PATH USER SHARE_NAME ACCESS_LEVEL
                         share PATH to USER.

In this case I do the following,
$ u1sdtool --list-shared
Shared list:
  id=deadbeef name=Scans accepted=True access_level=View to=openiduser19154 path=/home/rtg/Ubuntu One/Documents/Scans

Hm, probably, access_level needs to be set to "View".
However it does not matter what I put there. "View" != True, so the share is read-only, as intended. But it will be set to read-only for any value of access_level.

So please:
1. Make access_level understandable.
2. Fix the access_level check or people will start complaining once the second party tries to put a file into the share created with "Allow Modification".

P.S. openiduser19154 is not nice as well, but I suspect that has something to do with bug #402775

[Guillermo Gonzalez (verterok)]

Hi Roman,

Thanks for the detailed report! :-)

Lucio, please reasign and prioritize