Follow-up of #1416372: Translator Plugin: Local User
| Comment | File | Size | Author |
|---|---|---|---|
| #29 | local-allow-all-1876990-11.patch | 22.34 KB | blueminds |
| #28 | local-allow-all-1876990-11.patch | 22.34 KB | blueminds |
| #26 | local-allow-all-1876990-10.patch | 22.9 KB | blueminds |
| #25 | local_translator_settings.PNG | 28.27 KB | cgalli |
| #20 | local-allow-all-1876990-9.patch | 21.48 KB | blueminds |
Comments
Comment #1
berdirPatch with test coverage.
Comment #2
miro_dietikerOK, now we can submit even if there's no coverage...
Possibly the maintainer of the LUI system wants to take controle on that.. and NOT allo this to job creators.
So in this case of a SERVER using LUI accept only jobs that are covered by capabilities.
Or in case of LOCAL translation, we should be able to disallow users to submit such jobs.
I'm not sure if this should even be default...
Comment #3
berdirNot sure I follow you ;)
Job creators have no control over this, the admin who configures the translator does. The settings is added to the translator settings, not the checkout settings.
For now, I'm going to assume that these two persons are the same and even if not, it wouldn't change anything about the storage, we'd just need to expose it as a UI to the LUI manager.
The server should respect the languages returned by the translator, then this should just work.
I'm fine with defaulting this to on, but that will conflict with the auto-approve default value patch.
Comment #4
miro_dietikerOK, got it for the Local user translator creation. Thought it was a job checkout form...
Regarding server: We can followup on this once the server is ready again with the LUI.
Comment #5
berdirAh, now I understood what was confusing @cgalli about this.
The job validation considers the capabilities, so you could only submit the job if you had at least one user in your system that was able to translate that language.
The assign list, however, did not. It listed *all* translators, if they were able to translate the job or not. Added test coverage for that and fixed it in an ugly way because the capabilities API is so limited and functionality is mixed between skills and local modules. What's important is the test coverage, because it will allow us to refactor the implementation later on.
Comment #6
berdirUh, with patch.
Comment #7
cgalli commentedCnstalled the patch, works fine. Cannot assign jobs to users without the correct skills anymore, neither in the job checkout pane nor as the manager.
Something has happened to the design (see here)
There is still one case where the skills can be overridden. With the 'Administer translation tasks ' role I can assign jobs to myself, although I do not have the right skills. But that may be acceptable.
Comment #8
cgalli commentedThe broken interface was due to Internet Explorer (see #1889984).
Comment #9
blueminds commentedAdded functionality and test coverage for loading available translators for given tasks based on language skills. Please see the patch.
Comment #10
miro_dietikerI don't like this mix between strings and arrays here. We usually try to be type stable. PHP isn't always that friendly with such cases.
You have a disabled test in this patch :-)
Comment #11
blueminds commentedTotally agree with you, I am just using the design that is there. The tasks get passed via url as comma separated ints. I need to explode that string into array at certain point anyway so that I can use it as parameter for query builder.
This is not mine. I believe the test is not finished anyway.
Comment #12
berdirThat's my fault, the test should work though.
And yes, the explode is fine, passing a comma separted list through GET is way easier than as an array.
Comment #13
berdirOk.
While it's fine to pass it through as a string, we should be consistent internally and always convert it to an array. If you call explode(',', '1'), it will just return an array with a single value?
Then we can type hint $tasks to array here to be consistent with the @param.
Comment #14
blueminds commentedYes
So you suggest that all calls accepting $tasks should be able to accept string as well as an array?
Comment #15
berdirNo, the opposite.
The API function only accepts an array and ensures that with (array $tasks). The submit function makes sure that it converts $tasks to an array.
Comment #16
cgalli commentedInstalled and tested local-allow-all-1876990-6.patch
Within the local taks it works fine. one can only assign multiple jobs to translators with ALL the neccessary skills.
BUT the job checkout does not seem to work correctly. when checking out a job, the 'assign' dropdown lists translators lacking the needed skills.
New Issue? Or is it covered here?
Comment #17
blueminds commentedFixed
Comment #18
blueminds commentedsorry, wrong patch
Comment #20
blueminds commentedhmm, did diff between branches, apparently did not work.... this one should be okay though
Comment #21
cgalli commentedOk, works
Comment #22
berdirThis is unrelated.
The check here is not necessary. Make sure it's always an array.
If you add groupBy()/distinct() to the query then you don't need the condition in the foreach.
That or key by target language as well, then you don't need it either. But groupBy is probably the fastest option.
Test is still disabled, should not be the case.
I will fix and commit that myself once I find the time but feel free to update if you get to it before I do.
Comment #23
cgalli commentedRemark
The patch does work. It sets assignment filters correctly.
But it does not do what the title of the Issue says: Allow submitting of jobs even when the capabilities are not there yet (configurable)
Am I missing something?
Comment #24
berdirThere should be an option in the translator settings to enable that.
Comment #25
cgalli commentedHmm, I can't find them (see attachement)
Comment #26
blueminds commentedAdding patch with implemented comments.
@cgalli - there must be that setting. Please try to reapply the patch, or use the one attached to this comment.
Comment #28
blueminds commentedanother try...
Comment #29
blueminds commentedHmm, my last comment did not showed up... the patch is here though:
http://drupal.org/files/local-allow-all-1876990-11.patch
Comment #30
cgalli commentedNOW it works as advertised :-)
Comment #31
berdirCommited and pushed.
But I noticed this after I already pushed:
It needs to group on both target and source language, otherwise it will only return one record per target language.
And the if would then really be unecessary :)