Application CAMPUS, implémentation de fonctionnalités et objectifs

[Bababibel]

Bonjour à tous les zouzs!

Après avoir eu l'idée il y a fort longtemps pour l'asso musique Insarpège, d'utiliser une application dédiée pour la gestion de planning et de tout le bazar qui va avec, me voilà qui vous rejoins.

L'idée est d'apporter un lot de fonctionnalités à l'application Campus mobile pour se détacher d'une simple appli "de news", et lui donner une véritable fonction au sein des différentes associations.
Et évidemment pour éviter que chacun développe son truc dans son coin, l'objectif est d'utiliser Campus pour réunir toutes les assos au même endroit. (keur raph le boss)

Dans un premier temps, j'ai établi une sorte de cahier des charges des implémentations à faire, pour l'association Insarpège puisque c'est la finalité. Par contre, la quasi totalité des fonctionnalités pourront se généraliser à l'ensemble des associations pour profiter à tous, notamment une gestion des membres des assos (voir plus bas).

J'aurai besoin de votre avis avant de me lancer dans quoi que ce soit, des fois que je sois passé à côté d'un truc, surtout l'avis du beau Raphaël, au niveau de la faisabilité des différentes idées.

Je vous partage en copié/collé mon bloc-note que je prépare depuis pas mal de temps, avec plus de détails sur les fameuses fonctionnalités.

---

*Système d'annonces : envie de jouer, recherche d'un membre, groupe... etc
*Système de rappel des évènements
*Système de réservation d'un planning
*Système de stockage des données du planning avec les réservations

Ces modifications seront apportées dans un premier temps pour l'asso INSARPEGE car la plupart des modifications lui sont dédiées.
Le système de gestion de membres (voir ci-dessous) sera bien évidemment étendu à l'ensemble des assos s'il fonctionne correctement

Implantations :

Système de gestion de membres de l'asso :

• Utilisateur : peut suivre les notifications en lien avec l'asso
• Membre : Membre de l'asso, peut accéder au planning, aux annonces, réserver et poster des créneaux ou des annonces. Désignés par les Admins/Super-Admin
• Admin : Membres du BR, plein accès sur l'édition, la suppression des annonces/réservations. Désignés par le(s) Super-Admin(s)
• Super-Admin : Président (+ vice-prés?), lui seul peut gérer la liste des Admins
  *Note : La différence entre Admin et Super-Admin est qu'un Admin simple ne peut pas ajouter d'autres Admins. Fonction réservée au Super-Admin

Ces implantations impliquent l'ajout d'un panel de configuration au Super-Admin pour "gérer" les membres de l'association.

Ajout de nouvelles fonctionnalités reposant sur le système de gestion de membres :

• Dans l'onglet "Les assos", rajouter en haut de la page un bandeau avec les assos en FAVORIS, choisies par l'utilisateur (histoire de les avoir rapidement sous la main)
• Quand on clique sur une asso, affichage de la page de l'association, avec les fonctionnalités suivantes :
  • La page d’accueil "contrôle" contient deux parties :
    • Partie haute, sur une ligne, affichant le planning des réservations DU JOUR (accès rapide). Au clic :
      • Ouvre la page avec un planning complet sur la semaine
      • Contient un bouton "Réservation" pour placer un créneau sur un espace LIBRE du planning

*** Réservation ***
Se caractérise par une tranche horaire, d'un jour unique, avec le nom du membre qui réserve et une description rapide (groupe qui joue par ex)
Seul un admin ou le membre propriétaire d'une réservation peut supprimer/éditer cette dernière
Impossible de réserver sur un créneau déjà pris
Petit + : ajouter en feat la liste des membres qui réservent le créneau, et chaque membre peut éditer/supprimer la réservation sur laquelle ils sont affectés

Partie basse, environ 40% de la hauteur de la page, avec les annonces des membres. Au clic :
Ouvre la page avec la liste des annonces, dans l'ordre de priorité (Haute -réservée aux admins-, & Normale) puis par ordre chronologique
Contient un bouton "Poster une annonce"

*** Annonce ***
Se caractérise par un type (recherche, information, postulation de musicien, etc), le nom du membre qui poste, avec un titre et une description détaillée
Seul un admin ou le membre propriétaire d'une annonce peut supprimer/éditer cette dernière
Possède une date de péremption, et l'annonce disparait automatiquement à expiration (pour éviter d'avoir 400 annonces obsolètes à la fin de l'année)
Petit + : Utiliser les notifications pour les membres lorsqu'une annonce est postée.

---

Ouais je sais c'est long, navré mais j'ai préféré détailler pour avoir une ligne directrice précise, surtout pour le début.

