1. We have imported a stack of citations. Biblio built a list of authors. There were lots of variant author name forms. as usual. We left thjese for the moment.
2. We imported a stack of users and started training them on how to use Biblio. Task #1 was for them to assoicate themselves with a Biblio author, which they did. Task two was to merge the author variants, which they did.
3. Now, when my author James Q Zimble logs in and chooses to create a new citation, he starts to enter Zim.. in the author field and is greeted with an auto-complete: Zimble, JQ, which he selects, and publishes.
4. Biblio, however, has created a new author, same name, no Drupal user association. We have repeated this behaviour on multiple users.
5. What are we doing wrong?
Thanks in advance!

Comments

rjerome’s picture

In a few quick tests, I have not been able to reproduce this issue. One thing I can tell you is that if the user makes ANY changes to the author name provided by the auto-complete, then a new author will be created.

mreggie’s picture

We have the exact same problem at our site, for multiple users. Testing shows that using the auto-complete as-is will still result in a new author being created. Further new publications are all linked to this new author. After the authors are merged (to the original author), this all happens again. Some users seem not have this problem at all while others seem to have it with every new publication.

For some authors, the name fields (first, last, complete name) have been updated to better reflect the actual author details (e.g. complete first name, initials and prefix) and the complete name format that that user prefers, and local authors have been linked to their Drupal user ID. That is the reason that we merge newly creator authors to the "original" author. It is not yet clear if authors that have been manually edited are more, less or equally affected by this problem, and the same is true for complete names with only initials + last name versus only firstname + lastname (or a mix of the two). (With 100+ users and 1000+ authors it is impossible to keep track.)

I could be wrong, but it seems that (1) the biblio form does not keep track of the author IDs for the auto-completed authors, (2) the name parser does not recognize auto-completed authors as that (existing authors), (3) the name matching algorithm is not able to reliably match names to existing identical "complete names", and (4) no check is being done for an existing identical author when the new author is added.

Are the "complete names" taken into account in the name matching process? If so, why are the names not being matched?
Are any of the steps 1, 2 or 4 considered to make the system more robust?

Step 4 would also be very nice for manually entered names, considering all possible different ways to enter a name. In that case, some user input would probably be required; maybe an intermediate step after the parsing of the form where the user is presented a list of possible matches (based on the same algorithm that is already used to find merge candidates?).

rjerome’s picture

Thanks for the input on this. It's still a bit of a mystery (why some and not others), but your details may provide some clues and I will do further testing...

Stay tuned.

Ron

mreggie’s picture

This is getting really annoying. Even only adding an attachment causes duplicate author entries to be created. Again, some authors are affected and others are not.

I still have 400 attachment to (manually) add to existing publications, so a fix would be really appreciated...

rjerome’s picture

That is very strange, just attaching a file really should not be generating new users. It would be helpful if you could do the following query on your database for me using the nid of one of the entries that generates new authors when attaching files...

"SELECT * FROM biblio_contributor bc
      INNER JOIN biblio_contributor_data bcd ON bc.cid=bcd.cid
      WHERE bc.nid=SUSPECT_NID
      ORDER BY bc.rank ASC"

replacing "SUSPECT_NID" with the actual integer node id value.

If you don't want to publicly post the data, contact me via my contact page and we can do this via email.

rjerome’s picture

OK, disregard that last request, I think I finally got this one nailed. It was related to editing the "Complete Name" field in the author edit form, the md5 checksum for the author was not being updated when this was changed.

Unfortunately, this still may happen on authors you have already edited, but it shouldn't happen on new edits. If this is a problem, I could probably craft an "update" which would go through and refresh all the checksums.

Ron.

http://drupalcode.org/project/biblio.git/commit/dbdc5aa

mreggie’s picture

Sorry for getting back to you so late (I should check here more often).
I can confirm that the fix seems to work (for the one author that I tried).
It does require some manual labor now (merging the authors one last time), so an automatic update (run as part of update.php?) would be nice. It would also be nice for all those not aware of this thread, because they will very likely not trigger the md5 update and be stuck with this problem.

Anyway, thanks for the fix!

mreggie’s picture

I just noticed that after the upgrade to the git version specified above the biblio_views 'Filter by Author ID' view is no longer working: in the 'Arguments' section the error 'Broken/missing handler: biblio_contributor > cid' is displayed. The 'biblio_handler_argument_many_to_one' handler is missing.

agil’s picture

Hi,

We are experimenting the same problem, without the fix/commit.

We've just updated our biblio installation but I've seen that this fix is not there... why?
Is this fix/commit planned to be part of any comming release?
Do you recommend to apply the patch manually?

Thank you very much for the biblio module!!

Albert

liam morland’s picture

Issue summary: View changes
Status: Active » Closed (outdated)

This version is no longer maintained. If this issue is still relevant to the Drupal 7 version, please re-open and provide details.