PyROS

SP create : Un Observer peut créer un nouveau Proposal (SP) (pour une Période spécifique future)
L’utilisateur Observer devient alors “SP-PI” de ce SP
(v2) Le statut du SP est alors le statut initial : “1 - Proposal-draft”
Il lui associe un Institute (hérite ainsi de son %quota global)
Il peut lui associer une Time Period (obligatoire seulement pour la “soumission”)
Le SP-PI doit voir TOUS les users (ceux qui n’ont pas de SP et ceux qui sont dans son SP)
Pas de vote ou de validation, le SP est validé par défaut et utilisable (dès sa création)

SP update : Un Observer peut modifier les SPs qu’il a créés (v2 tant qu’ils sont encore dans le statut “Proposal” (pas encore soumis à validation)

SP submit (v2) : Un Observer peut soumettre un SP qu’il a créé pour le rendre disponible à la validation par le TAC :
Une Time Period doit obligatoirement être choisie pour que le SP puisse être soumis
Le statut du SP est alors “Proposal-to-TAC” (pour une période donnée)
Un SP PI peut soumettre à nouveau un ancien SP qu’il avait déjà créé
Pour un SP donné, on conservera l’historique de toutes les soumissions sur différentes périodes

SP notation (v2) : Un Referee (TAC) peut juger/noter un SP qui est dans le statut “Proposal-to-TAC” pour le rendre disponible à la validation par le Unit-PI
Le statut du SP est alors “Proposal-to-Unit-PI”

SP validation (v2) : Le Unit-PI peut valider un SP qui est dans le statut “Proposal-to-Unit-PI”
Le statut du SP est alors “SP”
Il lui attribue aussi un quota en heure (au sein de l’institut) et une priorité
Il peut aussi faire l’allocation du temps d’observation accordé

SP users : seul Le SP-PI (ou Unit-PI) peut ajouter des utilisateurs sur son SP de statut “SP”
Un SP-PI doit pouvoir ajouters/retirer des users dans son SP (à partir de la vue détaillée du SP)
Le SP-PI doit voir tous les users (ceux qui n’ont pas de SP et ceux qui sont dans son(ses) SP)