Editing EPrints 3.4.5 (section)

== Known Issues ==

=== Long time to add <tt>requester_userid</tt> field to access data object ===
Adding new columns to a database table that already contains a lot of records can take a long time.  The access table for EPrints can often have tens of millions of records.  At such a size adding a new column can take in the order of hours.  EPrints 3.4.5 add the new field <tt>requester_userid</tt>.  This is intended to capture the logged in user that is viewing or downloading an eprint/document.  This is useful for Open Education repositories that have different access permissions.  However, if you have a large access table you may want to [https://github.com/eprints/eprints3.4/commit/79683e8dadda91f5d4862b23fa7bd80bcdee081d apply this patch] from the [https://github.com/eprints/eprints3.4/issues/333 GitHub issue].

=== Subject search does not work in workflows ===
If you have a subject field which renders as a subject tree in a workflow, the search form will not work.  This is due to the [https://github.com/eprints/eprints3.4/issues/246 fix for ensuring Xapian respect a MetaField's <tt>text_index</tt> value].  This has the consequence of not indexing the <tt>ancestors</tt> field for subjects.  This is used by the search to filter out subjects that are not part of the subject sub-tree for a particular MetaField.  [https://github.com/eprints/eprints3.4/commit/3fbd47ccc0d9e66514455c693b62b902790e3326 This patch] fixes [https://github.com/eprints/eprints3.4/issues/411 the issue].  However, you will also need to re-index all subjects:
 EPRINTS_PATH/bin/epadmin reindex ARCHIVE_ID subject

=== Approved document requests still force user to login ===
This issue was caused by setting the <code>samesite</code> attribute for the <code>eprints_doc_request</code> cookie to <code>Strict</code>, this cookie is intended to allow the user to access the restricted document for the remainder of their session.  Changing this attributes means some browsers (e.g. Firefox) still send the user to a login page even when clicking the approved request link in the email they received.  This is because the change made to the cookie prevents its from being stored because <code>/cgi/process_request</code> never fully serves a page.  [https://github.com/eprints/eprints3.4/commit/278b5e599dc9f6aa1e4a20f3b211afabb2a4ea9a This patch] fixes the [https://github.com/eprints/eprints3.4/issues/413 the issue].