N'hésitez pas si vous avez d'autres idées ou si y'a des trucs qui vous plaisent pas.

Des bisous,
Baptiste

[Barbapapazes]

Joli projet ! Mais clairement, y a du boulot ! En plus d'ajout direct dans l'appli campus, il va te falloir une base de données et donc un back pour gérer toutes tes requêtes (inscription, création d'un réservation...). Il faut aussi que tu vois ce que stock @raphaelsfeir une fois connecté dans l'application, puisque il utilise le cas de l'insa. Car tu parles de utilisateur et membre mais comment faire la différence ? Comment choisir qui est qui ?

ça ressemble beaucoup à ce qu'on fait avec TutorINSA au niveau gestion d'annonces et maintien d'un calendrier.

[Bababibel]

Ah ça oui y'a du boulot ! Mais honnêtement une fois qu'on aura implémenté ça, on pourra commencer à vraiment déployer beaucoup de fonctionnalités sur l'appli. C'est un peu le but au final, de faire en sorte qu'elle permettre de regrouper les services des assos...

Je verrai avec @raphaelsfeir effectivement, que je vois quel modèle il a utilisé pour modéliser les données entre l'appli et la base de données.

Pour le système de gestion de membres, je pensais dans un premier temps ajouter les respos des assos en tant que Super-Admin, et ensuite chacun se débrouillera pour ajouter sa liste de membres, et pour sa propre modération. L'objectif c'est de déployer ce système de hiérarchie dans l'appli pour définir les autorisations.

Je sais pas si c'est très clair dans ce que j'ai détaillé au dessus, mais chaque asso possèdera sa propre "liste" de membres, et via l'appli, permettre aux admins d'ajouter ou retirer les membres intéressés.
Une fois que ça sera fonctionnel, on pourra commencer les fonctionnalités en dur avec le système de permissions qui va bien !

[raphaelsfeir]

Une des fonctionnalités que j'ai déjà commencé à développer (je n'ai pas encore eu le temps de push tous les outils de campus comme l'API et ce fameux truc) c'est une interface web.
L'idée dessus est pouvoir :

Gérer les évènements (créer, modifier, supprimer)
Récupérer un QR Code de l'événement pour le mettre sur l'affiche (on le scanne et ça ouvre l'appli sur la page de l'événement)
Gérer les membres de l'asso (ajouter et supprimer)

Donc la fonctionnalité de gestion des membres est déjà implémentée ! L'une des difficultés que j'ai rencontré pour cette interface (et c'est la raison pour laquelle j'ai mis son développement en pause) est que la connexion étant obligatoire il est très difficile (voire impossible, je n'ai pas compris comment le lier) de connecter l'utilisateur grâce au CAS en liant la base de données appli et la base de données INSA.

Pourquoi j'ai fait une interface web ?
La fonctionnalité originelle est la génération du QR Code pour l'affiche. Comme l'affiche n'est pas créée sur portable, l'interface web me semblait le plus approprié. Puis, j'ai commencé à ajouter des fonctionnalités qui me semblaient sympas. Au niveau ergonomie, permettre la gestion de l'asso sur portable est une bonne idée mais je pense que l'interface web se révélera plus simple et pratique à utiliser (sans compter les problèmes natifs à gérer sur portable)

[Barbapapazes]

j'aime beaucoup l'idée du QR code, ça peut vraiment être sympa pour les affiches des events pour permettre aux personnes d'avoir plus d'info.

pour ce qui est de l'interface web, ça semble pertinent de s'en servir comme support pour les gestinnaires et laisser l'appli tranquille, uniquement pour les users lambdas

et pour l'histoire du cas, si j'ai bien compris, tu n'as pas réussi à obtenir les info de l'utilisateur depuis sa connexion ?

[Anatharr]

C'est vrai que l'idée du QR code est très intéressante, mais plutôt que de faire un nouveau site pourquoi ne pas ajouter ces fonctionnalités directement au nouveau site campus ? Sachant qu'on comptait faire une intégration de l'API dans tous les cas ce serait plus compréhensible pour l'utilisateur que ce ne soit pas trop dispersé

Sinon super idées, ce serait génial si tout le monde pouvait créer des todo lists sur GitHub, surtout pour l'appli mobile, dans l'onglet Projects. Ça permettra d'avoir une vue d'ensemble des idées, de leur avancement, et on pourra donc répartir un peu le boulot et ne pas faire chacun notre truc dans notre coin <3

[Anatharr]

Et sinon par rapport au CAS on peut réessayer de (re)demander à la DSI de register le site campus comme un service et prier pour un miracle ?

[Barbapapazes]

Et sinon par rapport au CAS on peut réessayer de (re)demander à la DSI de register le site campus comme un service et prier pour un miracle ?

Ou demander à ce qu'il fasse un oauth ?

[raphaelsfeir]

Ou demander à ce qu'il fasse un oauth ?

Le oauth me semble compliqué...

j'aime beaucoup l'idée du QR code, ça peut vraiment être sympa pour les affiches des events pour permettre aux personnes d'avoir plus d'info.

On a déjà fait un test pour une projection INS'Action, il y a eu pas mal de réactions c'était sympa !

pour ce qui est de l'interface web, ça semble pertinent de s'en servir comme support pour les gestinnaires et laisser l'appli tranquille, uniquement pour les users lambdas

C'est ce qui sera le plus simple oui

et pour l'histoire du cas, si j'ai bien compris, tu n'as pas réussi à obtenir les info de l'utilisateur depuis sa connexion ?

Actuellement, la connexion sur l'appli est une webView, rien d'autre. J'affiche la page de connexion et j'analyse les redirections. Dès que je récupère un ticket donné par l'authentification (le CAS fonctionne comme ça) je l'envoie à l'API de Campus. Celle-là va checker sa validité sur le ServiceValidate du CAS et me retourner un arbre XML qu'il suffit de parser pour récupérer le nom d'utilisateur.
Une fois qu'il est récupéré mon API se charge de vérifier sa présence dans la base de données Campus et renvoie des réponses différentes selon les situations. En parallèle de tout ça, dans l'appli, j'affiche un petit chargement et récupère la réponse de l'API pour la stocker dans le store.

Bref, pour l'instant la connexion est rendue possible grâce à cette inclusion de la WebView dans le parent de l'appli : inclusion qu'il n'est pas possible de faire, à ma connaissance (le cross site ça marche pas et heureusement), sur un modèle web qui est linéaire.
À savoir que le CAS fonctionne telle façon que lorsque l'authentification a réussi, il y a une redirection vers le service indiqué dans l'URL (d'où le rôle du Service Validate)

[Barbapapazes]

C'est vrai que l'idée du QR code est très intéressante, mais plutôt que de faire un nouveau site pourquoi ne pas ajouter ces fonctionnalités directement au nouveau site campus ? Sachant qu'on comptait faire une intégration de l'API dans tous les cas ce serait plus compréhensible pour l'utilisateur que ce ne soit pas trop dispersé

Je suis pas particulièrement pour, le fait de couper, ça permet de maintenir plus facilement, après, si on commence à se retrouver avec 50 languages ça va devenir compliqué mais j'essaie de rendre le site campus le plus autonome en terme de dev une fois mis en place. Et je pense que lui mettre dedans, le dashboard admin, ça le compliquerais beaucoup (déjà qu'il est pas hyper-simple vu que tout est automatique au niveau de la création des pages). Et le site campus, c'est la vitrine du campus pour les extérieurs, les nouveaux arrivants ou pour découvrir un peu plus certaines assos.

Après je suis pas fermé mais il faudra voir exactement ce que l'on veut y mettre dedans et comment.

[raphaelsfeir]

Je ne suis plus en poste donc mon avis ne compte pas trop, mais je vous conseille de garder le site Campus sous WordPress. Ça permettra aux novices de le gérer facilement et la grosse partie est déjà faite (il suffit juste de créer un thème plus propre et le tour est joué, en une semaine c'est réglé).
Après je suis d'accord, le site Campus reste la vitrine du BDE, y stocker les éléments de gestion de l'appli n'est pas forcément la meilleure solution.
Enfin, quant aux langages, au vu des cours dispensés dans l'école, chacun devra dans tous les cas faire une partie importante de travail personnel pour apprendre les langages, donc autant prendre les langages (à comprendre frameworks également) qui vous arrangent le plus avant de regarder le nombre de langages différents que vous utilisez ; je pense à PHP pour le WordPress du site, peut-être Angular ou React pour l'interface de gestion (actuellement Angular) etc.

[Barbapapazes]

Hello,

Je sais pas si vous en aviez connaissance de l'appli campus de Toulouse: https://www.facebook.com/campus.insat/

Et on peut trouver aussi le repo:
https://git.etud.insa-toulouse.fr/vergnet/application-amicale

[raphaelsfeir]

Je n'ai pas trouvé leur appli très parlante, j'ai plutôt discuté avec le responsable de l'appli INSA Rennes: ins'app, je vous envoie le Git dès que je peux il est très bien fait et utilise la même technique que moi pour la connexion au CAS (webView & co)

[Barbapapazes]

C'est lui ? https://github.com/thomas-bouvier/insapp-android