Bug 7045 - Default-value substitution inconsistent
Summary: Default-value substitution inconsistent
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P5 - low normal (vote)
Assignee: Jonathan Druart
QA Contact: Bugs List
URL:
Keywords:
: 10294 (view as bug list)
Depends on:
Blocks: 17922
  Show dependency treegraph
 
Reported: 2011-10-17 14:11 UTC by D Ruth Holloway
Modified: 2019-11-29 06:42 UTC (History)
12 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Small patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Proposed patch (1.96 KB, patch)
2011-10-17 14:18 UTC, D Ruth Holloway
Details | Diff | Splinter Review
default value $z (71.54 KB, image/png)
2011-10-17 14:31 UTC, Nicole C. Engard
Details
default value $e (73.03 KB, image/png)
2011-10-17 14:31 UTC, Nicole C. Engard
Details
default value $d (67.64 KB, image/png)
2011-10-17 14:31 UTC, Nicole C. Engard
Details
item form with strange defaults (96.50 KB, image/png)
2011-10-17 14:32 UTC, Nicole C. Engard
Details
works on bib record (47.73 KB, image/png)
2011-10-17 14:43 UTC, Nicole C. Engard
Details
Bug 7045: Default-value behavior inconsistency (2.06 KB, patch)
2011-10-17 15:10 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review
New patch (2.53 KB, patch)
2011-10-17 15:22 UTC, D Ruth Holloway
Details | Diff | Splinter Review
New patch, minus a typo. (2.54 KB, patch)
2011-10-17 15:27 UTC, D Ruth Holloway
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 7045: Default-value behavior inconsistency (2.95 KB, patch)
2011-10-17 15:32 UTC, Nicole C. Engard
Details | Diff | Splinter Review
Bug 7045: Use <<tag>> for default value placeholders (3.93 KB, patch)
2016-08-16 08:20 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 7045: Update default value placeholders for existing installs (1.27 KB, patch)
2016-08-16 08:21 UTC, Jonathan Druart
Details | Diff | Splinter Review
Bug 7045: Use <<tag>> for default value placeholders (4.06 KB, patch)
2016-08-16 10:01 UTC, Marc Véron
Details | Diff | Splinter Review
Bug 7045: Update default value placeholders for existing installs (1.41 KB, patch)
2016-08-16 10:02 UTC, Marc Véron
Details | Diff | Splinter Review
[PASSED QA] Bug 7045: Use <<tag>> for default value placeholders (4.13 KB, patch)
2016-08-21 20:39 UTC, Katrin Fischer
Details | Diff | Splinter Review
[PASSED QA] Bug 7045: Update default value placeholders for existing installs (1.47 KB, patch)
2016-08-21 20:39 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description D Ruth Holloway 2011-10-17 14:11:02 UTC
If you supply a default value in a framework field, you may include YYYY, MM, DD, and user, to substitute for the year, month, day, and currently-logged-in username, respectively.

The downside of this is that the word "user" cannot be used in a default value for a note!

Patch coming shortly, to change the substitution to require USER, and to allow the use of YY to insert the last two digits of the year.
Comment 1 D Ruth Holloway 2011-10-17 14:18:43 UTC Comment hidden (obsolete)
Comment 2 Nicole C. Engard 2011-10-17 14:30:42 UTC
I need a bit more documentation on this patch as to how to test it.  One smart lady once told me that more details are always relevant.  See my screenshots that would make me fail this on QA - but I might be using it wrong.

Nicole
Comment 3 Nicole C. Engard 2011-10-17 14:31:08 UTC Comment hidden (obsolete)
Comment 4 Nicole C. Engard 2011-10-17 14:31:31 UTC Comment hidden (obsolete)
Comment 5 Nicole C. Engard 2011-10-17 14:31:50 UTC Comment hidden (obsolete)
Comment 6 Nicole C. Engard 2011-10-17 14:32:14 UTC Comment hidden (obsolete)
Comment 7 D Ruth Holloway 2011-10-17 14:36:27 UTC
USER only substitutes in the bib record, not in items, which is why you're not seeing it in items.  Otherwise, you're doing it right--not sure where those dashes are coming from on dates!

