docs

docs/about.md

+
+##Welcome to Gargantext documentation
+

docs/about/todo.md

-# API
-
-Be more careful about authorizations.
-
-cf. "ng-resource".
-
-# Projects
-
-## Overview of all projects
-
-- re-implement deletion
-
-## Single project view
-
-- re-implement deletion
-
-
-# Taggers
-
-Path for data used by taggers should be defined in `gargantext.constants`.
-
-
-# Database
-
-# Sharing
-
-Here follows a brief description of how sharing could be implemented.
-
-## Database representation
-
-The database representation of sharing can be distributed among 4 tables:
- - `persons`, of which items represent either a user or a group
- - `relationships` describes the relationships between persons (affiliation
-     of a user to a group, contact between two users, etc.)
- - `nodes` contains the projects, corpora, documents, etc. to share (they shall
-     inherit the sharing properties from their parents)
- - `permissions` stores the relations existing between the three previously
-     described above: it only consists of 2 foreign keys, plus an integer
-     between 1 and 3 representing the level of sharing and the start date
-     (when the sharing has been set) and the end date (when necessary, the time
-     at which sharing has been removed, `NULL` otherwise)
-
-## Python code
-
-The permission levels should be set in `gargantext.constants`, and defined as:
-```python
-PERMISSION_NONE = 0     # 0b0000
-PERMISSION_READ = 1     # 0b0001
-PERMISSION_WRITE = 3    # 0b0011
-PERMISSION_OWNER = 7    # 0b0111
-```
-
-The requests to check for permissions (or add new ones) should not be rewritten
-every time. They should be "hidden" within the models:
- - `Person.owns(node)` returns a boolean
- - `Person.can_read(node)` returns a boolean
- - `Person.can_write(node)` returns a boolean
- - `Person.give_right(node, permission)` gives a right to a given user
- - `Person.remove_right(node, permission)` removes a right from a given user
- - `Person.get_nodes(permission[, type])` returns an iterator on the list of
-    nodes on which the person has at least the given permission (optional
-    argument: type of requested node)
-- `Node.get_persons(permission[, type])` returns an iterator on the list of
-   users who have at least the given permission on the node (optional argument:
-   type of requested persons, such as `USER` or `GROUP`)
-
-## Example
-
-Let's imagine the `persons` table contains the following data:
-
-| id | type  | username  |
-|----|-------|-----------|
-| 1  | USER  | David     |
-| 2  | GROUP | C.N.R.S.  |
-| 3  | USER  | Alexandre |
-| 4  | USER  | Untel     |
-| 5  | GROUP | I.S.C.    |
-| 6  | USER  | Bidule    |
-
-Assume "David" owns the groups "C.N.R.S." and "I.S.C.", "Alexandre" belongs to
-the group "I.S.C.", with "Untel" and "Bidule" belonging to the group "C.N.R.S.".
-"Alexandre" and "David" are in contact.
-The `relationships` table then contains:
-
-| person1_id | person2_id | type    |
-|------------|------------|---------|
-| 1          | 2          | OWNER   |
-| 1          | 5          | OWNER   |
-| 3          | 2          | MEMBER  |
-| 4          | 5          | MEMBER  |
-| 6          | 5          | MEMBER  |
-| 1          | 3          | CONTACT |
-
-The `nodes` table is populated as such:
-
-| id | type     | name                 |
-|----|----------|----------------------|
-| 12 | PROJECT  | My super project     |
-| 13 | CORPUS   | A given corpus       |
-| 13 | CORPUS   | The corpus           |
-| 14 | DOCUMENT | Some document        |
-| 15 | DOCUMENT | Another document     |
-| 16 | DOCUMENT | Yet another document |
-| 17 | DOCUMENT | Last document        |
-| 18 | PROJECT  | Another project      |
-| 19 | PROJECT  | That project         |
-
-If we want to express that "David" created "My super project" (and its children)
-and wants everyone in "C.N.R.S." to be able to view it, but not access it,
-`permissions` should contain:
-
-| person_id | node_id | permission |
-|-----------|---------|------------|
-| 1         | 12      | OWNER      |
-| 2         | 12      | READ       |
-
-If "David" also wanted "Alexandre" (and no one else) to view and modify "The
-corpus" (and its children), we would have:
-
-| person_id | node_id | permission |
-|-----------|---------|------------|
-| 1         | 12      | OWNER      |
-| 2         | 12      | READ       |
-| 3         | 13      | WRITE      |
-
-If "Alexandre" created "That project" and wants "Bidule" (and no one else) to be
-able to view and modify it (and its children), the table should then have:
-
-| person_id | node_id | permission |
-|-----------|---------|------------|
-| 3         | 19      | OWNER      |
-| 6         | 19      | WRITE      |

docs/contribution.md

@@ -17,7 +17,6 @@
 * Architecture Overview
 
 
-
 * Database Schema Overview
 
 * Interface design Overview

docs/tuto.md

@@ -3,7 +3,7 @@
 1. Login
 
 run the gargantex box following the install procedure
-open a webrwoser at http://127.0.0.1:8000/
+open a webrowser at http://127.0.0.1:8000/
 click on Test Gargantext
 login with:
 ```
@@ -14,8 +14,16 @@ Password : autnagrag
 2. Create a project
 
 3. Import an existing corpus
-4. create corpus
-5. Explore
-6. Query
-7. Refine
-8. Export
+
+4. Create corpus from search
+
+5. Explore stats
+
+6. Explore graphs
+
+7. Query
+
+8. Refine
+* Time periods
+* Nodes
+9. Export

mkdocs.yml

@@ -2,6 +2,6 @@ site_name: Gargantext
   - "Welcome":"index.md"
   - "Installation Guide":"install.md"
   - "User Guide":"tuto.md"
-  - "Contribution Guide":"dev.md"
+  - "Contribution Guide":"contribution.md"
   - "Next steps":"todo.md"
 theme: readthedocs