separate fieldsets for different contributor types?

I see where you are coming from, although I'm not sure separating them by "type" is such a good idea since just recently someone told me that the mix types within the same author string. I think all that's really required is the ability to make individual author types "required" or not. Now the question is how to best accomplish this.... Have to think on it a bit.

Ron.

So if I understand correctly, your proposal would do away with the author "Type" select box and use the fieldset to indicate the author type?

There is another major problem with the current design: If you change the auth_type of a contributor field (in admin/settings/biblio/types/edit/%tid) having authors defined with the previous auth_type, these authors will not be displayed anymore, neither in the input form nor in the view

I just tested this and the existing authors did not disappear, and in the edit form, they still had the same (old) designation. Could you give me the steps you used to produce this problem as it is indeed quite serious if it is reproducible.

Ron.

Ok, I see that behavior now. Strangely, it doesn't happen on node that I imported from a file, only ones created from the form. I'll have to dig a bit deeper...

I found the problem, but I don't have a solution yet... Changing the auth_type on admin/settings/biblio/types/edit/%tid updates auth_type in biblio_contributor_type but auth_type in biblio_contributor remains unchanged. This would require going through the biblio_contributor table and finding the entries with biblio_type=tid and auth_type = old_auth_type updating the auth_type to the new value.

I'm seriously questioning the wisdom of relating author types with publication types, as this is the root of the problem.

Your right updating all the auth_type entries in biblio_contributor is probably not the intent, another perhaps simpler approach might be to just add the auth_catagory column to biblio_contributor then each publication could retain it's original author information regardless of what the default is set to. It would also simplify the author lookups since you wouldn't need any joins on the biblio_contributor_type table and you wouldn't need to know the publication type.

I'm not sure what you mean by "Is it possible to change the format of this obsolete entry?", could you elaborate?

I just tried this version and my authors still disappear (from the citation display) when the type is changed. Although they are still visible in the edit form. This is because I am using the auth_category in "style" file _format_authors() function.

I'm still thinking that adding auth_category column to the biblio_contributor table might be the solution, because then all the needed to classify the author is attached to each author entry. Right now only half the information is attached to the entry and I'm getting the other half from the publication type, but as we have seen that can change after a publication has been entered.

Also looking at this a bit more, the semantics may be a bit misleading, so just for clarification... "auth_type" is really just the category label. There are 5 categories of authors and and depending on the publication type, the category can assume a different name or label. i.e. a secondary author of a book could be called something different from a secondary author of a journal.

And lastly... I just noticed that I spelled category wrong in the db column name! DOH!

I tried adding duplicating the auth_catagory column in the biblio_contributor table and this does eliminate the problem completely.

I just created a new column called auth_catagory (sic) and used this SQL to copy the data...

UPDATE   biblio b
inner join biblio_contributor bc on b.vid = bc.vid
left join biblio_contributor_type bct on b.biblio_type = bct.biblio_type and bct.auth_type = bc.auth_type
set bc.auth_category=bct.auth_catagory

Then changed bct.auth_catagory to bc.auth_catagory in

>
function biblio_load_contributors($vid, $biblio_type) {
  $contributors = array();
  $query = "SELECT bcd.*, bc.auth_catagory,  bc.auth_type, bc.rank 
...
<

Your right, there is a 1:1 correspondence of catagory (field) and type (label) linked through biblio_type, however removing auth_type from biblio_contributors we will still have the problem of existing author types being changed when the global default is changed. In a nut shell, the biblio_contributor_type table is used to select which author types show up in the select box on the input form (the UI) and the biblio_contributor table links biblio entries with contributors (the actual data). The problem (disappearing authors) arose from mixing these differently purposed tables.

I hadn't fully modified all the code yet, but the intent was to use both auth_catagory and auth_type from biblio_contributors, not through linking with other tables thus once these values are set for a given author on a particular publication, they would not change. I'm going to make these changes in HEAD so you can see what I mean.

Ok, so assuming we have 5 different "groups" (fieldsets) of authors, what would these groups be called and how would these different groupings be utilized? I think these fieldsets would have to have some kind of name in order for the user to understand what they are for.

I "fixed" the issue of carrying the auth_category with the auth_type, by concatenating them, so the select box in the contrib widget has a string value rather than a single integer (auth_type). For example the select used to return a value of 1 is Author was selected, now it will return a value of 1:1 meaning auth_type=1 and auth_category=1, this way the values can be carried throughout the process.

The other option which you mention and I was also thinking of is to add a second select box for auth_category which might help to disambiguate this for the user. Alternatively, the category (role) (Primary, Secondary, etc.) could be added to the title in the existing select box to give a better indication of what these "titles" represent. i.e. "Author (Primary) " "Series Editor (Secondary)"

I would really like to put this one to rest, so I'll craft the "multi-fieldset" option and see what that looks like

Ron.

Thanks for that cleanup, especially that update in the install file (I must have been half asleep when I did that). I've done some experiments and I don't think the multi-fieldset option is going to be a big deal mostly just some updates to the database since once those new "fields" (contrib_widgets) are defined in the db, they just magically appear on the form ;-)

Of course there will be a few little tweaks in the form processing code, but it shouldn't be too bad (famous last words).

Ron.

OK, so I updated the biblio.field.link.data.csv file and the biblio.update files, now if you go to "admin/settings/biblio/types" and click the "Reset all types to defaults" button it will update the database with the new contrib_widget definitions. This is destructive (drops 'biblio_field_type_data', 'biblio_field_type' 'biblio_fields', 'biblio_contributor_type'& 'biblio_contributor_type_data' tables) so don't do it if you have any data you don't want to lose. Once this is done, the new widgets will show up on the input form.

I haven't done any of the form processing work yet, but it gives you and idea of what it will look like. I'm quitting for the night.

Cheers,

Ron.

I tried the "author merge", that does the trick, however in terms of usability it may leave a little to be desired... For instance I had one author who had 5 different entries, now before merging, I wanted to look at each to decide which had the most complete data and then merge the others with it. In order to do that I had to keep going back to the author page and selecting the other similar author. What I was thinking was that if these were check boxes rather than a select list, you could make the name a hyperlink to the author-edit form so you could just click on one of the names in the merge list and you would be transported to the edit form for that version of the author, that way you could hop between similar authors without going back to the author page.

I took the liberty of changing the "author merge" select list to check boxes with links. Try it out with an author who has more than a few variations and I think you will find this format easier to use.

Ron.

I've been debating as to whether orphaned authors should be removed or not. I currently have such a thing in biblio_delete() which removes orphans, however I've been thinking that perhaps someone might want to pre-populate the database with all the faculty members so something like that which would allow the autocomplete on the form to work more effectively. So I'm thinking of leaving orphans in. What do you think?

Excellent, do you want to do that or shall I?

And yes, the author purging would have to be removed from biblio_delete for obvious reasons.

BTW, I forgot to mention, if your wondering what the status of the multi-fieldset authors is... I have discovered an issue in parsing those .csv files, after adding the definitions for the new fields, the various author types are no longer stored in the biblio_contributor_type_data table. Given the fragility and ugliness of this code, I'm looking at alternatives (XML) for reading in this data.

The issue I'm referring to is in the install file function _add_custom_field_data(). It reads a file called biblio.field.type.data.csv which contains the "auth_type" definitions for the various publication types and this is not functioning correctly after adding the extra contributor fields to biblio.field.link.data.csv.

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