Authorizations and project_ids vs. collections

[steffilazerte]

I'm putting both these questions here, because I think they may both be related to authorizations.

---

Collections and Projects

@denislepage has alluded to the fact that users should be able to give either a collection name or a project_id to the collections filter.

@pmorrill Does this work? In my limited tests with project id "1042", I get "Authorization required". Is that because I don't have access to every collection in project 1042?

---

Permissions for list_permissions vs. get_data

Another odd thing is that if I look at my permissions ('list_permissions') and supply my token, I am told that I have access to collection "BCATLAS1BE_DO" and that it's akn level is 4.

But if I try to download data from this collection, I'm told that I don't have access to it.

Is there something wrong with either the "list_permissions" entry point, or with the "get_data" entry point, or am I missing something here?

[pmorrill]

As far as I can see, permissions are attached to collections, rather than projects. I might be confused. However, at the moment, there is no support for submitting a projectId parameter. It can be added once Denis confirms.

I will look into the issue re permissions! Tomorrow, hopefully.

[denislepage]

I think project should simply be used as a filter like any others. I.E., if you searched for project 1060, you would get about a dozen collections containing Monarch data. You’d still have to loop through by collection to get the data itself.

[steffilazerte]

So I should have the looping done locally? Through R? So the API still just uses collections, but the R package can take a Project ID as an optional filter, then turn that into a set of collections. Easy peasy :)

[pmorrill]

We could add an optional parameter to the metadata/collections/ query:

metadata/collections?projectId=1042

Return would be a filtered list of collections: only those linked to that project. This would require a change to the proc, as well as the api servlet.

[denislepage]

I am trying to follow here, but I am not 100% sure I do.

The project ID is already included in the collection table. I don't necessarily see a need support filtering the list of collections by project in the API, since the assumption is that the full collection table should already be available in the R client.

What I had in mind was the ability to filter data based on projectID, just like any of the other supported parameters (e.g. speciesID).

You ask for all data for projectID = 1060 and speciesID = 252456, and you get a list of 12 collections under that project (Monarch Knowledge Network) for the species Monarch Butterfly.

Then the R code would still have to loop through each collection to get the data, like any other query.

Let me know if I am still missing something.

[steffilazerte]

Nope that's fine, I should not have used the word 'filtering', what I meant was "argument", i.e. exactly as you said, it's all handled in R. I'll put it on my to-do list!

[steffilazerte]

I added a new project_id argument to the download and count functions which just returns a list of collections and sends that to the api.