fixes #10127 - remove dynflow stacktrace when unregistering, BZ 1208100

[komidore64]

Fixing a DynFlow stacktrace that is thrown when a content-host attempts
to unregister. DynFlow would throw an ActiveRecord Validation error
stating 'Resource cannot be blank'. The resource is it referring to is a
user/owner of the DynFlow task that is being planned. Since the
content-host was registered with an activation key it is userless, and
dynflow doesn't like that.

[ehelms]

Shouldn't we be seeing this with any unregister? What makes AK as the original registration special?

[ehelms]

A little more background on the question, we appear to be doing an authorize_client call before the consumer_destroy action which calls into this code and thus should be setting User.current based upon the consumer itself -- https://github.com/Katello/katello/blob/master/app/services/katello/authentication/client_authentication.rb#L28

[komidore64]

@ehelms the same validation error is being thrown when unregistering from a non-activation-key registered content-host.

[ehelms]

Ahh, looks like Foreman Tasks is expecting the owner of the task to have an 'id' and since we set User.current to a CpConsumerUser when a content host is preforming the action itself the 'id' field is nil (since we represent content hosts via uuid).

So you are proposing to override the current user to the anonymous admin when performing this action such that the owner of the action is our anonymous admin instead of the content host itself if I understand it correctly?

[komidore64]

yes.

do you have something better in mind?

[ehelms]

I could see it being nice to know that the content host initiated the action when looking at a task list; however, thinking and looking at the task list in the UI, I am guessing the user has to be a real object of class User with a field of 'login'. So, given that I suppose I am alright with this way of handling it.

[ehelms]

Forgot the ACK

[komidore64]

would it be too far fetched to see about modifying foreman_tasks to look for an owner or a content-host?

is that prone to causing too many other problems?

[ehelms]

From what I saw in the code, Foreman tasks is looking specifically for 'Users' and properties of them. If you look at (https://github.com/theforeman/foreman-tasks/blob/781b7c58636e2fc96e1c7a43ec6c22271900f6e4/app/models/foreman_tasks/task.rb#L54) or search within the file you will see references to the User table. Further, I am not clear whether for search and some other what happens if a User no longer exists.

[komidore64]

you've successfully deterred me

[ehelms]

ACK

[komidore64]

updating commit message