Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should users be able to delete their own AOIs/files? #85

Closed
jkeifer opened this issue Nov 22, 2017 · 2 comments
Closed

Should users be able to delete their own AOIs/files? #85

jkeifer opened this issue Nov 22, 2017 · 2 comments
Labels

Comments

@jkeifer
Copy link
Member

jkeifer commented Nov 22, 2017

@lbross brought up a question about users being able to delete their own uploads in ticket #79. I've created this ticket for the discussion around that request,.

To clarify one thing first: users should already be able to cancel their own uploads. We don't delete upload or download records because they should be retained for archival purposes. However, I think the question really was about users being able to delete AOIs created from their uploads.

I believe it would be best to pull @jdduh in here to comment, but my understanding was that we had determined it best to allow only admins to delete AOIs/files, as we really have no concept of ownership. If a user creates an AOI or other resource, then that is a resource for all users, and only admins can decide to remove that resource.

If we wanted to switch to something where users have more control over their stuff, then I'd suggest we move to an approach kinda like github, where everything a user creates is namespaced under their user account. This idea brings up some questions about permissions though, as in should other NWCC users really be allow to modify another user's stuff without explicit permission? Under this user ownership model, are we creating conditions similar to what they already have, where users have their own copies of AOIs, there is no official master copy, and disorder ensues?

Another idea: perhaps what we really need is a blend of both. We have global reference AOIs that are the standards, and one-off stuff that isn't really meant to be shared can be user-owned (and omitted from the default views). The latter could be moved to global ownership by an admin, or deleted if deemed no longer needed by an end user. This scenario would add significant complexity, and I'm not sure it is worth it at this point. After all, onetime AOIs are likely to still live on user's machines and not be uploaded to ebagis (I can see though how this model could be valuable if we have analytical functions server side at some point).

@lbross
Copy link

lbross commented Nov 22, 2017

Agreed that we should not proceed without @jdduh input. One issue to keep in mind as that we don't support partial updates of AOIs yet and I'm not sure if this is on the priority list for this year. This means that to update an AOI, one needs to delete it and then re-upload the whole thing. Not sure what the workflow is at NWCC but it could be inconvenient to have to find an admin to make changes to an AOI that one manages.

We have a filter on the PC-BAGIS side that allows users to filter for AOIs they have uploaded. If we decide to minimize the concept of ownership, this should probably be removed. We also show the author of each AOI on the PC-BAGIS interface.

I don't support going too far down the road of supporting individual namespaces. I think there are better things to do with that development effort. For example: partial updates.

@lbross
Copy link

lbross commented Dec 15, 2017

Per comments made by @jdduh during staff meeting on 12/14/2017, we will not allow users to delete AOIs unless they members of the nwcc_admin group. I have updated the error message in PC-BAGIS to include the suggestion to contact an Administrator for help deleting an AOI if a delete request fails. Closing.

@lbross lbross closed this as completed Dec 15, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants