README.md 2.31 KB
Newer Older
Skia's avatar
Skia committed
1
## Sith AE
Skia's avatar
Skia committed
2

Skia's avatar
Skia committed
3
### Get started
Skia's avatar
Skia committed
4 5 6 7 8

To start working on the project, just run the following commands:

    git clone https://ae-dev.utbm.fr/ae/Sith.git
    cd Sith
9
    virtualenv --clear --python=python3 env
Skia's avatar
Skia committed
10
    source env/bin/activate
11
    pip install -r requirements.txt
Skia's avatar
Skia committed
12
    ./manage.py setup
Skia's avatar
Skia committed
13

Skia's avatar
Skia committed
14
To start the simple development server, just run `python3 manage.py runserver`
Skia's avatar
Skia committed
15

Skia's avatar
Skia committed
16
### Generating documentation
Skia's avatar
Skia committed
17

Skia's avatar
Skia committed
18 19
There is a Doxyfile at the root of the project, meaning that if you have Doxygen, you can run `doxygen Doxyfile` to
generate a complete HTML documentation that will be available in the *./doc/html/* folder.
Skia's avatar
Skia committed
20

Skia's avatar
Skia committed
21
### Dependencies:
22
See requirements.txt
Skia's avatar
Skia committed
23

Krophil's avatar
Krophil committed
24
You may need to install some dev libraries like `libmysqlclient-dev`, `libssl-dev`, `libjpeg-dev`, or `zlib1g-dev` to install all the
Skia's avatar
Skia committed
25 26 27 28 29 30
requiered dependancies with pip. You may also need `mysql-client`. Don't also forget `python3-dev` if you don't have it
already.

You can check all of them with:

```
Skia's avatar
Skia committed
31
sudo apt install libmysqlclient-dev libssl-dev libjpeg-dev zlib1g-dev python3-dev libffi-dev
Skia's avatar
Skia committed
32
```
Skia's avatar
Skia committed
33

Skia's avatar
Skia committed
34 35
The development is done with sqlite, but it is advised to set a more robust DBMS for production (Postgresql for example)

Skia's avatar
Skia committed
36

37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61
### Misc about development

#### Controlling the rights

When you need to protect an object, there are three levels:
  * Editing the object properties
  * Editing the object various values
  * Viewing the object

Now you have many solutions in your model:
  * You can define a `is_owned_by(self, user)`, a `can_be_edited_by(self, user)`, and/or a `can_be_viewed_by(self, user)`
    method, each returning True is the user passed can edit/view the object, False otherwise.   
    This allows you to make complex request when the group solution is not powerful enough.    
    It's useful too when you want to define class-wide permissions, e.g. the club members, that are viewable only for
    Subscribers.
  * You can add an `owner_group` field, as a ForeignKey to Group.  Second is an `edit_groups` field, as a ManyToMany to
    Group, and third is a `view_groups`, same as for edit.

Finally, when building a class based view, which is highly advised, you just have to inherit it from CanEditPropMixin,
CanEditMixin, or CanViewMixin, which are located in core.views. Your view will then be protected using either the
appropriate group fields, or the right method to check user permissions.