Check whether deleting superuser causes errors

[bess]

In our 1.x branch, deleting a superuser causes submissions errors such that newly submitted ETDs no longer go to the correct workflow (instead they get published immediately) and the user gets an error upon submission. Check to see whether this is still an issue in our 2.x branch.

• [x] After deploying to a server, delete a superuser via the console
• [x] Submit a work. If the work submits as usual, and goes into its expected workflow (i.e., if it does not get published right away) then there's no problem

If there is still a problem, fix it. If we can confirm that there is a problem in laevigata, open a ticket in Hyrax to try to reproduce in a base Hyrax app.

[val99erie]

@bess I'm not sure if you'll remember exactly how you deleted the user, but can you tell me whether you used user.delete or user.destroy or user.destroy! or some other method?

[val99erie]

I was able to reproduce this problem on master (SHA 098e707d7a88507f4fa4dfa8b1ff04d34643588f).

Without knowing exactly what ruby code was run to delete the user in the production environment, I can't be sure, but this is my best guess as to what happened...

If I delete the user with either user.destroy! or user.destroy, then the app works as expected:

• Logged in as a student, create an ETD. Get no errors on the form.

• View the catalog page when logged out, and I see no records in the catalog (which is as expected since the new ETD should not be visible yet).

• Log in as a (different) superuser, and I can see the workflow notification message for the new ETD, as expected.

But, if I delete the user by running user.delete, then I am able to reproduce the problem:

• Logged in as a student, when I submit the form to create the ETD, I get an error message. (Error message has to do with not being able to find the user for notification message.)

• If I'm logged out and view the catalog page, I (incorrectly) see the new ETD record, even though it should not have been visible yet.

• Log in as a (different) superuser, and I don't see the notification that I expect to see that the new ETD needs to be reviewd.

So, I am able to reproduce the problem on master, but I don't think this is a bug. If you run user.delete instead of user.destroy, no callbacks will be run, which will leave orphaned records in all the Sipity join tables. In that situation, I wouldn't expect the code to work properly.

My best guess is that delete was used to delete that superuser record in production. We'll need to use destroy or destroy! instead.

[val99erie]

@bess I'm going to re-assign this story to you for some follow-up.

Could you read my explanation above and see if that seems like the likely cause of the problem, and close the story if you are happy with that explanation.

If you think we should write a rake task or some other tool to delete users, could you write a story for that? (I'm not sure how common that is. Maybe we should just document it somewhere?)

[bess]

Yes, this fixes the problem, and I was able to destroy! the alicia user in production without incident (after testing it elsewhere first).