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

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.

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.

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

Note to self: Make sure that the manual states that USER only shows the last name (unless that too is part of the craziness)

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.

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.

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.

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.

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

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.

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.

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.

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.

+1 for 3 with <<  >>

*** Bug 10294 has been marked as a duplicate of this bug. ***

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>

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>

Pushed to master for 16.11, thanks Jonathan!

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 ?

This appears to have been fixed now.

Pushed in 16.05. Will be in 16.05.05.

Pushed to 3.22.x, will be in 3.22.12