Merge branch 'next' into sydney-edits-oct23

doc/api.rst

@@ -4,13 +4,13 @@
 API
 ***
 
-What is an API?
-===============
+What's that?
+============
 
-An API can be used to read or write data from an external program (such as a Python script) to an eLabFTW instance.
+It's a way to read or write data to eLabFTW from an external program (like a Python script).
 
-For instance, instead of using a web browser to access your eLabFTW instance and create an experiment,
-you can make a call to the API saying "hey, create an experiment for me", and the api will reply with the ID of the newly created experiment.
+For instance, instead of using a web browser to access the web interface and create an experiment,
+you make a call to the API saying "hey, create an experiment for me", and the api will reply with the ID of the newly created experiment.
 
 It can be used to directly feed data to eLabFTW, coming from a piece of equipment for instance.
 

doc/changelog.rst

@@ -3,6 +3,15 @@
 Changelog
 =========
 
+Version 5.1.10
+--------------
+
+* 2383e82a0 bug/minor: templates: fix duplicate action missing attributes. fix #5312
+* 90f26ce4b bug/minor: eln: use user defined date during import. fix #5304
+* 4fa676635 bug/minor: pdf: fix missing id in links of links. fix #5311
+* 7b46538bd feat: mass emails: make sure everything gets sent when ungrouped
+
+
 Version 5.1.9
 -------------
 

doc/conf.py

@@ -62,7 +62,7 @@
 # The short X.Y version.
 version = '5.1'
 # The full version, including alpha/beta/rc tags.
-release = '5.1.9'
+release = '5.1.10'
 
 # The language for content autogenerated by Sphinx. Refer to documentation
 # for a list of supported languages.

doc/faq.rst

@@ -172,17 +172,17 @@ Is it compliant to 21CFR Part 11?
 
 1. Closed system: eLabFTW requires unique credentials to access the system. A system of permissions and roles allow fine control of what can be seen by whom.
 
-2. Experiments and database items (protocols, reagents, cell lines...) are considered signable by the locking mechanism that timestamps and locks an entity in place.
+2. Experiments and resources (protocols, reagents, cell lines...) can be signed with cryptographic signatures, verifiable outside the system, and stored in an immutable archive.
 
-3. Trusted timestamping: RFC3161 Trusted Timestamping is available for experiments. A specific PDF is generated and timestamped cryptographically to prove anteriority if needed in a court of law.
+3. Trusted timestamping: RFC3161 Trusted Timestamping is available for experiments. When using a qualified TSA such as Universign, this makes the process compliant with ETSI EN 319 42 (eIDAS european regulation).
 
-4. Audit trail: changes to entries are internally recorded and cannot be tampered with by users. A version history is available.
+4. Audit trail: changes to entries are internally recorded and cannot be tampered with by users. A version history is available, with adjustable granularity.
 
-5. Retention of records: a setting allows to disable the possibility to delete records entirely.
+5. Retention of records: a soft-delete mechanism prevents destructive actions on data.
 
-6. Copies of records: you can export your data in PDF, ZIP archives or CSV files very easily.
+6. Copies of records: you can export your data in PDF, ZIP archives or CSV files very easily. This can also be automated via the API.
 
-7. Password policy: passwords are securely stored in the database and security mechanisms such as preventing too many authentication tries are in place.
+7. Password policy: passwords are securely stored in the database and security mechanisms such as preventing too many authentication tries are in place. Password policies can also be enforced, and centralized authentication mechanisms can be setup.
 
 What about compliance to standards?
 ===================================

doc/generalities.rst

@@ -1,8 +1,8 @@
 .. _generalities:
 
-*******
-General
-*******
+************
+Generalities
+************
 
 Lexicon
 =======

doc/import-export.rst

@@ -50,19 +50,19 @@ Select a `.eln` file to display import options. Then click Import.
 Importing through CLI
 ^^^^^^^^^^^^^^^^^^^^^
 
-.. note:: This approach is only available to Sysadmins wish shell access.
+.. note:: This approach is only available to Sysadmins with shell access.
 
 If you wish to import a rather large `.eln` archive (such as a full team export), the CLI is the better approach. Display the help with:
 
 .. code-block:: bash
 
    docker exec -it elabftw bin/console import:eln -h
 
-As you can see, there are two mandatory arguments, the path to the file, and the Team ID where the import will be performed. The first thing to do is to copy the file in the right place in the container. It must be in `/elabftw/cache/elab` folder. Copy it with a command similar to this:
+As you can see, there are two mandatory arguments, the path to the file, and the Team ID where the import will be performed. The first thing to do is to copy the file in the right place in the container. It must be in `/elabftw/exports` folder. Copy it with a command similar to this:
 
 .. code-block:: bash
 
-   docker cp your.eln elabftw:/elabftw/cache/elab/
+   docker cp your.eln elabftw:/elabftw/exports/
 
 Figure out the Team ID by looking at the Team from the Sysconfig panel, where the ID will be displayed next to the Team. Next, import your file with:
 
@@ -71,7 +71,7 @@ Figure out the Team ID by looking at the Team from the Sysconfig panel, where th
    # import in team 12 and be verbose
    docker exec -it elabftw bin/console import:eln -vv your.eln 12
    # import in team 25, force everything to be owned by user 5 and be extra verbose
-   docker exec -it elabftw bin/console import:eln -vvv your.eln 12 --userid 5
+   docker exec -it elabftw bin/console import:eln -vvv your.eln 25 --userid 5
    # import in team 42, force everything to be of type "Resources" with category "6"
    docker exec -it elabftw bin/console import:eln --type items --category 6 your.eln 42
 
@@ -183,7 +183,19 @@ The Export tab from your Profile allows full export of all your data, in several
 
 Very long exports will still be processed if you close your browser or navigate away.
 
-Note to Sysadmins: on a given instance, export jobs are processed only one at a time. Users can each keep only 6 exported files. They are stored in `cache` and will disappear if the container is destroyed.
+Note to Sysadmins: on a given instance, export jobs are processed only one at a time. Users can each keep only 6 exported files. They are stored in `exports` within the elabFTW root folder. The `exports` folder may be mapped to a path outside the container to prevent exceeding the disk usage quota of the container.
+This can be done by adding a corresponding entry to `/etc/elabftw.yml` beneath the existing mapping for the upload path. In the example below, the exports folder is mapped to `/var/elabftw/exports`.
+
+.. code:: yaml
+
+    volumes:
+        # this is where you will keep the uploaded files persistently
+        # for Windows users it might look like this
+        # - D:\Users\Nico\elab-data\web:/elabftw/uploads
+        # host:container
+        - /var/elabftw/web:/elabftw/uploads
+        # mapping of exports folder
+        - /var/elabftw/exports:/elabftw/exports
 
 Exporting through CLI
 ---------------------