Try this in bib fields (e.g. notes) as well, since addbiblio.pl is also being modified.
Comment 8 Nicole C. Engard 2011-10-17 14:43:32 UTC
Created attachment 5927 [details]
works on bib record

Okay, this works on the bib record, but the item record has all kind of craziness that needs cleaning up.
Comment 9 Nicole C. Engard 2011-10-17 14:49:02 UTC
Let me define craziness. 

1. I entered YYYY-MM-DD as the default and it prints out as 2011-10-17--
2. I entered USER and it doesn't translate
3. I entered MM/DD/YY and it prints out //11
Comment 10 Nicole C. Engard 2011-10-17 14:49:53 UTC
Note to self: Make sure that the manual states that USER only shows the last name (unless that too is part of the craziness)
Comment 11 Jared Camins-Esakov 2011-10-17 15:10:16 UTC Comment hidden (obsolete)
Comment 12 Jared Camins-Esakov 2011-10-17 15:13:37 UTC
I did not realize that substitutions were supposed to work in items, too. My experience suggested that it only worked with biblios, and that's what I was signing off on. Please ignore my signed-off patch, and wait for the revised patch from Ruth.
Comment 13 D Ruth Holloway 2011-10-17 15:22:53 UTC Comment hidden (obsolete)
Comment 14 D Ruth Holloway 2011-10-17 15:23:24 UTC
As Nicole points out, this all works fine on biblio, but *not* on items--there was a problem with the way that the date was being created on items--I suspect that it wasn't working, ever, but this clears up a FIXME, because it now works correctly.

And yes, it is grabbing the surname of the logged in user, Nicole; that's as-designed.
Comment 15 D Ruth Holloway 2011-10-17 15:27:49 UTC Comment hidden (obsolete)
Comment 16 Nicole C. Engard 2011-10-17 15:32:27 UTC Comment hidden (obsolete)
Comment 17 Ian Walls 2011-10-17 16:00:29 UTC
I would think it would be more consistent to use <<YY>> and <<USER>> tokens, instead of raw strings.  This would reduce the likelihood of substitution mistakes dramatically, and be consistent with the tokens we use in Notices.

Also, I'm not positive that we should be governing individual subfield logic directly in the main code; a plugin would be more versatile with less risk of unintentional side effects.  Architecture already exists to connect these plugins to frameworks, and things like date formatted could be handled by the system-preference values.
Comment 18 Nicole C. Engard 2011-10-17 16:09:32 UTC
Ruth's patch just fixes a function that was already there and undocumented - I'd say we should submit another bug/patch to change the way it works if that's necessary, but a fix to the way it works now is necessary if people want to use the word 'user' in a default.
Comment 19 Paul Poulain 2011-10-18 16:26:07 UTC
My 2 cents :

> I would think it would be more consistent to use <<YY>> and <<USER>> tokens,
> instead of raw strings.  This would reduce the likelihood of substitution
> mistakes dramatically, and be consistent with the tokens we use in Notices.

==> I fully agree with Ian.

> Also, I'm not positive that we should be governing individual subfield logic
> directly in the main code;

==> partially agreeing, but Ruth patch fixes a bug, it's not an improvement, so it should be in another bug

QA comment:
 * what will be the behaviour for existing setups ? I feel they'll see their working user not working anymore (as we need USER) . It's worth a small updatedatabase with something like
"UPDATE marc_subfield_structure SET defaultvalue='USER' WHERE defaultvalue='user'"

Marking failed QA for now
Comment 20 Rocio Dressler 2016-04-29 16:46:43 UTC
Bug 10294 was submitted in regards to the word "user" needing to be used in the frameworks as a default value. I've just spoken with a library interested in displaying that text. Currently, that word is still transforming into the cataloger's last name.
Comment 21 Owen Leonard 2016-08-10 18:19:43 UTC
In master it still seems that the "user" placeholder works in the bibliographic editor but not the item editor, although instead of username the user's last name is used. The date placeholders work in both places.
Comment 22 Jonathan Druart 2016-08-15 15:20:42 UTC
1/ user will replace the field with the surname of the librarian, is it what we want?

2/ Should not we just remove this hidden feature as it does not exist in the manual?

