# Développement de Wikiarchives.space

# Work In Progress

## Réunion n°0

Il faut faire une première réunion avec les personnes qui pensent être disponible pour un développement qui démarerait ce mois ci.

Le but de cette réunion est de définir :
- l' équipe
- Dans un premier temps:
- qui est dispo et pendant combien d'heures par semaine ?
- quel sont les compétences de chacun ?
- à partir du cahier des charges:
- quelle techno front ?
- quelle techno back ?
- quelle techno bdd ?
- passer en revue chaque point du cahier des charges, le compléter si besoin

- le hôte du ou des repositories git
- l'organisation git
- quelle convention de nommage des commit ?
- comment ça se passe lors de la création d'une PR
- que se passe t-il quand une PR est mergé ?
- le CI/CD eventuellement
- l'hébergement
- utilisation de docker ?
- quel VPS provider ?
- quel provider S3 ?
- anticiper la migration de l'ancien au nouveau système

## Cahier des charges "officiel" WIP

### Partie publique
- Home page
- couverture
- slogan
- présentation des albums racines
- Page d'un album/resultat d'une recherche
- breadcrum (en gros le chemin album1/album2)
- bouton revenir à l'album parent
- affichage des albums enfants
- affichage des photos contenues
- tri par date
- priorité plus basse: possibilité de switch de mode d'affichage (mode card au mode liste détaillé)
- bouton modifier : redirige vers la page dédié
- bouton supprimer
- bouton ajouter une photo : redirige vers la page dédié
- Page d'une photo
- navigation photo précédente/suivante
- affichage de la photo dans une résolution medium
- accéder à l'album parent
- détails et méta données
- map
- bouton modifier: redirige vers la page dédié
- bouton supprimer
- Page recherche
- recherche d'album et de photos corespondant à un/des mots clés à partir des méta données : titre, tags et description
- affichage de resultats suivant la même manière d'afficher qu'un album
- Page about
- Page legals

### Pages utilisateurs

