[Bug 5572] New: refinements to function merge sub merge in C4::AuthoritiesMarc
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Summary: refinements to function merge sub merge in C4::AuthoritiesMarc Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: MARC Authority data support AssignedTo: gmcharlt@gmail.com ReportedBy: januszop@gmail.com QAContact: koha-bugs@lists.koha-community.org CC: ian.walls@bywatersolutions.com Estimated Hours: 0.0 Created attachment 2941 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=2941 Proposed patch When merging/editing authority records bibliographic records are to be corrected. This is done by merge from C4::AuthoritiesMarc. There has been a change in this function from 30 Sept./6 Oct. (commit e9c0a11d41f107425d7f53dcc09e57e3e00ee608) [between 3.2.0 beta and 3.2.0 RC] (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5264). The original behavior in 3.0 was: when authority has been changed, then in the corresponding fields in the bibliographic records all the subfields of such fields controlled by authority will be dropped and created anew with only subfields which have a value in the authority. The new behavior is much better: in the bibliographic record only subfields which have a value in the authority_to (the new authority) will be changed. BUT what there was a subfield present (with value) in authority (and in bibliographic) and the value is now deleted form authority? It will still stay in all bibliographic, whereas it should not. Hence my proposal: subfields not active in authority framework will be preserved; subfields active in the authority framework (i.e. controlled by this authority type) should be set as in the authority record - either have the value of corresponding subfield in authority or be empty. Regards, Janusz -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 januszop@gmail.com changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 |PATCH-Sent Status|NEW |ASSIGNED Patch Status|--- |Needs Signoff AssignedTo|gmcharlt@gmail.com |januszop@gmail.com -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl --- Comment #1 from M. de Rooy <m.de.rooy@rijksmuseum.nl> 2011-01-13 13:20:02 UTC --- Tested your patch: it works as described. I see your point when you should clear a subfield at the authority side and you want to see the same at the biblio side. [How often would that happen?] However, if the subfield was already empty at the authority side and you update the auth record, do you also want to clear at that moment any possible info in that subfield at the biblio side? Does an empty authority subfield that is "not in the ignore tab" in the framework, really mean that that subfield should always be empty too at the biblio side? I am not sure about that; I will copy this comment to the Koha list for possible further discussion. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #2 from januszop@gmail.com 2011-01-13 16:19:10 UTC --- (In reply to comment #1)
Tested your patch: it works as described. I see your point when you should clear a subfield at the authority side and you want to see the same at the biblio side. [How often would that happen?]
Well, me myself was not convinced that it happens and that such a refinement is is necessary--it was the library staff that told me it really happens sometimes and demanded to make Koha to behave like described in the proposal. It does not happen often perhaps, but if it happens then the staff would have to edit even hundreds of biblio records by hand without this refinement.
However, if the subfield was already empty at the authority side and you update the auth record, do you also want to clear at that moment any possible info in that subfield at the biblio side?
Yes, because I was told this exactly means that the set of subfields of a field in biblio is *controlled* by the authority record. In other words, if a subfield can have a value in authority (in Koha: it is not in 'ignored' state), then you are not supposed to edit it by hand in biblio. I do not know if it is really so--I was told that.
Does an empty authority subfield that is "not in the ignore tab" in the framework, really mean that that subfield should always be empty too at the biblio side? I am not sure about that; I will copy this comment to the Koha list for possible further discussion.
At least this is what I was told. This means of course that with my refinement you have to carefully check which subfields are active in the authority framework, in order not to delete what you do not intend to. I will appreciate any comments. For now this is what was needed in my library. I thought it worth to share this with others. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #3 from januszop@gmail.com 2011-01-25 19:20:51 UTC --- I am still thinking about my previous proposal. Had some doubts, but I still think it should be OK. Even in case of PERSO_NAME (in MARC 21) for instance. In fact this authority comes in two flavors: author and author/uniform title. So, if you will have empty (but active) 100$t in the author-flavored version of the authority record for instance, there is nothing bad if the procedures attempts to delete $t in some 700, since it should be empty... I really try, but still cannot find cons for the proposal ;) -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 stephane.delaune@biblibre.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |stephane.delaune@biblibre.c | |om --- Comment #4 from stephane.delaune@biblibre.com 2011-04-06 13:13:37 UTC --- This patch conflicts with patch bug 5943. It just changes the sub merge C4::AuthoritiesMarc::merge which is only used by function C4::AuthoritiesMarc::ModAuthority if (C4::Context->preference('MergeAuthoritiesOnUpdate') ). This syspref does not exist by default. So it makes me doubt the relevance of this patch -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #5 from januszop@gmail.com 2011-04-06 13:29:22 UTC --- I am wondering--and how then about the merge_authority.pl script (it makes use of C4::AuthoritiesMarc::merge), which in turn should be executed (as cron job for example, if I understand well) if MergeAuthoritiesOnUpdate is off (which is the default)...? -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #6 from M. de Rooy <m.de.rooy@rijksmuseum.nl> 2011-04-06 13:30:49 UTC --- Commit 928905570305d8ace24e4deba03a17bbe95774c2 appears to introduce this problem: @@ -646,7 +649,9 @@ sub ModAuthority { ### If a library thinks that updating all biblios is a long process and wishes ### they should have a system preference "dontmerge=1" otherwise by default bib ### the $merge flag is now depreceated and will be removed at code cleaning - if (C4::Context->preference('dontmerge') ){ + if (C4::Context->preference('MergeAuthoritiesOnUpdate') ){ -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #7 from M. de Rooy <m.de.rooy@rijksmuseum.nl> 2011-04-06 13:33:10 UTC --- I guess the new pref should be added and set based on the older dontmerge option. Should be FIXED! -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #8 from M. de Rooy <m.de.rooy@rijksmuseum.nl> 2011-04-06 14:50:57 UTC --- (In reply to comment #7)
I guess the new pref should be added and set based on the older dontmerge option. Should be FIXED! Opening bug 6094 for this one.
-- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #9 from M. de Rooy <m.de.rooy@rijksmuseum.nl> 2011-04-07 08:32:04 UTC --- januszop or stephane: I submitted a patch for 6094. Could you have a look please? Thanks. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #10 from januszop@gmail.com 2011-04-07 15:25:48 UTC --- Marcel, because of my other commitments I wouldn't be able to jump into Koha coding thing before Monday, though I looked through your changes -- it looks fine for me. The only concern I have -- do you think it is a good idea to put authid memo files into general /tmp subdirectory which can be purged beyond your control? -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #11 from M. de Rooy <m.de.rooy@rijksmuseum.nl> 2011-04-08 17:44:54 UTC --- (In reply to comment #10)
Marcel, because of my other commitments I wouldn't be able to jump into Koha coding thing before Monday, though I looked through your changes -- it looks fine for me. The only concern I have -- do you think it is a good idea to put authid memo files into general /tmp subdirectory which can be purged beyond your control? Janusz, I copy this comment to 6094 and reply there.
-- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |6094 -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #2941|0 |1 is obsolete| | --- Comment #12 from Janusz Kaczmarek <januszop@gmail.com> 2011-07-24 16:19:47 UTC --- Created attachment 4730 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=4730 A safer varsion of previous patch -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Stefano Bargioni <bargioni@pusc.it> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bargioni@pusc.it --- Comment #13 from Stefano Bargioni <bargioni@pusc.it> 2011-09-28 15:16:52 UTC --- If I'm not wrong, no words were spent about indicators. They must be propagated in most cases, but we need to observe MARC specifications. For instance, in MARC21 the # of nonfiling characters for tag 130 auth is stored in ind2, while it is stored in 130 bib ind1. And 730 auth doesn't have the nonfiling characters, that is present in 730 bib ind1. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #14 from Janusz Kaczmarek <januszop@gmail.com> 2011-09-28 15:54:12 UTC --- (In reply to comment #13)
If I'm not wrong, no words were spent about indicators. They must be propagated in most cases, but we need to observe MARC specifications. For instance, in MARC21 the # of nonfiling characters for tag 130 auth is stored in ind2, while it is stored in 130 bib ind1. And 730 auth doesn't have the nonfiling characters, that is present in 730 bib ind1.
You are perfectly right. But this is beyond the scope of this patch. But, to make things clear, when updating the controlled field in biblio records the merge function preserves the old indicators from biblio record. At this stage, it does not copy nor makes any use of the indicators stored in the authority record. This had to be still implemented. BTW, you could also have a look at Bug 5262. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #15 from Stefano Bargioni <bargioni@pusc.it> 2011-10-13 11:04:30 UTC --- I tested the latest patch (attachment 4730) in Koha 3.2.3 and 3.2.7 (production environment). It works. Two little questions: I changed $marcrecord->insert_grouped_field($field_to); with $marcrecord->insert_fields_ordered($field_to); This will avoid that a modified 700, for instance, will be placed at its correct place and not after every 7xx field, like 740. The second one is the performance: if the change involves hundreds of biblios, it is very slow and a web server timeout can occurr. I hope to test the patch in Koha 3.4.4 ASAP. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Paul Poulain <paul.poulain@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|rel_3_2 |Rel_3_8 --- Comment #16 from Paul Poulain <paul.poulain@biblibre.com> 2011-10-24 11:38:10 UTC --- Updating Version : This ENH will be for Koha 3.8 -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Paul Poulain <paul.poulain@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|Rel_3_8 |master --- Comment #17 from Paul Poulain <paul.poulain@biblibre.com> 2011-10-25 15:05:43 UTC --- Bug versionned for master. entries will be made against rel_3_8 once the patch has been applied (see thread about that on koha-devel yesterday) -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch Status|Needs Signoff |Does not apply --- Comment #18 from M. de Rooy <m.de.rooy@rijksmuseum.nl> 2011-11-30 14:43:14 UTC --- Applying: Changes to sub merge in C4::AuthoritiesMarc to refine authorities merging -- safer version error: patch failed: C4/AuthoritiesMarc.pm:1315 error: C4/AuthoritiesMarc.pm: patch does not apply fatal: sha1 information is lacking or useless (C4/AuthoritiesMarc.pm). Repository lacks necessary blobs to fall back on 3-way merge. Cannot fall back to three-way merge. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Bug 5572 depends on bug 6094, which changed state. Bug 6094 Summary: Fixing ModAuthority problems http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6094 What |Old Value |New Value ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #4730|0 |1 is obsolete| | --- Comment #19 from Janusz Kaczmarek <januszop@gmail.com> 2012-01-20 20:50:22 UTC --- Created attachment 7264 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=7264 A revised version of the previous patch An "upgraded" version of the patch -- now applies smoothly to master (as on 20th Jan. 2012) -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Jared Camins-Esakov <jcamins@cpbibliography.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jcamins@cpbibliography.com --- Comment #20 from Jared Camins-Esakov <jcamins@cpbibliography.com> --- (In reply to comment #2)
(In reply to comment #1)
Tested your patch: it works as described. I see your point when you should clear a subfield at the authority side and you want to see the same at the biblio side. [How often would that happen?]
Well, me myself was not convinced that it happens and that such a refinement is is necessary--it was the library staff that told me it really happens sometimes and demanded to make Koha to behave like described in the proposal. It does not happen often perhaps, but if it happens then the staff would have to edit even hundreds of biblio records by hand without this refinement.
However, if the subfield was already empty at the authority side and you update the auth record, do you also want to clear at that moment any possible info in that subfield at the biblio side?
Yes, because I was told this exactly means that the set of subfields of a field in biblio is *controlled* by the authority record. In other words, if a subfield can have a value in authority (in Koha: it is not in 'ignored' state), then you are not supposed to edit it by hand in biblio. I do not know if it is really so--I was told that.
I do not think this is correct. Subfield 'e' is not authority-controlled, but Koha treats all non-numeric subfields in authority-controlled fields as if they are. Or am I misunderstanding what this bug does, and there is a workaround for this?
Does an empty authority subfield that is "not in the ignore tab" in the framework, really mean that that subfield should always be empty too at the biblio side? I am not sure about that; I will copy this comment to the Koha list for possible further discussion.
At least this is what I was told. This means of course that with my refinement you have to carefully check which subfields are active in the authority framework, in order not to delete what you do not intend to.
I will appreciate any comments. For now this is what was needed in my library. I thought it worth to share this with others.
-- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|PATCH-Sent (DO NOT USE) |P3 QA Contact|koha-bugs@lists.koha-commun | |ity.org | --- Comment #21 from M. de Rooy <m.de.rooy@rijksmuseum.nl> --- Patch still applies. But I still have my doubts on clearing subfields on the biblio side for an empty authority subfield. This may theoretically be true, but could result in data loss when used without enough care. I will retry to get more feedback from the list. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 M. de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |In Discussion -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #22 from Janusz Kaczmarek <januszop@gmail.com> --- (In reply to comment #20)
I do not think this is correct. Subfield 'e' is not authority-controlled, but Koha treats all non-numeric subfields in authority-controlled fields as if they are. Or am I misunderstanding what this bug does, and there is a workaround for this?
OK, the action of the modified merge procedure is based on "Select to display or not" (i.e. auth_subfield_structure.hidden) and of course one has to be cautious about it. If a subfield of the heading is hidden in authority editor == it not supposed to be controlled == will never be overwriten. This would be the case of auth. 100 applied on biblio. 700 with $e present. $e will stay untouched provided it is not active in the authorities framework. Why I now think it is really important: a very common case for my libraries (participating in a cooperative cataloguing program) are personal headings with duplicated family name + surname. So, if the librarian who creates the entry does no know the dates, he/she adds a qualifier like $c. But then another librarian who found the dates (maybe after some months or even years) exchanges $c for $d in the authority data. Now, without this enhancement you will have $c and $d in bibliographic records, which is what you don't want. Another reason is the case when wrongly entered data was propagated to several dozens of biblio recs. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Janusz Kaczmarek <januszop@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #7264|0 |1 is obsolete| | --- Comment #23 from Janusz Kaczmarek <januszop@gmail.com> --- Created attachment 18387 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=18387&action=edit Proposed patch - refreshed Applies smoothly to master (as on 24th May 2013) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Jonathan Druart <jonathan.druart@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@biblibre.co | |m See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=5943 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Martin Renvoize <martin.renvoize@ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com --- Comment #24 from Martin Renvoize <martin.renvoize@ptfs-europe.com> --- Can anyone comment as to whether this bug is still relevant in the upcoming 3.16 release? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #25 from Janusz Kaczmarek <januszop@gmail.com> --- Yes, it is. In ver. 3.16.00, sub merge still does not remove from header fields in biblio those controlled subfields that has been removed from associated authority record. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Rafal Kopaczka <rkopaczka@afm.edu.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rkopaczka@afm.edu.pl -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Jacek Ablewicz <abl@biblos.pk.edu.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |abl@biblos.pk.edu.pl -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #26 from Jacek Ablewicz <abl@biblos.pk.edu.pl> --- Nice patch, quite usefull for our library particular needs as well.. Would it be possible to make this feature controllable by e.g. some system preference (= disabled by default)? I have a feeling that chances for reaching any agreement whenever such change would be "universally" good, or not good, are close to nil; there are way too many different habits, approaches etc. in various libraries regarding authority editing nad maintaining. But, I believe that as long as this patch: - does not by default introduce any changes to the existing behaviour, - libraries willing to use it are made aware (e.g. by some kind of remark in syspref description) that they should carefully review their existing authority frameworks before enabling this feature, to prevent any possible "data loss" in authority-controlled biblio fields, all concerns indicated in previous comments will be sufficiently (?) addressed, so it could hopefully get a promotion from "In Discussion" to "Needs Signoff" ;). -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Fridolin SOMERS <fridolyn.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=11315 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Jacek Ablewicz <abl@biblos.pk.edu.pl> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=14583 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Frédéric Demians <frederic@tamil.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |frederic@tamil.fr --- Comment #27 from Frédéric Demians <frederic@tamil.fr> --- Janusz, do you still use your patch for your library? Have you seen bug 14583? IMO your patch is required in master. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Frédéric Demians <frederic@tamil.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Frédéric Demians <frederic@tamil.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #18387|0 |1 is obsolete| | --- Comment #28 from Frédéric Demians <frederic@tamil.fr> --- Created attachment 44610 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=44610&action=edit Bug 5572 Improve C4::AuthoritiesMarc->merge() function A new syspref AuthCleanBiblios allows to control how modified info in a modified authority are propagated to the attached biblio records. By default, the merge() behavior isn't changed. When AuthCleanBiblio is set to yes, the subfields of the authority heading are copied to biblio field. If the biblio field contains subfields that are not anymore in the authority, they are removed (this is true only for the authority subfields that are neither ignored nor hidden in the authority editor) This patch do some code refactoring: - New function C4::AuthoritiesMarc::GetBibliosByAuthid - New function C4::Biblios::GetBiblionumber($record) - Minimizing SQL queries, and caching -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Frédéric Demians <frederic@tamil.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #44610|0 |1 is obsolete| | --- Comment #29 from Frédéric Demians <frederic@tamil.fr> --- Created attachment 44628 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=44628&action=edit Bug 5572 Improve C4::AuthoritiesMarc->merge() function A new syspref AuthCleanBiblios controls how modified info in a modified authority are propagated to the attached biblio records. By default, the merge() behavior isn't changed. When AuthCleanBiblio is set to yes, the subfields of the authority heading are copied to biblio field. If the biblio field contains subfields that are not anymore in the authority, they are removed (this is true only for the authority subfields that are neither ignored nor hidden in the authority editor) This patch does some code refactoring: - New function C4::AuthoritiesMarc::GetBibliosByAuthid - New function C4::Biblios::GetBiblionumber($record) - Minimizing SQL queries, and caching - Code cleaning + doc http://bugs.koha-community.org/show_bug.cgi?id=1572 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Frédéric Demians <frederic@tamil.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=14560 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Frédéric Demians <frederic@tamil.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Patch complexity|--- |Small patch -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Frédéric Demians <frederic@tamil.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #44628|0 |1 is obsolete| | --- Comment #30 from Frédéric Demians <frederic@tamil.fr> --- Created attachment 45515 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=45515&action=edit Bug 5572 Improve C4::AuthoritiesMarc->merge() + syspref AuthCleanBiblios A new syspref AuthCleanBiblios controls how modified info in a modified authority are propagated to the attached biblio records. By default, the merge() behavior isn't changed. When AuthCleanBiblios is set to yes, the subfields of the authority heading are copied to biblio field. If the biblio field contains subfields that are not anymore in the authority, they are removed (this is true only for the authority subfields that are neither ignored nor hidden in the authority editor) This patch does some code refactoring: - New function C4::AuthoritiesMarc::GetBibliosByAuthid - New function C4::Biblios::GetBiblionumber($record) - Minimizing SQL queries, and caching - Code cleaning + doc -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Frédéric Demians <frederic@tamil.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|januszop@gmail.com |frederic@tamil.fr -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Frédéric Demians <frederic@tamil.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|refinements to function |Improve |merge sub merge in |C4::AuthoritiesMarc->merge( |C4::AuthoritiesMarc |) + syspref | |AuthCleanBiblios -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #45515|0 |1 is obsolete| | --- Comment #31 from Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> --- Created attachment 45821 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=45821&action=edit [SIGNED-OFF] Bug 5572: Improve C4::AuthoritiesMarc->merge() + syspref AuthCleanBiblios A new syspref AuthCleanBiblios controls how modified info in a modified authority are propagated to the attached biblio records. By default, the merge() behavior isn't changed. When AuthCleanBiblios is set to yes, the subfields of the authority heading are copied to biblio field. If the biblio field contains subfields that are not anymore in the authority, they are removed (this is true only for the authority subfields that are neither ignored nor hidden in the authority editor) This patch does some code refactoring: - New function C4::AuthoritiesMarc::GetBibliosByAuthid - New function C4::Biblios::GetBiblionumber($record) - Minimizing SQL queries, and caching - Code cleaning + doc Signed-off-by: Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> Tested with dontmerge on/off, AuthCleanBiblioson/off Work as described Few errors fixed in folloups -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #32 from Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> --- Created attachment 45822 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=45822&action=edit Bug 5572: (follow-up) atomic update -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #33 from Bernardo Gonzalez Kriegel <bgkriegel@gmail.com> --- Created attachment 45823 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=45823&action=edit Bug 5572: (follow-up) fix koha-qa errors -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Frédéric Demians <frederic@tamil.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |15381 Referenced Bugs: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15381 [Bug 15381] Move the authority types related code to Koha::Authority::Type[s] - part 2 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #34 from Frédéric Demians <frederic@tamil.fr> --- Bugs 15380 and 15381 should be pushed to master before refactoring this one to use new authorities related classes. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Frédéric Demians <frederic@tamil.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Failed QA -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #35 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- (In reply to Frédéric Demians from comment #34)
Bugs 15380 and 15381 should be pushed to master before refactoring this one to use new authorities related classes.
This can be pushed before the refactoring, I will rebase bug 15381 if needed. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Frédéric Demians <frederic@tamil.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|15381 | Status|Failed QA |Signed Off --- Comment #36 from Frédéric Demians <frederic@tamil.fr> --- (In reply to Jonathan Druart from comment #35)
(In reply to Frédéric Demians from comment #34)
Bugs 15380 and 15381 should be pushed to master before refactoring this one to use new authorities related classes.
This can be pushed before the refactoring, I will rebase bug 15381 if needed.
OK thanks. So I reset this patch to signed-off. And let see which patch will be pushed first. Referenced Bugs: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15381 [Bug 15381] Move the authority types related code to Koha::Authority::Type[s] - part 2 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Patch doesn't apply --- Comment #37 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- This patch set does not apply anymore. We will need tests here, the merge functionality is completely unstable at the moment and it seems dangerous to continue without good basis. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=15358 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5572 --- Comment #38 from Frédéric Demians <frederic@tamil.fr> --- (In reply to Jonathan Druart from comment #37)
This patch set does not apply anymore. We will need tests here, the merge functionality is completely unstable at the moment and it seems dangerous to continue without good basis.
Bug 15358 need to be fixed before doing anything here. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org