Update Projects structure according to 4.14.1

docs/application/administration/users/create.rst

@@ -3,7 +3,7 @@
 Create User
 ***********
 
-As administrators, we can create new users manually by clicking :guilabel:`Create` on the :ref:`users list<users-list>` and submitting the form. Each user must have a unique email address, first name and last name, assigned :ref:`role<user-roles>`, and a password. Optionally, a user can have affiliation specified.
+As admins, we can create new users manually by clicking :guilabel:`Create` on the :ref:`users list<users-list>` and submitting the form. Each user must have a unique email address, first name and last name, assigned :ref:`role<user-roles>`, and a password. Optionally, a user can have affiliation specified.
 
 .. figure:: create/create.png
     :width: 500

docs/application/administration/users/detail.rst

@@ -3,7 +3,7 @@
 User Detail
 ***********
 
-As administrators, we can edit existing users manually on the detail (selected user from  the :ref:`users list<users-list>`). It is possible to change all properties of the user, including possibility to change whether the user account is active or inactive. 
+As admins, we can edit existing users manually on the detail (selected user from  the :ref:`users list<users-list>`). It is possible to change all properties of the user, including possibility to change whether the user account is active or inactive. 
 
 .. figure:: detail/profile.png
 

docs/application/administration/users/index.rst

@@ -3,7 +3,7 @@
 Users
 *****
 
-Users list allows administrators to see and manage all users in a |project_name| instance. The list can be filtered using role, searched based using name or email fragment, and sorted via various properties of users. The list shows the role of a user next to its name and also indicates in case the user is inactive. Next to the email, we can quickly see what authentication services the user uses to log-in (:guilabel:`internal` is the internal authentication with email-password credentials, other are based on configured :ref:`OpenID services<auth-services>`).
+Users list allows admins to see and manage all users in a |project_name| instance. The list can be filtered using role, searched based using name or email fragment, and sorted via various properties of users. The list shows the role of a user next to its name and also indicates in case the user is inactive. Next to the email, we can quickly see what authentication services the user uses to log-in (:guilabel:`internal` is the internal authentication with email-password credentials, other are based on configured :ref:`OpenID services<auth-services>`).
 
 A :ref:`user detail<user-detail>` can be opened by clicking the name of a user or by selecting :guilabel:`Edit` in the right dropdown menu for the desired row. There, a user can be also deleted via the :guilabel:`Delete` action. Finally, administrator can :ref:`create a new user<user-create>` by clicking :guilabel:`Create`.
 

docs/application/knowledge-models/list/preview.rst

@@ -9,6 +9,6 @@ The preview feature for knowledge models allows us to check the content, i.e. ho
 
     https://researchers.ds-wizard.org/knowledge-models/dsw:root:2.4.4/preview?questionUuid=0b12fb8c-ee0f-40c0-9c53-b6826b786a0c
 
-For a nested question, all needed question above in the tree will be automatically prefilled. The KM preview may be also available to non-logged-in users, if configured by administrators in :doc:`../../administration/settings/content/knowledge-models`.
+For a nested question, all needed question above in the tree will be automatically prefilled. The KM preview may be also available to non-logged-in users, if configured by admins in :doc:`../../administration/settings/content/knowledge-models`.
 
 A user can directly create a new project from the KM preview. Again, this can be available also for non-logged-in users if anonymous projects are enabled by administrations in :doc:`../../administration/settings/content/projects`.

docs/application/documents/index.rst → docs/application/projects/documents.rst

@@ -1,13 +1,13 @@
 Documents
 *********
 
-As admins, we can quickly browse all documents stored in the |project_name| instance by navigating to :guilabel:`Documents` from the main menu. It is possible to search for a document by name or sort them using the name or creation timestamp.
+As admins, we can quickly browse all documents stored in the |project_name| instance by navigating to :guilabel:`Documents` from the projects menu. It is possible to search for a document by name or sort them using their name or creation timestamp.
 
-Each document has a name, format, specific size (if the generation is completed), a link to the project it was generated from, and a template used for its creation. The document can be directly downloaded or deleted from the list. Additionally, we can quickly navigate to the project from which the document was created.
+Each document has a name, format, specific size (if the generation is completed), a link to the project it was generated from, and a template used for its creation. The document can be directly downloaded or deleted from the list. 
 
 In case that there is a document that was not generated due to an error, we can check the error message. Also, if there are some documents got stuck in :guilabel:`Queued` or :guilabel:`In Progress` status, we should check the deployment (especially of the document worker component).
 
-.. figure:: index/list.png
+.. figure:: documents/documents.png
 
     List of all documents across projects.
 

docs/application/projects/files.rst

@@ -0,0 +1,16 @@
+Files
+*****
+
+As admins, we can quickly browse all files stored in the |project_name| instance by navigating to :guilabel:`Files` from the projects menu. It is possible to search for a file by name or sort them using their creation timestamp, name or size.
+
+Each file has a name, size, a link to the project it was uploaded to and user who uploaded it. The file can be directly downloaded or deleted from the list. 
+
+.. WARNING::
+
+    It is not recommended to delete files from the list without informing the project team, as it can lead to confusion among researchers. Admins should always communicate with the project team before deleting files.
+
+
+.. figure:: files/files.png
+
+    List of all files across projects.
+

docs/application/projects/index.rst

@@ -22,4 +22,6 @@ Projects are mainly used by the researchers. We have the introduction video abou
     :maxdepth: 2
 
     List<list/index>
+    Files<files>
+    Documents<documents>
     Importers<importers>

docs/index.rst

@@ -49,7 +49,7 @@ Here are some recommended sections where to start based on the role:
       - Application
     * - :ref:`projects`
       - :ref:`knowledge-models`
-      - :ref:`documents`
+      -
     * - 
       - :ref:`document-templates`
       - :ref:`administration`
@@ -85,7 +85,6 @@ Here are some recommended sections where to start based on the role:
     application/knowledge-models/index
     application/document-templates/index
     application/projects/index
-    application/documents/index
     application/administration/index
     application/profile/index
 

docs/more/development/submission-service.rst

@@ -3,7 +3,7 @@
 Submission Service
 ******************
 
-As administrators, we can configure submission services using :doc:`../../application/administration/settings/content/document-submission`. The configured HTTP request is then used when a user clicks :guilabel:`Submit` for an allowed document for submission and selected the desired submission service. The document is sent as a body of the request (or as multipart, based on the configuration) to the external service that should process it and return HTTP response with status code, and possibly also the `Location` header and some textual message.
+As admins, we can configure submission services using :doc:`../../application/administration/settings/content/document-submission`. The configured HTTP request is then used when a user clicks :guilabel:`Submit` for an allowed document for submission and selected the desired submission service. The document is sent as a body of the request (or as multipart, based on the configuration) to the external service that should process it and return HTTP response with status code, and possibly also the `Location` header and some textual message.
 
 Usually, we will need a simple proxy service to be developed that will accommodate this to API of some information system, database, storage, or other service. For example, such a proxy service will be able to receive the JSON documents from |project_name|, retrieve additional information through |project_name| API as needed, transform it to some other resulting artifact and store it in some local database that is used by other systems.