user_permission wrong

[nconrad]

I guess I never made a ticket for this. user_permission field is often incorrect.

I have a workspace "testing upload capability" shared with me (nconrad) with write permissions:

[
     ["nconrad@patricbrc.org", "w"],
     ["dmachi@patricbrc.org", "w"]
     ["global_permission", "n"]
]

But the user_permission field is n (none):

[
    "testing upload capability",
    "folder",
    "/devuser@patricbrc.org/",
    "2017-08-23T21:06:59",
    "00A8B4D0-8847-11E7-ABE9-C90A692E0674",
    "devuser@patricbrc.org",
    0,
    {},
    {},
    "n",
    "n",
    ""
]

[olsonanl]

is that user permission on the file itself? I think that is probably not used, since permission decisions are made at the workspace level. another piece of the workspace puzzle that needs to be cleaned up.

[nconrad]

It's the "user permission" on the workspace that was shared with me: /devuser@patricbrc.org/testing upload capability. The 10th spot in the array returned from Workspace.ls

[nconrad]

I've been working around this, of course. It just throws me off and I would use the user permission if it made sense.

[olsonanl]

Do you have a current example of this being broken? I see this for example:

  DB<13> x $ws->get({objects => ['/jimdavis@patricbrc.org/Aerococcus'], metadata_only=> 1})
0  ARRAY(0x23b7488)
   0  ARRAY(0x2278e70)
      0  ARRAY(0x22ba4c8)
         0  'Aerococcus'
         1  'folder'
         2  '/jimdavis@patricbrc.org/'
         3  '2017-12-18T21:17:56Z'
         4  'E7353D86-E438-11E7-BA85-DA0B692E0674'
         5  'jimdavis@patricbrc.org'
         6  0
         7  HASH(0x280da18)
              empty hash
         8  HASH(0x234a640)
              empty hash
         9  'w'
         10  'n'
         11  ''

which is behaving correctly for a workspace of Jim's that I can write to.

  DB<14> x $ws->list_permissions({objects => ['/jimdavis@patricbrc.org/Aerococcus']})
0  HASH(0x195af08)
   '/jimdavis@patricbrc.org/Aerococcus' => ARRAY(0x23c2490)
      0  ARRAY(0x234a6e8)
         0  'gdpusch@patricbrc.org'
         1  'n'
      1  ARRAY(0x2378cb8)
         0  'RossO@patricbrc.org'
         1  'r'
      2  ARRAY(0x23b7608)
         0  'olson@patricbrc.org'
         1  'w'
      3  ARRAY(0x23c25c8)
         0  'mshukla@patricbrc.org'
         1  'r'
      4  ARRAY(0x22369f8)
         0  'hoejholt@patricbrc.org'
         1  'w'
      5  ARRAY(0x27feac8)
         0  'csjes@patricbrc.org'
         1  'w'
      6  ARRAY(0x234a550)
         0  'seedsveta@patricbrc.org'
         1  'w'
      7  ARRAY(0x23c25f8)
         0  'global_permission'
         1  'n'

[nconrad]

yeah, the workspace above, "/devuser@patricbrc.org/testing upload capability" should still be in that permissions state. I'm not really sure what is causing it to get into that state, but I can test more to see if I can make it happen again.

[olsonanl]

There had been a bug in earlier versions of the workspace where you couldn't insert usernames with dots in them. If this was a workspace from before that was fixed you may see the issue. if it shows up on a new workspace please let me know.

[nconrad]

@olsonanl I don't think this is fixed. I just shared devuser2's workspace workspace4 with user nconrad (with write w privileges). Now, logged in as nconrad, the user_permission entry is n:

{
    "id": "F046F980-3021-11E7-AC70-A1C0682E0674",
    "path": "/devuser2@patricbrc.org/workspace4",
    "name": "workspace4",
    "type": "folder",
    "creation_time": "2017-05-03T16:59:58Z",
    "link_reference": "",
    "owner_id": "devuser2@patricbrc.org",
    "size": 0,
    "userMeta": {},
    "autoMeta": {},
    "user_permission": "n",
    "global_permission": "n",
    "timestamp": 1493830798000
}

However, list_permissions is correct:

       [
            "nconrad@patricbrc.org",
            "w"
        ],
        [
            "global_permission",
            "n"
        ]