From andres at ekumenlabs.com  Mon Jul  3 15:23:23 2017
From: andres at ekumenlabs.com (=?UTF-8?Q?Andr=C3=A9s_Fortier?=)
Date: Mon, 3 Jul 2017 16:23:23 -0300
Subject: [Girder-users] Restricting user access
Message-ID: <CALiGwQuZwb76xUgq3a02OdpTKD71Td7SK3SWOb9wi2Z_8yV54g@mail.gmail.com>

Hi all,
I was wondering if it is possible to restrict a user access to girder, both
in the REST API and in the web view. One use case for this is to be able to
treat a folder and its contents as a whole: we want a user to be able to
upload a folder and to update it, but always as a whole (i.e. not to allow
partial updates, like adding a file to it). Our idea would be to have a
dedicated REST endpoint for this (similar to the way a folder is uploaded
now) to handle the CRUD, but then we need to ensure that:

1. the user can't manually call the current API to update the folder. I
think the way to do this would be to remove some API endpoints, although
I'm not sure this can be done easily.
2. the user can't login in the web UI (this is ok as we will be rolling our
dedicated UI). Is there a simple way to make the UI admin-only?

Any hints would be much appreciated.

Thanks!
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/girder-users/attachments/20170703/4419cce5/attachment.html>

From zach.mullen at kitware.com  Mon Jul  3 15:31:50 2017
From: zach.mullen at kitware.com (Zach Mullen)
Date: Mon, 3 Jul 2017 15:31:50 -0400
Subject: [Girder-users] Restricting user access
In-Reply-To: <CALiGwQuZwb76xUgq3a02OdpTKD71Td7SK3SWOb9wi2Z_8yV54g@mail.gmail.com>
References: <CALiGwQuZwb76xUgq3a02OdpTKD71Td7SK3SWOb9wi2Z_8yV54g@mail.gmail.com>
Message-ID: <CAPzddEGC_gknVT-wv2R9-7eQA9+=9teJSsOt5MSoLjvqMhs93A@mail.gmail.com>

Hi Andy,

Both of these things are pretty easy. API endpoints can be removed in your
plugin just by using delattr on the method itself under info['apiRoot'].
Modifying the UI to only show login for admins is pretty simple, too, by
using the wrap function on the HeaderUserView.render function.

Thanks,



Zach Mullen
Kitware, Inc.
919-869-8858

On Mon, Jul 3, 2017 at 3:23 PM, Andr?s Fortier <andres at ekumenlabs.com>
wrote:

> Hi all,
> I was wondering if it is possible to restrict a user access to girder,
> both in the REST API and in the web view. One use case for this is to be
> able to treat a folder and its contents as a whole: we want a user to be
> able to upload a folder and to update it, but always as a whole (i.e. not
> to allow partial updates, like adding a file to it). Our idea would be to
> have a dedicated REST endpoint for this (similar to the way a folder is
> uploaded now) to handle the CRUD, but then we need to ensure that:
>
> 1. the user can't manually call the current API to update the folder. I
> think the way to do this would be to remove some API endpoints, although
> I'm not sure this can be done easily.
> 2. the user can't login in the web UI (this is ok as we will be rolling
> our dedicated UI). Is there a simple way to make the UI admin-only?
>
> Any hints would be much appreciated.
>
> Thanks!
> Andy
>
> _______________________________________________
> Girder-users mailing list
> Girder-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/girder-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/girder-users/attachments/20170703/3638b6cc/attachment.html>

From andres at ekumenlabs.com  Mon Jul  3 15:59:37 2017
From: andres at ekumenlabs.com (=?UTF-8?Q?Andr=C3=A9s_Fortier?=)
Date: Mon, 3 Jul 2017 16:59:37 -0300
Subject: [Girder-users] Restricting user access
In-Reply-To: <CAPzddEGC_gknVT-wv2R9-7eQA9+=9teJSsOt5MSoLjvqMhs93A@mail.gmail.com>
References: <CALiGwQuZwb76xUgq3a02OdpTKD71Td7SK3SWOb9wi2Z_8yV54g@mail.gmail.com>
 <CAPzddEGC_gknVT-wv2R9-7eQA9+=9teJSsOt5MSoLjvqMhs93A@mail.gmail.com>