- navbar quand on est connecté :
- Compteur des modifications
- Page connexion
- Checkbox: se souvenir de moi (création d'un cookie de connexion)
- Page inscription
- Page mot de passe oublié
- Page paramètres utilisateur
- changer d'username
- changer l'email
- changer de mot de passe
- supprimer son compte
- option de notifications par email?

- Page liste des brouillons/sessions de modifications
- Affichage sous forme de liste des différentes sessions de modification de l'utilisateur
- Pagination
- Page ajout d'une photo dans un album
- Page modification d'une photo
- Page modification d'un album

## Pages modérateur

- Page de gestion des brouillons (en attente)
- Lister les differents brouillons

- Page de détail d'un brouillon
- Liste de toute les mutations
- Publier la modification ou la rejeter (avec un commentaire)

- Page de gestion des utilisateurs
- Lister les users avec leur username et lien vers leur page de profil
- Reinitialiser un mdp utilisateur
- Blacklister une IP
- Impossibilité de se connecter ou de s'enregistrer
- Suspendre un utilisateur
- entraîne l'impossibilité de se login
- supprime les token de sessions (si il y en a)
- aucune action de write ne pourrat être entreprit par cet utilisateur

## Pages admin

- Page de gestion des utilisateurs
- Changer le role de l'utilisateur (default|admin|modo)
- Supprimer un utilisateur complétement

## Gestion des brouillons

lors d'une modification, on considère duplique les entités concerné en les attribuants une marque pour les différencier du contenus publié mais en le gardant sur la même table

si une version d'un user est accepté on supprime toute les version antérieur non publié de cette entité afin d'éviter les conflits

--------------------
--------------------
--------------------
*Brouillon*

à partir d'ici c'est le contenu du premier document note que j'avais fait pour voir un peu les fonctionnalités et comment on peux mettre une bdd dessus. Donc c'est des idées/propositions

### Cahier des charges fonctionnel

Système d’utilisateurs
Connection
Inscription
Rôles (Modo et Admin)
Stockage des images dans un Object Storage type Amazon S3
Plusieurs résolutions d’images (small, medium, large, original)
Home page
Cover?
Liste des albums racines
About page (page statique)
Page Album
Affichage du nom et de la description
Liste des albums ou des photos contenus dans cet album
Naviguer dans les albums imbriqués
Recherche (pas prio)
“Session” pour les changements

### Cahier des charges technique
Ceci est un example de comment moi je m’imagine implémenter le truc mais c’est totalement sujet à changements

**users: User[]**
id: ID
username: string
email: string
password: string
role: ‘moderator’|’admin’
createdAt: datetime
updatedAt: datetime
metaDatas à propos de l’utilisateur

**drafts: Draft[]**
id: ID
commentary: string
user: User
createdAt: datetime
updatedAt: datetime
rejectedAt: datetime
rejectionDescription: string
events[]:
type: ‘proposal’|’accepted’|’rejected’
commentary
at: datetime

**albums: Album[]**
id: ID
name: string
description: string
parent: Album
images: Image[]
createdBy: User
createdAt: datetime
updatedAt: datetime
draft: Draft
createdByDraft: boolean

**images: Image[]**
id: ID
sizes[] (JSON)
type: string ’original’|‘large’|’medium’|’small’
width: float
height: float
key: string
type: string (‘image/png’, ‘image/jpeg’)
fileName: string
createdBy: User
createdAt: datetime
updatedAt: datetime
checksum: string (sha256 checksum of the original file)
name: string
description: string
latitude: float
longitude: float
takenAt: datetime
source: string (champs libre pour décrire la source)
draft: Draft (duplicate)
createdByDraft: boolean

API GraphQL en PHP
Interface user en Nuxt.js
Page pour voir son draft
voir les changements du draft
proposer le draft
supprimer le draft
lire l’historique du draft
Page pour voir son profil user
changer username
changer email
changer mdp
MODO: lliste des drafts
voir toute les entitiés (Album et photos) affectés par le draft
accepter le draft
refuser le draft
ADMIN: liste des users et gestion
changer role
supprimer

## Technos choisi

- Amazon S3 pour le stockage d'image

## Client-side Data layer

on a besoin d'un code pour cacher les données du serveur coté client

il faut garder la liste des modifs appliqués par l client
et après on a juste à les appliquer sur les données reçues

ça pour toute les photos, albums qui sont un peu les seuls trucs qui sont modifiés

faut faire une classe qui généralise ça pour tout type d'items

CatalogStore
.loadsCatalog(data) # load data from server, it will apply the mutations made by this user
.add({ name, description })
.edit({ name, description, primaryPicture })
.remove(id)
.getMutations() # récupère une liste des mutations

ça va rajouter

PictureStore

meme principe

On affiche en bas à droite de l'écran de l'user un compteur de tout ses changements

Quand il clique dessus ça amène vers l'url `/changes`

Pages /changes

ça affiche tout les changements qui ont été faits
de la même manière que openstreetmap
on peut remove individuellement ces changements

on peut mettre un message de commit et submit les changements

## Idée de badge

badge de missions spatiales indexé sur les points

## ROLES

- LEVEL 0: ROLE_USER
role given to every user by default, contribution need approval

- LEVEL 1: ROLE_TRUSTED or ROLE_APPROVAL_FREE
role given to a user that is trusted to contribute without approval

- LEVEL 2: ROLE_MODERATOR
allow to approve others users, lock accounts or delete (really it's just hiding the user)

## Actions possibles avec les points et Badge

Pouvoir choisir entre le côté américain, européen et russe

- entre 0 et 10 points: seulement les albums "modifier"
pouvoir seulement modifier les photos des albums marqué comme safe
ex: "à trier"
ajout d'une proprieté 'isEditableByBeginner' dans catalog

- à partir de 10: on peut modifier partout (BADGE DE NIVEAU 1)

- à partir de 50: (BADGE DE NIVEAU 2)

- à partir de 100: (BADGE DE NIVEAU 3)

- à partir de 500: (BADGE DE NIVEAU 4)

- à partir de 1000: (BADGE DE NIVEAU 5)

### idées de niveaus

- 1: sub orbital
- 2: orbital avec un sat (spouknik)
- 3: un animal en orbite
- 4: premier retour avec un animal vivant de l'orbite
- 5: premier homme en sub orbital
- 6: homme en orbite
- 7: EVA ()

- Circo lunaire (Apollo 8)
- Orbite autour de la lune (Apollo 10)
- atterissage sur la lune (Apollo 11)
- : Station en orbite basse (Skylap)

    // role given to every user by default, contribution need approval
    const ROLE_USER        = 'ROLE_USER';
    // role given to a user that is trusted to contribute without approval
    const ROLE_CONFIRMED = 'ROLE_CONFIRMED';
    // allow to approve others users, lock accounts or delete (really it's just hiding the user)
    const ROLE_MODERATOR   = 'ROLE_MODERATOR';
    // the supreme role, allow to manage the roles of others
    const ROLE_ADMIN       = 'ROLE_ADMIN';

## Overview/Idées d'autres features

- URL Seo friendly (catalog & picture)
- Meta: graphql, twitter etc
- Chronological event calendar or event discovery
- tag "fond d'écran"
- instagram publisher
- contact form
- rule of community
- Report a image for copyright violation

# Nouveau système de contribution

## Ressources

Picture => (OneToMany) => Versions
Picture => (OneToMany) => Changes

Version => (OneToMany) => Changes

Change => [
status
qui
quel champs
quel valeur
quand
]

# Scénarios

## Création d'une image

notre gars est un user ROLE_USER
il veut créer une image dans un album

donc il se rend sur la page de l'album en question et il appuie sur "Créer une image"

ça redirige vers une page /picture/create page dédié à la création d'une image.

il drag and drop le fichier dans l'input file, ça attend ça fait rien du tout

il remplit les champs en priorité name, source etc

il appuie sur SAVE

donc là il y a une requête `POST /pictures` qui va:
- upload l'image
- créer les différentes résolutions
- créer un objet de type Picture (mais avec le isPublished: false, car il n'y a pas encore de version associé, juste des resolutions et des changements)
- il va créer des objets de type Change pour chaque field

(cela sert à uniformiser le panel modérateur et l'affichage des contributions dans le dashboard user)

[
    { status: 'pending', user: ..., object: ..., field: 'name', value: 'IDNASA' },
    { status: 'pending', user: ..., object: ..., field: 'description', value: 'Super cool' }
]

cet objet là n'a pas encore bcp de propriétés

donc après on va le remplir

et après on va save les autres propriétés

**RQ: une image devrait pouvoir passer la validation sans de méta en plus, juste avec le fichier en lui même ET l'album parent**

## Affichage des contributions sur le panel utilisateur

- regrouper les contributions par "sessions"
- généralement les contributions arrivent par "slaves" donc il faut faire un petit algo qui regroupe les différentes slaves à partir du timestamp
- on peut se proposer de faire par heures

- on regroupe les changes par groupe de 2 heures

const changes = [
    "2020-10-01 20:05:00",
    "2020-10-01 20:06:00",
    
    "2020-10-02 19:45:00",
    "2020-10-02 20:45:00",
    "2020-10-02 21:05:00",
    "2020-10-02 21:06:00",
    "2020-10-02 21:35:00"
    "2020-10-02 21:36:00"
    "2020-10-02 21:38:00"
    
    "2020-10-03 00:38:00"
    "2020-10-03 00:50:00"
]