horizon-efrei / horizonweb

🖥 Plateforme d'entraide et de vie étudiante de Horizon EFREI !

HorizonWeb

🖥 Le forum d'entraide étudiante de Horizon !

Rapport de bug et suggestions

• Vous avez aperçu un bug en utilisant HorizonWeb ?
• Vous avez une idée ou une suggestion ?
• Vous souhaitez nous faire part de quelque chose ?

Vous pouvez vous rendre dans le menu des issues et en créer une ; nous y jetterons un œil dès que possible !
Pour tout autre question, vous pouvez créer une Discussion GitHub.

Développement et contributions

Nos Pull Request (PR) sont ouvertes à toutes contributions ! Vous pouvez regarder notre guide de contributions avant de commencer à travailler sur HorizonWeb : il vous aidera à tout mettre en place et à vous assurer que votre PR puisse être merge rapidement.

Informations

HorizonWeb est le projet de site web d'Horizon. C'est un forum de collaboration étudiante, de remontée à l'administration et de partage de fichiers. Son fonctionnement s'inspire du système de Post de Reddit, StackOverflow, ou les Discussions GitHub.
Le backend est développé en TypeScript et utilise le framework NestJS.
Le frontend est développé en JavaScript et utilise le framework VueJS.
La base de données est une base de données Postgres.
Le service pour la recherche instantanée est Typesense.

Fonctionnalités

• Forum d'entraide, de résolutions de problèmes, suggestions pour l'administration, etc.
• Système de partagde, de recherche et de téléchargement de fichiers.
• Système de réponses, commentaires, de signalement de contenus inappropriés, etc.
• Espace blog ouvert aux étudiants, pour poster des annonces concernant les associations où des événements.

Crédits

Développeurs

Team de développement de l'association Horizon !
Voir les contributeurs.

License

HorizonWeb est sous license MIT.

horizonweb's Issues

