only an admin should be able to delete objects

[jrochkind]

Does "admin" mean something different than "logged in user" here and in associated issues?

[catlu]

I think so--this came up because we wanted to separate collection management/deletion abilities from "cataloger" logged in users (currently, if you can edit, you can delete, and there is no separation in type of logged in user). This probably also gets into what we want for admin user functionality, a conversation we started but haven't returned to just yet.

[jrochkind]

Thanks @catlu! @catlu and @hackmastera: Do we need more discussion before tackling this issue and others in https://github.com/chemheritage/chf-sufia/labels/gantt%3A%20admin%20%2F%20authorization , should I not start on them yet?

[MDiMeo]

We haven't really talked about this for a year(!), so I think a brief revisit might be best first. I know @hackmastera got close on this, but then we put it down for other priorities.

[MDiMeo]

@jrochkind We previously discussed the authorization strategy on Basecamp, then turned it into GitHub tickets. Here's some background, but this is OLD and should be revisited https://basecamp.com/1929213/projects/8498313/todos/158824002

[hackartisan]

The unfinished work is on the admin-role branch; see https://github.com/chemheritage/chf-sufia/wiki/List-of-WIP-branches

[hackartisan]

setting the permissions in ability work to prevent the behavior, but the buttons still show up and should be removed from the UI:

• [x] 'delete' action on 'my works' listing

• [ ] 'delete' action when a batch is selected in 'my works' listing

• [x] 'delete' button on work show page

• [x] 'delete' action in item list on work show page (this one uses the id string so we don't need to do any view changes; taken care of in ability.rb)

• [x] 'delete this file' button button on fileset show page

• [x] once the ability has been updated you can activate any of these, approve the confirmation, and then you get a confusing / wrong error message: