As part of #965890: [meta] Revisit VersioncontrolAccount and bring it up to speed, and in much the same spirit as #223891: API change: make authentication management pluggable, the process by which raw VCS user data is mapped to a Drupal user needs to be made completely pluggable. There's two layers to this pluggability:
- Since the raw data is different from one VCS to the next, vcapi itself can at most define some shell logic (abstract methods, whatever), that the backends then fill out.
- The backends must, in implementing that vcapi-defined logic, be pluggable in that they should be able to send their raw data to some plugin that then responds with the uid/a user object/a VersioncontrolAccount object (or a FALSE or something), and we can then update corresponding operations with the uid.
We could probably have some simple plugins that live in vcapi itself - e.g., mapping based on {users}.mail.
Comments
Comment #1
sdboyer commentedtagging
Comment #2
marvil07 commentedComment #3
marvil07 commentedHere the first patch version mainly using all sdboyer ideas :-)
What needs to be done now: Actually call the plugin callbacks('map author' and 'map committer'). I did not added them because the mapping now is done while account class is executing its CRUD methods and IMHO this should be easier if we first try to get rid of account class. I'm not really sure where should be the right place to call the mapping callbacks.
So I will be opening another issue about that removal.
Another TODO here is fix the hook_update_N() I implemented to add default values at the update fro plugins field.
Comment #4
marvil07 commentedThe related issue I was going to open is on #983926: Remove account class
Comment #5
marvil07 commentedMinor updates to fix tests after applying the patch.
Comment #6
marvil07 commentedComment #7
sdboyer commentedLooks like this is coming along nicely. Very much like the code I'd been working on locally :) Some comments:
First big note is that there's no reason to use crappy procedural ctools plugins - oo plugins ftw :) They're a bit more of a pain to set up, but point you to examples, or just do it myself.
Second big thing is that we need to assume multiple plugins will be defined to attempt mapping. It's a good idea in general, but if #898816: Consider using real names and/or e-mail addresses for the author/committer metadata? goes the way I think it should, also completely necessary for d.o. That's gonna be fairly complicated, of course - we have to start worrying about plugin weighting and a UI to control the ordering - but still needs doing.
Only other thing that immediately jumped out at me was this:
From the first line of
public function determineUsers()- I'd ratherVersioncontrolRepositoryprovide a method for doing this, pulling the plugin out manually is a little awkward. Additionally, we can reduce the number of calls into ctools by caching the plugin locally on the repository object and masking it all behind a single method. Much cleaner.Comment #8
marvil07 commentedI'm going to try to make the plugin a oop plugin now.
Comment #9
marvil07 commentedOk, here an attempt to convert it to oop ctool plugin :-)
Comment #10
sdboyer commentedFair bit of refactoring & tweaking. Here's the list:
I'm ready to commit this, and probably will presently since I can't seem to find marvil07 on IRC :)
Two patches are attached, incremental diff vs. #9 and diff vs. mainline.
Comment #11
marvil07 commentedThis looks more clear ;-)
Comment #12
sdboyer commentedAaaand, committed. woohoo!
Comment #13
marvil07 commentedfor the record http://drupal.org/cvs?commit=458628
Comment #14
marvil07 commented:-/