Problem/Motivation
We can have a situation where a user creates a job but does not submit it, and another user submits it.
Right now in this case the owner will be the one that created it, while it should be the one that submitted it.
So, on submission we will switch the job owner.
Also, all interactions, also cron, will use the job owner.
And for continuous jobs we will allow to switch the owner when editing the job.
Proposed resolution
Remaining tasks
User interface changes
API changes
Data model changes
| Comment | File | Size | Author |
|---|---|---|---|
| #23 | interdiff-improve_job_owner-2675662-21-23.txt | 5.36 KB | edurenye |
| #23 | improve_job_owner-2675662-23.patch | 6.64 KB | edurenye |
| #21 | interdiff-improve_job_owner-2675662-19-21.txt | 1.48 KB | edurenye |
| #21 | improve_job_owner-2675662-21.patch | 7.36 KB | edurenye |
| #19 | interdiff-improve_job_owner-2675662-17-19.txt | 4.38 KB | edurenye |
Comments
Comment #2
edurenye commentedAlso we should discuss how it must work with continuous translations.
Comment #3
edurenye commentedChange the owner when submitting.
What we should do for continuous translators? Maybe set an owner to the job item?
Comment #4
miro_dietikerI remember that we discussed a week ago and came to the conclusion:
- On submission we will switch the job owner.
- All interactions, also cron, will use the job owner.
- For continuous jobs we will allow to switch the user when editing the job.
Please update the job summary properly.
Comment #5
edurenye commentedComment #6
edurenye commentedAdded allow to switch the user when editing the job for continuous jobs.
Comment #7
miro_dietikerYay! Near to a well defined job ownership situation.
That's quite some workaround and not a single comment about what you do. There's no better helper?!
You could check for if(in_array('authenticated', $roles))
And only do the array_keys and _combine if specific roles need to be filtered for.
Uh, this takes the first bracket, not the last.
Checkout EntityAutocomplete::extractEntityIdFromAutocompleteInput() how Drupal core properly matches this situation.
That reads like a strange position right in the middle of $message handling?
Comment #8
berdirThe function that miro mentioned is called automatically, just use the value in form state values, which is already checked and validated for you?
It's also quite likely that the value is already set and works without this because the form element is named after the field.
Comment #9
edurenye commentedFixed all comments by @miro_dietiker, about what @Berdir said, first I also thought that should work without this, but was not working, I don't know if I'm doing something wrong or I should add something else in the selection_settings.
Added tests.
Comment #11
miro_dietikerAs discussed, check setting a breakpoint inside validateEntityAutocomplete and figure out why the id extraction is not properly called.
Comment #12
edurenye commentedI added validated, not validate. Big mistake, it changed a lot.
Comment #14
edurenye commentedFixed the failing test, adding the missing permission.
Comment #15
miro_dietikerIf you really need this, then use empty($job->getOwnerId()) ? ...
Still, a User::load(0) should be possible for anonymous. Why as a special case?
Comment #16
berdirUser::load(NULL) wouldn't and the code explicitly avoids loading 0 and defaults to the current user instead. Which we could also do as a default value for that field, see how Node does it. Could still be 0 for existing jobs, though.
But the double check is indeed not needed because 0 == NULL, it will never go into the second condition.
Comment #17
edurenye commentedReverted this then.
Comment #18
miro_dietikerYou are implementing the feature that the job owner is switched on submission.
This needs specific test coverage.
Not sure if the current simple assert is enough for the continuous case or if we need to test submissions also.
Comment #19
edurenye commentedAdded tests for submission.
I think that with continuous we can ensure that the submission works assigning to another user that is not the one submitting, so I improved that.
Comment #21
edurenye commentedFixed the failing test.
Comment #22
berdirThis is too late. submitted() is called by the translator, *after* it was submitted. if the translator used the owner, then it used the old one.
Instead, set it in requestTranslation(), before calling the translator.
We could test this by adjusting the message in the test translator to include the owner. This might break some other tests though.
this is the wrong fix I think. Users that have administer tmgmt can also submit content. You will have to get roles that have either this or the other permission.
Comment #23
edurenye commentedDone.
Comment #25
berdirThanks, committed.
We might want to open an issue to consider actually showing the owner somewhere now that the value makes sense?
Job overview maybe?