Doc patch for bug 44595: interface for administrator to delete attachments - Patch...

diff --git a/docs/xml/using.xml b/docs/xml/using.xml
index 0eae71b5abc3a949d67d84c136f6c0a04e89b66f..1d886660852a23af6bb7a4535792fbd577dbb671 100644 (file)
--- a/docs/xml/using.xml
+++ b/docs/xml/using.xml
@@ -848,12 +848,16 @@
 
     <para>
       If you have a really large attachment, something that does not need to
-      be recorded forever (as most attachments are), you can mark your
-      attachment as a <quote>Big File</quote>, assuming the administrator of the
-      installation has enabled this feature.  Big Files are stored directly on
-      disk instead of in the database, and can be deleted when it is no longer
-      needed.  The maximum size of a <quote>Big File</quote> is normally larger
-      than the maximum size of a regular attachment.
+      be recorded forever (as most attachments are), or something that is too
+      big for your database, you can mark your attachment as a
+      <quote>Big File</quote>, assuming the administrator of the installation
+      has enabled this feature.  Big Files are stored directly on disk instead
+      of in the database.  The maximum size of a <quote>Big File</quote> is
+      normally larger than the maximum size of a regular attachment. Independently
+      of the storage system used, an administrator can delete these attachments
+      at any time. Nevertheless, if these files are stored in the database, the
+      <quote>allow_attachment_deletion</quote> parameter (which is turned off
+      by default) must be enabled in order to delete them.
     </para>
 
     <para>