Message-ID: <CALiGwQv0j5mOSQNiz8ugDZ-yZ6f0Z5OiLvRJPbntLEaVek7Upg@mail.gmail.com>

Great, thanks for the quick reply Zach! We are making good progress on
defining the workflow and so far Girder seems like a nice fit :)

On Mon, Jul 3, 2017 at 4:31 PM, Zach Mullen <zach.mullen at kitware.com> wrote:

> Hi Andy,
>
> Both of these things are pretty easy. API endpoints can be removed in your
> plugin just by using delattr on the method itself under info['apiRoot'].
> Modifying the UI to only show login for admins is pretty simple, too, by
> using the wrap function on the HeaderUserView.render function.
>
> Thanks,
>
>
>
> Zach Mullen
> Kitware, Inc.
> 919-869-8858
>
> On Mon, Jul 3, 2017 at 3:23 PM, Andr?s Fortier <andres at ekumenlabs.com>
> wrote:
>
>> Hi all,
>> I was wondering if it is possible to restrict a user access to girder,
>> both in the REST API and in the web view. One use case for this is to be
>> able to treat a folder and its contents as a whole: we want a user to be
>> able to upload a folder and to update it, but always as a whole (i.e. not
>> to allow partial updates, like adding a file to it). Our idea would be to
>> have a dedicated REST endpoint for this (similar to the way a folder is
>> uploaded now) to handle the CRUD, but then we need to ensure that:
>>
>> 1. the user can't manually call the current API to update the folder. I
>> think the way to do this would be to remove some API endpoints, although
>> I'm not sure this can be done easily.
>> 2. the user can't login in the web UI (this is ok as we will be rolling
>> our dedicated UI). Is there a simple way to make the UI admin-only?
>>
>> Any hints would be much appreciated.
>>
>> Thanks!
>> Andy
>>
>> _______________________________________________
>> Girder-users mailing list
>> Girder-users at public.kitware.com
>> http://public.kitware.com/mailman/listinfo/girder-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/girder-users/attachments/20170703/7d946096/attachment.html>

From andres at ekumenlabs.com  Mon Jul 10 09:25:25 2017
From: andres at ekumenlabs.com (=?UTF-8?Q?Andr=C3=A9s_Fortier?=)
Date: Mon, 10 Jul 2017 10:25:25 -0300
Subject: [Girder-users] Understanding Items, Files and Folders
Message-ID: <CALiGwQsN4ekUYRsqYpDXZ5zufaYRjNtO7r7j5yAeEX2pD_Df_A@mail.gmail.com>

Hi all,
I'm working on a plugin to search on Files and Folders by a metadata field
(the "type" field). The important parts of the code I have so far are:

class ResourceExt(Resource):
    @access.public
    @describeRoute(...)
    def typeSearch(self, params):
        self.requireParams(('type'), params)
        limit, offset, sort = self.getPagingParameters(params, 'name')
        asset_type = params['type']
        query = {"meta.type": asset_type}
        fields = ['_id', 'name', 'description', 'folderId', 'public',
'access']

        model = ModelImporter().model('item')
        cursor = model.find(query, fields=fields)
        return list(model.filterResultsByPermission(
            cursor, user=self.getCurrentUser(), level=AccessType.READ,
            limit=limit, offset=offset, removeKeys=('public', 'access')))

def load(info):
    ModelImporter.model('item').ensureIndex(['meta.type', {'sparse': True}])
    ext = ResourceExt()
    info['apiRoot'].resource.route('GET', ('type_search',), ext.typeSearch)

now this seems to be working ok with files, but fails to return folders, so
I think I have a wrong idea of what an item model is. I originally thought
that an item was an abstraction of both files and folders, and that
querying the item model was the way to query for both of them. I then
checked the items mongo collection and it seems there is an item record for
each file record, but none for the folder entries. So this brings up a
couple of questions:

1. What is the relationship between items, files and folders? What are the
concrete use cases for items? [1]
2. Is there a way to perform metadata-based queries on both files and
folders? I know I can do two queries (one on files and one on folders) but
then I would have to manually merge them and handle all the limit/offset
math, which seems unnecessarily complicated.