🖥️ Titre HTML (nom d'onglet)

Toutes les pages devraient avoir un nom d'onglet pertinent, customisable dans le router

Back-end : AuditLogs (garder en mémoire toutes les activités sur les entités)

Les "AuditLogs" permettent de créer un historique des actions sur les différentes entités de la base de données. Chaque champ important modifié d'une entité doit avoir son propre type de log, et stocker l'information de l'état précédent et de l'état suivant, ainsi que la date de la transaction et tout autre méta-information pertinente.

TODO:

• Subscribers qui gère automatiquement les ajouts aux AuditLogs
• Définir tous les types de logs pertinents à stocker

Modal (singleton)

[A DETAILLER] Espace : Utilisateur

TODO:

• Profil
• Lier à Discord
• Customisation des préférences (apparence, accessibilité, données personnelles, etc.)

Refactoring: Bonnes pratiques Vue3

Checkup de tous les components pour assurer les bonnes pratiques Vue3:

• querySelector => refs
• Bindings plutôt que des manipulations de DOM
• Debouncing (délai) du firing d'évents constants avec lodash
• Lifecycles propres (pas de fuites mémoire)
• #31

(Prochaine issue bonne pratique : script setup)

📋 Espace de blog

CMS permetttant de créer et visualiser des articles de blogs (table des matières, articles avec images et liens externes, section commentaires...) librement.

• Backend : module des blogs et endpoints pour créer / modifier des articles
• Frontend : page de création des articles (à refaire)
• Frontend : page de listing des articles
• Frontend : page de visualisation d'un article avec actions utilisateur

Front-end : Comment

Les commentaires sont en ligne sous les Posts, Replies ou les descriptions de Documents et doivent être les plus compréssés possibles ; s'inspirer du design de Stackoverflow.

Les commentaires doivent également avoir quelques options : possibilité de liker le commentaire, de réagir, de flagger comme inapproprié, de mettre en favori / possibilité d'éditer ou de supprimer le commentaire

• Component simple du commentaire (avec props)
• Tooltip de l'utilsateur (+ lien)
• Actions (différentes en fonction du niveau de permission)

Front-end : ThreadHistoryView (vue d'un Thread avec l'historique complet de modifications)

La ThreadHistoryView permet de voir l'ensemble des actions utilisateurs sur un Thread dans l'ordre chronologique. Elle est particulièrement utile pour les admins/modérateurs mais peut aussi être utile pour des utilisateurs souhaitant comprendre le contexte d'une modification de message, quels contenus ont depuis été supprimés, etc.

Non-prioritaire

Front-end : TagsList (liste de tags responsive)

Liste de tags en une ligne. Les tags qui overflow le container d'un TagsList sont tronqués et un message apparaît en dessous de la liste disant "+ N tags", et peut être hover et faire apparaître la liste complète des tags (avec une certaine limite s'il y'a vraiment beaucoup de tags)

TODO:

• Component de base avec liste tronquée et message
• Popup avec liste des tags
• Considérations responsive

Front-end : PostList (liste de posts responsive)

La liste des posts présente les posts en ligne, en montrant le plus d'informations pertinentes possibles en prenant le minimum de place.

TODO:

• #56
• Rendre la liste responsive (enlever les sections à droite et à gauche si l'écran devient trop petit, utilisez un autre design de post pour petit écran/écran de téléphone)

L'idée serait de faire un design proche des listes de questions de Stackoverflow

Refactoring: VueX

TODO:

• Séparer les utils dans un fichier à part
• Rendre la cache du store fonctionnelle

Refactoring: Dépendences

• Refactoring général des dépendences (pour Node 16, node-sass => sass)
• HeroIcons => RemixIcon
• node-fetch => axios
• Nouvelle config de linting (lint-staged, drop de la config webpack)
• Upgrade, prune, résolution des warnings...

📋 Espace Forum

Backend : [CRUD + Schéma]

• #38
• #5
• #54
• #6
• #7
• #8

Frontend : [Chacun dans son propre component]

Pages :

• #10
• #11
• #12
• #13

Components:

• #38
• #39
• #15
• #16
• #17

Refactoring: Sidebar

• Utiliser un seul component pour éviter d'avoir les deux components qui se chevauchent
• Assurer une transition smooth d'une sidebar à l'autre (sidebar avec ou sans bouton pour fermer la sidebar)
• Compacter la sidebar
• Alternative responsive à la sidebar (pour mobile)

📋 Espace Administrateur

TODO :

• Component Dashboard (général)
• Dashboard des posts (Actions depuis Dashboard => voir, (dés)archiver, lock, (dé)valider, éditer, suivre...)
• Dashboard des utilisateurs (Actions depuis Dashboard => voir, mute, donner rôle...)

Refactoring: Servir les images statiques sur le front

• Déplacer api/public vers site/src/assets/img
• Restructurer l'arborescence de site/src/assets/img
• Enlever le chemin intermédiaire api dans les endpoints du backend
• Adapter les components correspondants

🖥️ Post

Le component d'un Post contient un titre avec quelques méta-informations en dessous, à gauche les boutons pour upvote/downvote et à droite des actions générales (créer un post, etc.). En dessous se trouve le corps du contenu et en bas une ligne avec l'avatar de l'OP et ses détails d'une part, et de l'autre les actions possibles sur le message du Post (edit, archiver, mettre en favori, flag); en dessous se trouvent ensuite les commentaires (collapsed s'il y'en a trop, avec un bouton "Show More" ou expand pour un commentaire de plus de 2 lignes).

• Component de base d'un Post (avec props)
• Actions (cohérentes en fonction des permissions)
• Popup utilisateur
• Commentaires
• Popup ressources externes

Tag (back-end)

Les tags sont stockés en base de données et contiennent une description, un nom en kebab-case (":" possible pour un tag au sein d'une catégorie de tags, exemple: promo:l2, priorité:haute, etc.). Si un utilisateur défini un nouveau tag, il est ajouté à la base de données, et un contributeur de confiance peut modifier sa couleur, sa description, et rétroactivement changer son nom.

TODO:

• CRUD (avec permissions cohérentes) : nom, couleur, description

Refactoring: Build fonctionnel (swiper & tags)

Les builds de npm run build semblent avoir un problème avec swiper; tentative de débugging en cours; solution de dernier recours: utiliser une librairie alternative à swiper + les tags n'ont pas de background-color (bug bizarre)

:clipboard: Système de récompenses utilisateurs

TODO:

• Backend : système de points, de badges, de rangs, de customisations
• Frontend : afficher une notification lorsqu'un nouveau badge est réçu, voir le classement des utilisateurs par nombre de points, définir clairement les récompenses en fonction du nombre de points

Front-end : Reply

Le component d'une Reply contient deux colonnes: la colonne gauche, petite, contient les boutons de upvote/downvote, les actions sur le post (edit, valider, mettre en favori, flag), l'avatar de l'utilisateur répondant et ses informations ; la colonne droite contient le contenu du post et une ligne en bas du corps contient la liste des réactions et quelques méta informations ; en dessous se trouvent ensuite les commentaires (collapsed s'il y'en a trop, avec un bouton "Show More" ou expand pour un commentaire de plus de 2 lignes).

• Component de base d'une Reply (avec props)
• Actions (cohérentes en fonction des permissions)
• Popup utilisateur
• Commentaires
• Popup ressources externes

Front-end : Component UserList

Liste d'utilisateurs sur une ligne tronquable (avec un ellipsis "+ ... users"), avec possibilité d'ouvrir un popup pour voir la liste complète des utilisateurs (avec des minicartes pour chaque collaborateurs) ; un popup peut être ouvert pour chaque utilisateur pour avoir accès à un résumé d'informations sur l'utilisateur.

S'inspirer de ce design et des designs GitHub

TODO:

• Liste d'une ligne tronquable (avec une bulle cliquable avec le nombres de collaborateurs additionnels) ; première bulle avec un label "OP" en dessous si la liste d'utilisateur est sur un thread
• Mini-carte utilisateur avec avatar, informations pertinente, raccourci vers la dernière activité, etc.
• Popup responsive (prend tout l'écran sur téléphone/petit écran avec bouton retour, simple popup sur grand écran) avec la liste des utilisateurs
• Popup pour chaque utilisateur avec les informations cruciales sur l'utilisateur

Refactoring: URL en kebab-case (systématiquement)

Les URLs et sous-URL du site devraient être en kebab-case le plus possible
cf StackOverflow, d'autres sources dans le thread

Front-end : Breadcrumbs

A partir du Router, générer en en-tête de chaque page un Breadcrumb pour simplifier la navigation

• Component de base du breadcrumb (hooked au Router)
• Possibilité de customiser le breadcrumb avec des préfixes, suffixes, etc. pour garder en mémoire différentes origines dans la navigation
• Considérations responsives : différents breacrumbs en fonction de la taille de l'écran et du device

🖥️ Thread

Les threads incorporent:

• un header avec les méta-informations les plus importantes du post (titre, date de publication, dernière activité, nombre de vues, de réponses, de commentaires...)
• une toolbar à droite similaire à celle des issues GitHub (que vous pouvez voir sur votre droite en plein écran)
• une partie centrale qui contient la "View" du Thread (#12 , #13)

La toolbar doit contenir les informations suivantes sur le post:

• Tags (#8)
• Participants au thread (#17)
• Team assignée (#51)

Ajouter un slider mobile-friendly / auto-slide pour la landing page

Swiper n'étant pas fonctionnel sur le build du site, il faut trouver une alternative à cette librairie.

L'objectif est de rendre l'UI plus mobile-friendly et de faire une landing page animée.

Back+Front-end : Customisation du niveau de notifications

Il doit y avoir plusieurs niveaux de notifications (cf. #52) possibles propres à un favori donné:

Notification pour chaque activité > Notification pour une nouvelle réponse > Notification pour une réponse validé/un avancement du post > Notification pour une fermeture de post

Ce niveau de notification devra décider de si une notification est envoyée à l'utilisateur lorsqu'il y'a une activité sur un post en bookmark

Ce niveau de notification doit être modifiable depuis l'espace où l'on peut consulter ses favoris (cf. #55)

PostCard (preview card d'un Post dans les listes de Post)

• Cas où le post est vide (afficher un message erreur à la place)
• Update des champs avec la nouvelle entité de post en BDD
• Design responsive
• Design plus friendly pour les listings ?

Refactoring des styles (avec SCSS)

TailwindCSS:

• Transitionner tous les components sur Tailwind
• Enlever la dépendance scrollbar (refaire un mini-module)
• Transitionner sur Tailwind 3.0

Augmentation de la modularité des styles:

• Utilisation de @ extend pour étendre les classes de bases
• Passage en SCSS => compression des styles de themes.css + fonctions utilitaires
• Regroupement des classes réutilisables dans assets/scss

Général:

• Ajout d'un linter (Stylelint)
• Linting

Back-end : Reply

Les "Replies" (réponses) peuvent être placés en réponse à un Post dans un Thread

TODO:

• CRUD (avec permissions cohérentes) : corps, votes

Refactoring: ThreadCompactView

• Refactoring UI complet
• Hook à la DB

Refactoring: Authentification via cookie JWT (httpOnly) + Refactoring de 'file-upload'

• Header 'Authorization': 'Bearer ' => Cookies (res.cookie => les queries d'auth renvoient maintenant les champs publics de l'utilisateur et les tokens via des cookies httpOnly)
• Suppression de authHeader dans VueX (front)
• Suppression du stockage en localStorage des tokens (juste les champs publics de l'utilisateur sont stockés)
• Logout avec query serveur (car httpOnly)
• Refactoring des queries axios (withCredentials/credentials: 'include' pour le login/logout)
• Refactoring de FileUpload.vue => ajout d'un module files dans le store VueX (pas de requêtes directement dans les components)
• Ajout d'un lien vers 'file_upload' dans la sidebar

Refactoring: SearchQuery

- [ ] Utiliser des margins plutôt qu'un fixed flex avec z-index pour cacher l'expander
- [ ] UI par onglet plutôt que par ligne pour chaque catégorie d'item recherchable
- [ ] Hook à la DB pour les documents

Back-end : Comment

Les "Comments" (commentaires) peuvent être placés en dessous de Posts, de Replies ou de Documents.

TODO:

• CRUD (avec permissions cohérentes) : corps, ressources externes liées
• Interdire les downvotes (upvote uniquement)

Espace : Docs Sharing

TODO:

• Formulaire d'upload
• Formulaire de requête
• Querying/listing de documents (#56)
• Favoris (#54)

Refactoring Fin-Octobre/Début-Novembre 2021

Dév.

• #19
• #20

Back-end

• #28
• #32

Back-end + Front-end (VueX)

• #34

Front-end

Convention

• #35

Styles

• #27

Vue3

• #30
• #31

Components

• #29
• #21
• #22
• #23
• #24
• #25
• #26

Refactoring: Composition API

Prioriser le Composition API aux lifecycles pour des tâches ne nécessitant pas d'accès direct à la DOM

Front-end : Favoris : espace personnel où consulter ses favoris

Un dossier de favori responsive où l'on peut voir la liste de ses contenus favoris, les enlever de ses favoris et voir toutes les informations importantes du contenu favori en préview.

Attention : il faut faire attention à représenter uniformément les différents types de contenus pour que cela reste intuitif pour l'utilisateur (post, reply, comment, fichier)

Espace Favoris

Un post, une réponse à un post, un commentaire et un document peuvent tous être mis en favori, ce qui signifie qu'un utilisateur pourra le retrouver dans son espace personnel, dans un dossier "favoris" ; il s'agit d'une alternative au bookmark pour garder un raccourci vers des ressources remarquables sans être notifié de l'activité sur les ressources.

TODO:

• CRUD des favoris
• #55

Refactoring: Réorganisation des components / suppression des components inutiles

• Post => PostCompactView / Drop de PostView (75463d6)
• Drop de Carousel (remplacé par swiper)
• Drop des components vides
• Renommer les components pour suivre la nouvelle nomenclature (Post..View => Thread..View, PostListingCard => PostCard, Footer => PageFooter)

Refactoring: Uploads

• Restructuration de l'arborescence de uploads: sous-dossiers par genre de fichier (fileKind) (avec .gitignore & .gitkeep pour garder les dossiers vides mais ne jamais push les fichiers uploadés)
• Pas de sous-dossier par upload !
• Type énuméré de référence "file-kinds.enum.ts" pour les genres de fichiers
• Toujours préciser le fileKind dans le service de création des fichiers après upload !
• Servir les fichiers sur endpoint (get-file/:id)
• file/upload => file-upload (files, le module + controller général, reste files)
• course-doc => study-doc

Back+Front-end : S'abonner à un post

Un utilisateur peut s'abonner à un post de sorte à ce qu'il recoive des notifications lorsqu'il y'a de l'activité sur le Thread du Post. L'utilisateur peut ensuite choisir de n'être notifié que pour certains types d'activités sur le post, ou de se désabonner

Similaire au fonctionnement des Subscribers sur les issues GitHub.

Prérequis:

• Système de notifications
• Activités des threads

Ensuite, à faire :

• Possibilité de s'abonner (back + front)
• Customisation du niveau de notifications

:clipboard: Démo Janvier 2022

Sous-espaces :

• #2
• #41
• #42
• #43
• #44 => pour plus tard

Components généraux :

• #47 => jugé inutile pour la première démo
• #48
• #49
• #50 => à faire avec la landing page

N'hésitez pas à suggérer vos propres Issues !

Like/dislike

Refactoring: AdminSide

- [ ] Refactoring UI complet
- [ ] Rajouter différents types de filtres
- [ ] Hook à la DB
- [ ] Ajouter des actions

⚙️ Team

EDIT:

Première implémentation terminée, il manque :

• Les sous-teams
• #163

Front-end : Dialog

Mettre en place un système de popup simple pour indiquer si une action s'est réalisée avec succès ou non

TODO:

• Réaliser le Dialog
• Utiliser dans le Login
• Utiliser dans le PostNew
• Utiliser dans le FileUpload

Back+Front-end : Bookmark : Système de notifications (activité des Thread)

Chaque utilisateur à une "boîte de réception" de notifications, chaque notification peut avoir été vue ou ne pas avoir encore été vue.

Dès qu'une activité est faite sur un post/document sur lequel le user a un bookmark, on vérifie le niveau de notification du bookmark (cf. #53) ; si l'activité est incluse dans le niveau actuel de notification, une notification est envoyée via un server-sent event. Le user renvoie une requête POST s'il a bien vu la notification. Sinon, la notification est considérée comme non-vue.

A la prochaine connexion de l'utilisateur, on vérifie qu'il n'a pas de notifications non-vues. Sinon, on met a jour sa boîte de réception sur le front avec les nouvelles notifications non-vues, en attendant qu'elles soient vues.

Front-end : TheadCompactView (vue d'un Post avec les Replies + les Comments sous le Post et les Replies)

La "Compact View" est incorporée dans la partie centrale d'un Thread (#11) si le Thread est actuellement en mode "Compact View".

La Compact View contient:

• le Post (#38)
• les Replies (réponses) (#39)
• les Comments (commentaires) sous le Post et les Replies (#15)

L'idée serait proche du design des threads StackOverflow (exemple)

Refactoring: PostNew

• Régler les problèmes de bordures et de couleur
• Améliorer le style de Card
• Remplacer les panels de droite par des guidelines ("A faire", "A ne pas faire")
• Responsive (+ panels en collapside)