Editing EPrints 3.4.3 (section)

=== Known Issues ===
==== Multiple values not supported by EPrints::MetaField::Date validate function ====
The <code>validate</code> function of <code>EPrints::MetaField::Date</code> does not support multiple values like is used in [https://bazaar.eprints.org/449/ Dates, Dates, Dates] Bazaar plugin. [[:File:MetaField-Date-validate.patch|This patch]] fixes this issue and also improves the warning message generated if an invalidate date is entered.

==== Bespoke validations no longer supported for Date MetaField ====
The <code>validate</code> function of <code>EPrints::MetaField::Date</code> does not call the <code>SUPER</code> function where validation triggers for specific Date MetaFields are called. [https://github.com/eprints/eprints3.4/commit/1cc835a261e3b722d1dbb5ad57727ff0e567b332 This patch] can be used to reintroduce the <code>SUPER</code> function call and allow bespoke validations again.

==== Requesting /cgi/set_lang causes an internal server error ====
This is cause by an underlying error where there is no <code>scheme</code> method for <code>Apache2::RequestRec</code> object.  Instead <code>EPrints::Repository</code>'s <code>get_secure</code> method should be called and tested for whether the return value is the string "on".  [https://github.com/eprints/eprints3.4/commit/8c18cd49c65597539bd3fe9c1c97ef05c52694f7 This patch] can be used to fix this issue.  However, the original intent for this change in 3.4.3 is to ensure EPrints' <code>set_lang</code> [https://hacks.mozilla.org/2020/08/changes-to-samesite-cookie-behavior/ continues to work in future version of Firefox] and other browsers (see https://github.com/eprints/eprints3.4/issues/118).  

Even with the above patch to the fix, EPrints' <code>set_lang</code> may not be correctly defined to be supported in future web browsers.  To make sure it is, you need to make sure that the installed version Perl's <a href="https://metacpan.org/pod/CGI::Cookie"><code>CGI::Cookie</code></a> package is at least version 4.31.  This is the case for Ubuntu (18.04 and 20.04 LTS) and RHEL/CentOS 8, all of which, (as of 2nd June 2021), install version 4.38.  However, RHEL/CentOS 7 only installs version 3.63.  This means you will need to install the latest version through CPAN (as the root user):
 cpan CGI::Cookie

==== Non-multiple Subject field causes an internal server error ====
This problem does not affect any fields in a vanilla installation of EPrints 3.4.3 but will affect any non-multiple [[Subject field]]s unless they use the <code>Field::Subject</code> typed component in the workflow.  From the web browser the page will just show an internal server error but the underling error message in the webserver logs will be something like:

 [Fri Sep 10 10:54:00.439169 2021] [:error] [pid 12763] Can't use an undefined value as an ARRAY reference at /opt/eprints3/perl_lib/EPrints/MetaField/Subject.pm line 128.\n

This issue was caused by some recently introduced code to attempt to harmonise the behaviour of Subject fields independent of whether they use the <code>Field::Subject</code> workflow component.  Specifically, that any subject that has been made undepositable but which had already been selected for an item, should still appear an remain selected.  This prevent a user deselecting this option without realisng, whilst editing it for another reason. The <code>divisions</code> is a good example, where an institution has changed its structure and does not want users to deposit against old divisions but wants to ensure these old divisions remain associated with historical items. (see https://github.com/eprints/eprints3.4/issues/144 for more details).  

[https://github.com/eprints/eprints3.4/commit/41f6f199d7abb753a3d180aabde6a0c482825ff8 This patch] fixes this issue by checking to see whether the value returned by the <code>get_value</code> for the specific field, is already an ARRAY reference and if not making sure it is converted to one before the <code>foreach</code> code block that iterates over this value.

==== Multiple Subject field using default rendering shows selected options twice ====
This problem does not affect the <code>subjects</code> stage of the workflow because the <code>subjects</code> field is rendered using the special <code>Field::Subject</code> workflow component.  However, it is will effect the <code>divisions</code> field in the <code>core</code> (Details) stage of the workflow.  In of itself this does not cause selected options to be saved to the database but it liable to be concerning to users.  

This issue can be resolved by the [https://github.com/eprints/eprints3.4/commit/41f6f199d7abb753a3d180aabde6a0c482825ff8 same patch] that fixes the bug with non-multiple [[Subject field]]s.  It makes sure that only previously selected items that are now undepositable are added to the array of selected options, as the one that are still depositable will be added to this array by other means.  In making this change, both undepositable and depositable options will only be selected once in the select input for this field.

==== Non-compulsory boolean radiogroup fields cannot deselect UNSPECIFIED ====
If a field is set to type <code>boolean</code> and then in the workflow it is not set as required, then the ''UNSPECIFIED'' option will be displayed and selected.  This is due to a typo in the code when enhancing accessibility for various MetaFields.  [https://github.com/eprints/eprints3.4/commit/73f493421fb5feba81e1461181d444e4bb72ae1b This patch] fixes the typo so that the name of the input field is set correctly, whilst the id for the input field is set to a unique value.

==== RIOXX2 plugin field validation leads to internal server error ====
When upgrading if you have the [http://bazaar.eprints.org/390/ RIOXX2 plugin] installed then this can lead to an internal server error when trying to edit an eprint item.  This is due to a combination of issue.
# The RIOXX2 plugin has its own MetaField type that has a <code>validate</code> that calls the <code>validate</code> method of the underlying MetaField but without providing the data object as a parameter.  
# When this underlying validate method calls the <code>EP_TRIGGER_VALIDATE_FIELD</code> this initiate the trigger method in <tt>lib/cfg.d/user_password_maxlength.pl</tt>.  This  trigger expect the data object to be set under the variable <code>$user</code> but is is not and therefore fails when trying to call the <code>isa</code> method on it, which is not possible when it is undefined.
Both the RIOXX2 plugin and <tt>lib/cfg.d/user_password_maxlength.pl</tt> should be patched.  The former to avoid any other trigger methods from causing an internal server error in a similar way and the latter to work round the bug in the RIOXX2 field's <code>validate</code> method. [https://github.com/eprints/eprints3.4/commit/0904940a1d68f3e92317bb3bae1e33888c777b36 This is the patch] for the latter.  Any future versions of the RIOXX2 plugin should hopefully have a patch to ensure the data object is sent as a parameter to the underlying field's <code>validate_method</code>.

==== EPrints::System's sanitise cannot be called by bin scripts ====
If you call the <code>sanitise</code> function ofr <code>EPrints::System</code>, this works fine under CGI because the <code>EPrints::Repository</code> object can be determined but this is not currently possible if this function is called by a standalone bin script.  [https://github.com/eprints/eprints3.4/commit/08581f02531184e7aa4b917e95db4a5ab93e0dca This patch] allows the function to be passed an optional <code>EPrints::Repository</code> object.  The bin script in question may need to be modified so it pass this additional parameter.

==== $c->{userhome} and $c->{urlpath} Auto-set Incorrectly ====
As a result of changes for [[#Configuration for URLs and Paths|configuration for URLs and paths]], a bug was introduced which made <code>$c->{userhome}</code> and <code>$c->{urlpath}</code> full URLs rather than just paths.  This has been identified in [https://github.com/eprints/eprints3.4/issues/266|this GitHub issue].  The resolution is either to apply [https://github.com/eprints/eprints3.4/commit/00cf55a8de6193528ee50b55dd9db04b36245b78 this patch] or to update your archive's <tt>cfg/cfg.d/10_core.pl</tt> to include:
 $c->{urlpath} = "/";
 $c->{userhome} = "/cgi/users/home";