[1] I did check the class comments and I'm a bit confused about those too.
E.g. in Item it says "Items are leaves in the data hierarchy. They can
contain 0 or more files within them ...", which is confusing as I would
expect leaves to be files instead of containing them. Also if items can
contain files, doesn't that mean they are (or act as) folders?

Thanks in advance!
Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/girder-users/attachments/20170710/99b52f92/attachment.html>

From jonathan.beezley at kitware.com  Mon Jul 10 09:49:57 2017
From: jonathan.beezley at kitware.com (Jonathan Beezley)
Date: Mon, 10 Jul 2017 09:49:57 -0400
Subject: [Girder-users] Understanding Items, Files and Folders
In-Reply-To: <CALiGwQsN4ekUYRsqYpDXZ5zufaYRjNtO7r7j5yAeEX2pD_Df_A@mail.gmail.com>
References: <CALiGwQsN4ekUYRsqYpDXZ5zufaYRjNtO7r7j5yAeEX2pD_Df_A@mail.gmail.com>
Message-ID: <CAATBr3asqncyKRg40na2pAy=hDvOC+QOObXniwP7e0Ckgunh8A@mail.gmail.com>

Hi Andy,

Folders, items, and files are all separate entities.  In terms of their
tree structure, Girder models look like this:

* a folder's parent is either a folder, user, or collection
* an item's parent is a folder
* a file's parent is an item

A model can only have one parent, but multiple children.  So, folders can
contain both other folders and items, but not files.  In terms of an
abstract file system, there is no equivalent to an "item", it is an
additional type that lies between a file and a folder.

Files don't have metadata associated with them, so you are probably looking
to create an endpoint that searches folders and items.  It's possible you
might be able to construct a single query to do this using a mongo
aggregation pipeline, but I'm not certain how.  The simplest way would be
to do two queries and join them together somehow.  The only endpoint that I
know of that returns multiple model types is /resource/search
<https://github.com/girder/girder/blob/master/girder/api/v1/resource.py#L68>,
though I don't know I would recommend doing it that way.

If I were doing this, I would probably just create two different endpoints
for each type.  It adds a bit of complexity to the client (two rest
requests rather than one), but it is a more idiomatic restful interface.

Jon

On Mon, Jul 10, 2017 at 9:25 AM, Andr?s Fortier <andres at ekumenlabs.com>
wrote:

> Hi all,
> I'm working on a plugin to search on Files and Folders by a metadata field
> (the "type" field). The important parts of the code I have so far are:
>
> class ResourceExt(Resource):
>     @access.public
>     @describeRoute(...)
>     def typeSearch(self, params):
>         self.requireParams(('type'), params)
>         limit, offset, sort = self.getPagingParameters(params, 'name')
>         asset_type = params['type']
>         query = {"meta.type": asset_type}
>         fields = ['_id', 'name', 'description', 'folderId', 'public',
> 'access']
>
>         model = ModelImporter().model('item')
>         cursor = model.find(query, fields=fields)
>         return list(model.filterResultsByPermission(
>             cursor, user=self.getCurrentUser(), level=AccessType.READ,
>             limit=limit, offset=offset, removeKeys=('public', 'access')))
>
> def load(info):
>     ModelImporter.model('item').ensureIndex(['meta.type', {'sparse':
> True}])
>     ext = ResourceExt()
>     info['apiRoot'].resource.route('GET', ('type_search',),
> ext.typeSearch)
>
> now this seems to be working ok with files, but fails to return folders,
> so I think I have a wrong idea of what an item model is. I originally
> thought that an item was an abstraction of both files and folders, and that
> querying the item model was the way to query for both of them. I then
> checked the items mongo collection and it seems there is an item record for
> each file record, but none for the folder entries. So this brings up a
> couple of questions:
>
> 1. What is the relationship between items, files and folders? What are the
> concrete use cases for items? [1]
> 2. Is there a way to perform metadata-based queries on both files and
> folders? I know I can do two queries (one on files and one on folders) but
> then I would have to manually merge them and handle all the limit/offset
> math, which seems unnecessarily complicated.
>
> [1] I did check the class comments and I'm a bit confused about those too.
> E.g. in Item it says "Items are leaves in the data hierarchy. They can
> contain 0 or more files within them ...", which is confusing as I would
> expect leaves to be files instead of containing them. Also if items can
> contain files, doesn't that mean they are (or act as) folders?
>
> Thanks in advance!
> Andy
>
> _______________________________________________
> Girder-users mailing list
> Girder-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/girder-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/girder-users/attachments/20170710/a2fa4e67/attachment.html>

From andres at ekumenlabs.com  Mon Jul 10 10:17:06 2017
From: andres at ekumenlabs.com (=?UTF-8?Q?Andr=C3=A9s_Fortier?=)
Date: Mon, 10 Jul 2017 11:17:06 -0300
Subject: [Girder-users] Understanding Items, Files and Folders
In-Reply-To: <CAATBr3asqncyKRg40na2pAy=hDvOC+QOObXniwP7e0Ckgunh8A@mail.gmail.com>
References: <CALiGwQsN4ekUYRsqYpDXZ5zufaYRjNtO7r7j5yAeEX2pD_Df_A@mail.gmail.com>
 <CAATBr3asqncyKRg40na2pAy=hDvOC+QOObXniwP7e0Ckgunh8A@mail.gmail.com>
Message-ID: <CALiGwQt0mePGe8cicvaQaZgkio=wZvYS62D7Ad+4O+2ZgbVrNA@mail.gmail.com>

Hi Jon,
thanks for the quick reply and the explanation about file/folder/item,
things are much clear now. Regarding the approach we are taking, we would
like to think in term of "assets", where an asset can be either a file or a
folder. Under this approach we will most likely remove the file/folder
endpoints and generate a new one called "asset", keeping the REST
semantics. So maybe we should start by creating an Asset model with its
mongo collection counterpart and then move from there. But I will dig a bit
deeper into mongo's options first, just to get a better insight on its
capabilities.

Thanks!
Andy

On Mon, Jul 10, 2017 at 10:49 AM, Jonathan Beezley <
jonathan.beezley at kitware.com> wrote:

> Hi Andy,
>
> Folders, items, and files are all separate entities.  In terms of their
> tree structure, Girder models look like this:
>
> * a folder's parent is either a folder, user, or collection
> * an item's parent is a folder
> * a file's parent is an item
>
> A model can only have one parent, but multiple children.  So, folders can
> contain both other folders and items, but not files.  In terms of an
> abstract file system, there is no equivalent to an "item", it is an
> additional type that lies between a file and a folder.
>
> Files don't have metadata associated with them, so you are probably
> looking to create an endpoint that searches folders and items.  It's
> possible you might be able to construct a single query to do this using a
> mongo aggregation pipeline, but I'm not certain how.  The simplest way
> would be to do two queries and join them together somehow.  The only
> endpoint that I know of that returns multiple model types is
> /resource/search
> <https://github.com/girder/girder/blob/master/girder/api/v1/resource.py#L68>,
> though I don't know I would recommend doing it that way.
>
> If I were doing this, I would probably just create two different endpoints
> for each type.  It adds a bit of complexity to the client (two rest
> requests rather than one), but it is a more idiomatic restful interface.
>
> Jon
>
> On Mon, Jul 10, 2017 at 9:25 AM, Andr?s Fortier <andres at ekumenlabs.com>
> wrote:
>
>> Hi all,
>> I'm working on a plugin to search on Files and Folders by a metadata
>> field (the "type" field). The important parts of the code I have so far are:
>>
>> class ResourceExt(Resource):
>>     @access.public
>>     @describeRoute(...)
>>     def typeSearch(self, params):
>>         self.requireParams(('type'), params)
>>         limit, offset, sort = self.getPagingParameters(params, 'name')
>>         asset_type = params['type']
>>         query = {"meta.type": asset_type}
>>         fields = ['_id', 'name', 'description', 'folderId', 'public',
>> 'access']
>>
>>         model = ModelImporter().model('item')
>>         cursor = model.find(query, fields=fields)
>>         return list(model.filterResultsByPermission(
>>             cursor, user=self.getCurrentUser(), level=AccessType.READ,
>>             limit=limit, offset=offset, removeKeys=('public', 'access')))
>>
>> def load(info):
>>     ModelImporter.model('item').ensureIndex(['meta.type', {'sparse':
>> True}])
>>     ext = ResourceExt()
>>     info['apiRoot'].resource.route('GET', ('type_search',),
>> ext.typeSearch)
>>
>> now this seems to be working ok with files, but fails to return folders,
>> so I think I have a wrong idea of what an item model is. I originally
>> thought that an item was an abstraction of both files and folders, and that
>> querying the item model was the way to query for both of them. I then
>> checked the items mongo collection and it seems there is an item record for
>> each file record, but none for the folder entries. So this brings up a
>> couple of questions:
>>
>> 1. What is the relationship between items, files and folders? What are
>> the concrete use cases for items? [1]
>> 2. Is there a way to perform metadata-based queries on both files and
>> folders? I know I can do two queries (one on files and one on folders) but
>> then I would have to manually merge them and handle all the limit/offset
>> math, which seems unnecessarily complicated.
>>
>> [1] I did check the class comments and I'm a bit confused about those
>> too. E.g. in Item it says "Items are leaves in the data hierarchy. They
>> can contain 0 or more files within them ...", which is confusing as I
>> would expect leaves to be files instead of containing them. Also if items
>> can contain files, doesn't that mean they are (or act as) folders?
>>
>> Thanks in advance!
>> Andy
>>
>> _______________________________________________
>> Girder-users mailing list
>> Girder-users at public.kitware.com
>> http://public.kitware.com/mailman/listinfo/girder-users
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/girder-users/attachments/20170710/da83c14e/attachment-0001.html>

