Difference between revisions of "EPrints 3.4.6"

From EPrints Documentation
Jump to: navigation, search
(Release Notes: Added known issue about generate_apacheconf not working without archive cfg/static/javascript/auto/ directory)
m (Known Issues)
 
(3 intermediate revisions by the same user not shown)
Line 119: Line 119:
 
== Known Issues ==
 
== Known Issues ==
 
=== Running generate_apacheconf with an archive without a cfg/static/javascript/auto/ directory ===
 
=== Running generate_apacheconf with an archive without a cfg/static/javascript/auto/ directory ===
If you are upgrading an EPrints repository and your archive(s) do not have a <code>cfg/static/javascript/auto/</code> directory then <code>bin/generate_apacheconf</code> will fail.  This is because 3.4.6 [https://github.com/eprints/eprints3.4/issues/369 introduces] code that makes sure that the maximum upload limit is configured to be the same in the Apache configuration and in EPrints' JavaScript, which prevents you from trying to upload files larger than certain size.  This is useful because if you just updated the JavaScript, EPrints would allow the upload to start but would then fail when the Apache limit was reached.  So not only would you not be able to upload the file but you would waste a lot of time before and possibly not understand why the upload failed.
+
If you are upgrading an EPrints repository and your archive(s) do not have a <code>cfg/static/javascript/auto/</code> directory then <code>bin/generate_apacheconf</code> will fail.  This is because 3.4.6 [https://github.com/eprints/eprints3.4/issues/369 introduces] code that makes sure that the maximum upload limit is configured to be the same in the Apache configuration and in EPrints' JavaScript, which prevents you from trying to upload files larger than a certain size.  This is useful because if you just updated the JavaScript, EPrints would allow the upload to start but would then fail when the Apache limit was reached.  So not only would you not be able to upload the file but you would waste a load of time and possibly not understand why the upload failed.
  
To fix this issue for now, just make sure your archive (or archives) all have a <code>cfg/static/javascript/auto/</code> before running <code>bin/generate_apacheconf</code>.  Future versions of EPrints will automatically create this directory if it does not exist.
+
To fix this issue for this version of EPrints, just make sure your archive (or archives) all have a <code>cfg/static/javascript/auto/</code> before running <code>bin/generate_apacheconf</code>.  Future versions of EPrints will automatically create this directory if it does not already exist.
 +
 
 +
=== 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].
  
 
== Further Planned Features and Improvements ==
 
== Further Planned Features and Improvements ==

Latest revision as of 10:32, 13 November 2024

Release Notes

3.4 | 3.4.1 | 3.4.2 | 3.4.3 | 3.4.4 | 3.4.5 | 3.4.6


3.3 | 3.3.5 | 3.3.6 | 3.3.7 | 3.3.8 | 3.3.9 | 3.3.10 | 3.3.11 | 3.3.13 | 3.3.14 | 3.3.15 | 3.3.16


3.2.0 | 3.2.1 | 3.2.2 | 3.2.3 | 3.2.4 | 3.2.5 | 3.2.6 | 3.2.7 | 3.2.8 | 3.2.9


3.1.0

This page contains information about the provisional EPrints v3.4.6 tag and release on GitHub.

Release Notes

EPrints 3.4.6 is now available on GitHub.

  • Zero codename: Creme Brulee Cryoseism
  • Publications flavour codename: Affogato Snowmelt

New Dependencies

Check earlier dependencies for EPrints 3.4.5 and before.

Changes Since 3.4.5

New Functionality

Security and Privacy Improvements

General Improvements

Bug Fixes

Known Issues

Running generate_apacheconf with an archive without a cfg/static/javascript/auto/ directory

If you are upgrading an EPrints repository and your archive(s) do not have a cfg/static/javascript/auto/ directory then bin/generate_apacheconf will fail. This is because 3.4.6 introduces code that makes sure that the maximum upload limit is configured to be the same in the Apache configuration and in EPrints' JavaScript, which prevents you from trying to upload files larger than a certain size. This is useful because if you just updated the JavaScript, EPrints would allow the upload to start but would then fail when the Apache limit was reached. So not only would you not be able to upload the file but you would waste a load of time and possibly not understand why the upload failed.

To fix this issue for this version of EPrints, just make sure your archive (or archives) all have a cfg/static/javascript/auto/ before running bin/generate_apacheconf. Future versions of EPrints will automatically create this directory if it does not already exist.

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 fix for ensuring Xapian respect a MetaField's text_index value. This has the consequence of not indexing the ancestors 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. This patch fixes 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 samesite attribute for the eprints_doc_request cookie to Strict, 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 /cgi/process_request never fully serves a page. This patch fixes the the issue.

Further Planned Features and Improvements

See 3.4.7 milestone on GitHub for more details.