3/ If we decide to keep it, let's
- use same code for add biblios and add items
- use "USER" or "<<USER>>" or whatever instead of "user"
- update existing installs

I can provide a patch if you reach a consensus.
Comment 23 Katrin Fischer 2016-08-15 20:46:07 UTC
It's hidden.. but I think not unused. I'd prefer 3). A placeholder like <<USER>> or similar that is unlikely to happen otherwise would work for me.
Comment 24 Marc Véron 2016-08-16 06:33:40 UTC
+1 for 3 with <<  >>
Comment 25 Jonathan Druart 2016-08-16 08:20:57 UTC Comment hidden (obsolete)
Comment 26 Jonathan Druart 2016-08-16 08:21:04 UTC Comment hidden (obsolete)
Comment 27 Jonathan Druart 2016-08-16 08:22:52 UTC
*** Bug 10294 has been marked as a duplicate of this bug. ***
Comment 28 Marc Véron 2016-08-16 10:01:49 UTC Comment hidden (obsolete)
Comment 29 Marc Véron 2016-08-16 10:02:35 UTC Comment hidden (obsolete)
Comment 30 Katrin Fischer 2016-08-21 20:39:13 UTC
Created attachment 54669 [details] [review]
[PASSED QA] Bug 7045: Use <<tag>> for default value placeholders

When adding a biblio, the default value of a MARC subfield defined in
the frameworks can be used as placeholders to set the current date or
the surname of the logged in user (use cases?).
The different placeholders are 'YYYY', 'MM', 'DD', 'user'.
When adding an item, same behavior except that 'user' is not replaced.

This patch makes behaviors consistent between the 2 editors and
surrounds placeholders with << >>
We will now have: <<YYYY>>, <<MM>>, <<DD>> and <<USER>>

Test plan:
Define default values for biblio and item subfields.
Create a bibliographic record and attach it an item.
The default values should be used and replaced if you used placeholders.

Signed-off-by: Marc Véron <veron@veron.ch>

Signed-off-by: Katrin Fischer  <katrin.fischer@bsz-bw.de>
Comment 31 Katrin Fischer 2016-08-21 20:39:41 UTC
Created attachment 54670 [details] [review]
[PASSED QA] Bug 7045: Update default value placeholders for existing installs

Signed-off-by: Marc Véron <veron@veron.ch>

Signed-off-by: Katrin Fischer  <katrin.fischer@bsz-bw.de>
Comment 32 Kyle M Hall 2016-09-02 15:20:55 UTC
Pushed to master for 16.11, thanks Jonathan!
Comment 33 Zeno Tajoli 2016-09-05 06:48:00 UTC
ATTENTION
The update in updatedatabase.pl for this patch (DBRev 16.06.00.016)
is wrong.
Instesad of 

update marc_subfield_structure set defaultvalue=REPLACE(defaultvalue, 'YYYY', '<<YYYY>>') where defaultvalue like "%YYYY%" and defaultvalue not like "%<<YYYY>>%";
update marc_subfield_structure set defaultvalue=REPLACE(defaultvalue, 'MM', '<<MM>>') where defaultvalue like "%MM%" and defaultvalue not like "%<<MM>>%";
update marc_subfield_structure set defaultvalue=REPLACE(defaultvalue, 'DD', '<<DD>>') where defaultvalue like "%DD%" and defaultvalue not like "%<<DD>>%";
update marc_subfield_structure set defaultvalue=REPLACE(defaultvalue, 'user', '<<USER>>') where defaultvalue like "%user%" and defaultvalue not like "%<<USER>>%";

I see:

 INSERT IGNORE INTO systempreferences (`variable`, `value`, `options`, `explanation`, `type`) VALUES ('OPACSuggestionMandatoryFields','title','','Define the mandatory fields for a patron purchase suggestions made via OPAC.','multiple');

It is the same of DBRev 16.06.00.017.

An error of RM ?
Comment 34 Katrin Fischer 2016-09-26 04:47:36 UTC
This appears to have been fixed now.
Comment 35 Frédéric Demians 2016-10-22 08:00:48 UTC
Pushed in 16.05. Will be in 16.05.05.
Comment 36 Julian Maurice 2016-10-24 09:31:58 UTC
Pushed to 3.22.x, will be in 3.22.12