Bug 490930: Always store attachments locally if they are over X size (and below some threshold!), don't ever display "Big File" checkbox

r=mkanat a=LpSolit

1 files changed, 1 insertions, 17 deletions

diff --git a/docs/en/xml/using.xml b/docs/en/xml/using.xml
index 101a9d131..daa0720fa 100644
--- a/docs/en/xml/using.xml
+++ b/docs/en/xml/using.xml
@@ -332,9 +332,7 @@
         <para>
         <emphasis>Attachments:</emphasis>
           You can attach files (e.g. testcases or patches) to bugs. If there
-          are any attachments, they are listed in this section.  Attachments are
-          normally stored in the Bugzilla database, unless they are marked as
-          Big Files, which are stored directly on disk.
+          are any attachments, they are listed in this section.
         </para>
       </listitem>
 
@@ -862,20 +860,6 @@
     </para>
 
     <para>
-      If you have a really large attachment, something that does not need to
-      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>
       Also, if the administrator turned on the <quote>allow_attach_url</quote>
       parameter, you can enter the URL pointing to the attachment instead of
       uploading the attachment itself. For example, this is useful if you want to