From Brian.Chapman at utah.edu  Fri Jul 21 20:38:31 2017
From: Brian.Chapman at utah.edu (Brian E Chapman)
Date: Sat, 22 Jul 2017 00:38:31 +0000
Subject: [Girder-users] Switching Between 2D and 3D dicom viewers
Message-ID: <8B3AE212-18DA-456F-BFD4-71AB3DCA7BB9@umail.utah.edu>

Hi Everyone,

After a great visit from Zach, we are trying to replicate all the girder functionality he demonstrated. One thing I can?t remember is how to switch between the 2D and 3D DICOM viewers. I think it was a metadata value but can?t remember the key/value pair for this.

Brian

Brian E Chapman, Ph.D
Associate Professor
Department of Radiology and Imaging Sciences
University of Utah

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/girder-users/attachments/20170722/7a609d3c/attachment.html>

From zach.mullen at kitware.com  Fri Jul 21 21:21:32 2017
From: zach.mullen at kitware.com (Zach Mullen)
Date: Fri, 21 Jul 2017 21:21:32 -0400
Subject: [Girder-users] Switching Between 2D and 3D dicom viewers
In-Reply-To: <8B3AE212-18DA-456F-BFD4-71AB3DCA7BB9@umail.utah.edu>
References: <8B3AE212-18DA-456F-BFD4-71AB3DCA7BB9@umail.utah.edu>
Message-ID: <CAPzddEFz-fjCFsNDOCipO42JDqz8uP_71xoyw=deAh2iycXEMQ@mail.gmail.com>

Hi Brian,

In the XTK plugin that I demoed, you just change the XTK metadata value
from {"type": "volume"} to {"type": "volume2d"}

Thanks,

-Zach



On Fri, Jul 21, 2017 at 8:38 PM, Brian E Chapman <Brian.Chapman at utah.edu>
wrote:

> Hi Everyone,
>
> After a great visit from Zach, we are trying to replicate all the girder
> functionality he demonstrated. One thing I can?t remember is how to switch
> between the 2D and 3D DICOM viewers. I think it was a metadata value but
> can?t remember the key/value pair for this.
>
> Brian
>
> Brian E Chapman, Ph.D
> Associate Professor
> Department of Radiology and Imaging Sciences
> University of Utah
>
>
> _______________________________________________
> Girder-users mailing list
> Girder-users at public.kitware.com
> http://public.kitware.com/mailman/listinfo/girder-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/girder-users/attachments/20170721/0f5bcea0/attachment.html>