Linked projects are not shown in explorer
smathot opened this issue · 12 comments
I just came across the following use case, which is not handled well:
- Someone makes their OpenSesame experiment public on the OSF
- But you're not a collaborator, so the project is not accessible through the OSF extension
So how can you still access the experiment?
My first thought was: I create a link to this project in one of my repositories. On the OSF website, this makes the experiment visible through (what seems like) a storage provider:
But the storage provider does not show up in the OSF extension:
Ideally, linked projects would be visible, but read-only. This may be a waterbutler limitation, I'm not sure.
Hmm, we should ask the Waterbutler developers about this. QOSF just recursively traverses the file trees that it is provided. If a file doesn't show up, it's probably not present in the tree and thus not presented by waterbutler. Or there is a different notation/file type for links such that QOSF doesn't process it. It would be an interesting option to add this though...
Could you repost this issue on Waterbutler then? I think it's probably simply not implemented yet, but they may do it if we point this use case out to them.
Yes, that sounds like a good idea. Here it is CenterForOpenScience/waterbutler#188.
Working on this, but I have some problems interpreting the API response.
As of v1.2.0, linked projects appear in the item tree. Making the linked projects appear was quite easy, but the challenge was to honor the read-only permissions that these linked projects can potentially have (your own and shared projects are usually writeable, so I never accounted for per-project permissions). I accounted for this by disabling buttons/actions for items which the user doesn't have write access to. Permission checking is not really done 'elegantly', but this is mainly due to a limitation to the OSF API (see CenterForOpenScience/waterbutler#197). Hopefully we can improve on this in the future. For now it seems to work quite nicely.
Can you test it and see if it works correctly for you?
Excellent!
It works, but there seems to be one edge case that isn't handled properly, having to do with the read-only problem:
The problem
- If I open an experiment from a linked project, then the original author of the experiment may have linked it to some location on the OSF.
- The OSF extension recognizes this and indicates where the experiment is linked to.
- However, this linked location is not writable for me!
If I now save the experiment, the OSF extension asks if I want to update it on the OSF as well. If I say yes, then I get the following error, presumably resulting from the extension trying to write to a read-only location on the OSF.
A solution
One way to solve this is by checking, when an experiment is opened, whether it was linked to a read-only location on the OSF. If so, a notification is shown to notify the user that:
We have unlinked this experiment from the OSF, because it was linked to a read-only location.
What do you think?
I bumped into that one too. Your solution seems the most logical one, but it is harder to achieve than you'd assume. The problem is that user permission information is stored at the project node, but not at the file and folder nodes. So if I request the information of a specific (OpenSesame) file, I get no indication if the user has write access. One way to tackle this, is to somehow traverse up the tree until a parent node is encountered that contains the project information. As far as I can tell, the OSF API does not offer any mechanism to do so, as it does not provide the parents in a node's information...
This limitation is also discussed at CenterForOpenScience/waterbutler#197 and CenterForOpenScience/waterbutler#188 (comment)
After looking into this more thoroughly, I have to conclude that it is really hard to realise your solution, even though it seems so simple.
The problem is that the OSF API does not provide the minimum amount of information that is needed to determine the access permissions to an isolated file (i.e. a file that you directly request information for with the API, instead of getting its information as part of constructing the whole file tree).
As stated before, you'd either need:
- access information to the node representing the file.
- links to parent nodes.
to somehow determine if a user can manipulate the file. None of these are currently provided.
There is an OSF API key called delete_allowed which I thought would save us, but this is set to 'yes' even for users that don't have write access to the file, so it doesn't tell us anything.
Even though the current way of handling the opening of read-only experiments is isn't particularly nice, I think it will currently cost too much valuable time to make it more graceful. It is probably better to wait until the OSF API provides the necessary information (an issue has already been created: CenterForOpenScience/waterbutler#197).
One solution I can look into is to listen for the 'Forbidden' error message, and unlink the experiment if it is detected. This seems far from fool-proof to me, and should be regarded as an ugly monkey-patch for this situation.
Ok, well it's a bit of an edge case, so I wouldn't give it priority.
One solution I can look into is to listen for the 'Forbidden' error message, and unlink the experiment if it is detected. This seems far from fool-proof to me, and should be regarded as an ugly monkey-patch for this situation.
What does this mean exactly? If the Forbidden error could be used to at least notify the user that the experiment wasn't updated on the OSF, then that would already be quite an improvement, right? The worst aspect of the current situation is not that writing to the OSF fails per se, but that it fails without any message to the user.
It is the error message which you receive when you can't access an item. It's on the screenshot that you posted and reads server replied: Forbidden. We could scan for this message and replace it with You do not have access to perform this operation ... or something like that.
Yes. Something like this:
The OSF replied 'Forbidden'. This may mean that you do not have permission to write to a repository.
Linked Projects are shown in the tree now. I think we should open a new issue for the Forbidden problem.