Commit 7c16c150 authored by Laurent Lécluse's avatar Laurent Lécluse
Browse files

MAJ doc

parent 82c85bfa
......@@ -40,20 +40,67 @@ Objectif : Doubles statuts et refonte des données personnelles
## Notes de mise à jour
* PHP 7.4 minimum requis : attention à bien mettre à jour vos serveurs
Merci de lire ceci **AVANT** d'entamer la mise à jour!!
* Cette version comporte de nombreux changements en particulier sur la gestion des intervenants.
La migration ne sera possible qu'à partir de la version 14.11.
Si vous êtes sur une version antérieure à la 14, merci de migrer en 14.11 **AVANT** de migrer vers la 15.
La mise à jour n'est en effet pas réversible.
* La base de données ayant été remaniée, il vous faudra adapter vos connecteurs RH. En particulier les vues sources visant les tables INTERVENANT, STRUCTURE, PAYS et DEPARTEMENT.
Une nouvelle documentation sur les connecteurs est disponible ici : [Import de données via les connecteurs](doc/Connecteurs%20Import/Connecteurs%20IMPORT.md).
Nous vous recommandons en outre de vous entrainer au préalable sur une instance de préproduction avant de passer en production.
* Lors de la mise à jour, les différents objets qui concernent vos connecteurs et sur lesquels il y a des changements à faire s'afficheront en erreur. Il vous revient de mettre à jour par vous-mêmes ces connecteurs.
### 1. PHP7.4
PHP 7.4 est maintenant requis : attention à bien mettre à jour vos serveurs
* Attention : un bug est connu et en cours de résolution : il se produit lorsqu'en tant qu'intervenant vous saisissez vos données personnelles. Une page d'erreur s'affiche au moment ou vous sélectionnez votre statut. Une mise à jour de la page suffit pour pouvoir continuer la saisie du formulaire.
### 2. OSE 14.11 minimum
Pour cette version, il n'est pas possible de migrer depuis dde trop anciennes instances de OSE.
Avant la V15, vous devrez préalablement migrer en version 14.16.
Et ce n'est qu'à partir de la 14.16 que vous pourrez migrer vers la 15.
### 3. Connecteurs
La structure de la base de données OSE a évolué.
Voici pour information la liste des changements opérés au niveau des structures de données : ([Changements de structures BDD 14->15](doc/Divers/migration-bdd-14-vers-15.sql)).
Ce script ne doit pas être exécuté, la procédure de migration se chargera de cela toute seule.
Certains de vos connecteurs devront être adaptés, en particulier au niveau RH.
De même, si vous avez créé des requêtes personnalisées, des états de sortie, attention à bien tenir compte ces changmements!
Niveau connecteurs, les changements à faire sont les suivants :
* Vue source [SRC_PAYS](doc/Connecteurs%20Import/Création%20tables/PAYS.md) :
* LIBELLE_COURT et LIBELLE_LONG disparaissent au profit de LIBELLE
* nouvelle colonne CODE
* Vue source [SRC_DEPARTEMENT](doc/Connecteurs%20Import/Création%20tables/DEPARTEMENT.md) :
* LIBELLE_COURT et LIBELLE_LONG disparaissent au profit de LIBELLE
* nouvelle colonne CODE
* Nouvelle table [VOIRIE](doc/Connecteurs%20Import/Création%20tables/VOIRIE.md) :
* Possibilité d'importer les voiries en provenance de votre système d'information.
* Vue source [SRC_STRUCTURE](doc/Connecteurs%20Import/Création%20tables/STRUCTURE.md) :
* Changement du format des adresses. Vouc pourrez vous inspirer des différents connecteurs existants pour adapter le votre.
* Vue source [SRC_INTERVENANT](doc/Connecteurs%20Import/Générique/SRC_INTERVENANT.sql) :
* Il y a ici de nombreux changements.
* La vue matérialisée [MV_INTERVENANT](doc/Connecteurs%20Import/Création%20tables/INTERVENANT.md) devra être adaptée pour fournir toutes les colonnes nécessaires.
* La vue [SRC_INTERVENANT](doc/Connecteurs%20Import/Générique/SRC_INTERVENANT.sql) doit être utilisée telle quelle, sans adaptation de votre part
* Suppression d'anciennes tables, dont les vues sources correspondantes doivent être supprimées par vos soins :
* DROP VIEW V_DIFF_ADRESSE_INTERVENANT
* DROP VIEW SRC_ADRESSE_INTERVENANT
* DROP VIEW V_DIFF_ADRESSE_STRUCTURE
* DROP VIEW SRC_ADRESSE_STRUCTURE
* Ces vues devront être supprimées AVANT la mise à jour. Le script de migration ne le fait pas automatiquement afin de vous laisser le temps de les sauvegarder le cas échéant.
Plus généralement, [une nouvelle documentation sur les connecteurs est disponible](doc/Connecteurs Import/Connecteurs IMPORT.md).
### 4. Activation du stockage des fichiers dans le filesystem
Pas obligatoire, mais recommandé (sur votre instance de production).
* [Activer le stockage des fichiers dans le système de fichiers plutôt qu'en base de données (recommandé pour la production)](doc/Stockage-fichiers.md)
### 5. Gestion des employeurs
OSE peut maintenant gérer un référentiel des employeurs
Vous avez deux options au choix :
* soit importer votre propre liste d'employeurs via une vue source [SRC_EMPLOYEUR](doc/Connecteurs%20Import/Création%20tables/EMPLOYEUR.md) dédiée, à l'instar des autres connecteurs
* soit injecter dans OSE la totalité des employeurs de France, liste issue du référentiel SIRENE via la commande `./bin/ose update-employeur`
Cette commande devra être exécutée de manière régulière, une fois par mois environ si vous voulez que votre référentiel d'employeurs soit à jour.
# OSE 14.17 (en cours de développement)
......
......@@ -10,6 +10,34 @@ Colonnes nécessaires :
|RAISON_SOCIALE |VARCHAR2|250 |Non | |
|NOM_COMMERCIAL |VARCHAR2|250 |Oui | |
|IDENTIFIANT_ASSOCIATION|VARCHAR2|250 |Oui | |
|CRITERE_RECHERCHE |VARCHAR2|500 |Oui | |
|Z_SOURCE_ID |NUMBER | |Non |==> SOURCE.CODE|
|SOURCE_CODE |VARCHAR2|100 |Oui | |
Voici ci-dessous un prototype de vue qui pourra vous inspirer :
```sql
CREATE OR REPLACE FORCE VIEW SRC_EMPLOYEUR AS
WITH source_query AS (
SELECT
'votre SIREN' siren,
'votre RAISON_SOCIALE' raison_sociale,
'votre NOM_COMMERCIAL' nom_commercial,
'votre IDENTIFIANT_ASSOCIATION' identifiant_association,
'votre Z_SOURCE_ID' z_source_id,
'votre SOURCE_CODE' source_code
FROM
dual
)
SELECT
sq.siren siren,
sq.raison_sociale raison_sociale,
sq.nom_commercial nom_commercial,
sq.identifiant_association identifiant_association,
-- optimisation pour accélérer les recherches
ose_divers.str_reduce( sq.raison_sociale || ' ' || sq.nom_commercial || ' ' || sq.identifiant_association ) critere_recherche,
s.id source_id,
sq.source_code source_code
FROM
source_query sq
JOIN source s ON s.code = sq.z_source_id
```
\ No newline at end of file
......@@ -9,6 +9,8 @@ Ici, principalement pour des raisons de performances, ilest recommandé de proc
* Utiliser [SRC_INTERVENANT](../Générique/SRC_INTERVENANT.sql) en tant que vue source. Cette vue SRC_INTERVENANT est commune à tous les connecteurs.
Vous devez l'utiliser telle quelle.
Votre vue matérialisée MV_INTERVENANT devra contenir les colonnes suivantes :
|Colonne |Type |Longueur|Nullable|Commentaire |
|--------------------------|--------|--------|--------|-----------------------------|
|CODE |VARCHAR2|60 |Non | Identifiant unique de l'individu dans le système d'information l'individu |
......@@ -69,5 +71,3 @@ Par défaut, c'est `supannEmpId`, mais vous pouvez le personnaliser dans le fich
Exemple de vue matérialisée :
[MV_INTERVENANT](../Harpège/MV_INTERVENANT.sql)
Attention : il faudra adapter le code permettant de faire le mapping au niveau du statut ainsi que de la discipline.
\ No newline at end of file
This diff is collapsed.
# Stockage des fichiers
## Présentation
Dans OSE, les fichiers, que ce soient les pièces justificatives ou les contrats ou tout autre fichier téléversé,
sont par défaut stockés dans la table FICHIER et leur contenu dans la colonne CONTENU.
Au bout de plusieures années d'exploitation, cela devient problématique, car le tablespace Oracle est extensible jusqu'à 32Go, mais par au-delà.
Il existe donc une alternative qui permet de stocker ces données directement dans le système de fichiers de votre serveur.
## Mise en œuvre du stockage dans le système de fichiers
Le stockage dans le système de fichiers est recommandé pour une instance de production uniquement.
Deux opérations sont nécessaires pour pouvoir stocker vos données dans votre système de fichiers :
### 1. Configuration
Dans votre fichier config.local.php, la rubrique "fichiers" doit être personnalisée.
Si vous avez un ancien fichier config.local.php qui ne comporte pas cette ubrique, veuillez copier/coller cette dernière depuis le fichier [config.local.php.default](../config.local.php.default).
Exemple de configuration :
```php
/* Fichiers */
'fichiers' => [
/* file => dans le système de fichiers par défaut, bdd => en base de données par défaut */
'stockage' => 'file',
/* Répertoire où seront stockés les fichiers (pièces justificatives, contrats déposés, etc.
* A savoir : le répertoire par défaut data/fichiers est ignoré par GIT.
* Il est nécessaire de prévoir une sauvegarde de ce répertoire.
* IMPORTANT : ce répertoire doit être accéssible en lecture/écriture par l'utilisateur www-data d'Apache.
*/
'dir' => __DIR__ . '/data/fichiers',
],
```
Paramètre "stockage" :
- bdd => Stockage par défaut directement dans la base de données
- file => Stockage dans le système de fichiers, dans un répertoire spécifique
Paramètre "dir" :
- Ce paramètre vous permet de préciser dans quel répertoire stocker ces fichiers. Vous pouvez utiliser
comme ci-dessus la variable magique __DIR__ qui permet de partir du répertoire OSE, ou alors opter pour un chemin absolu en débutant par "/".
A Caen, nous avons opté pour un répertoire data de OSE lié symboliquement à un répertoire monté en réseau sur un espace de stockage distinct du serveur et sauvegardé régulièrement.
Au cas ou le fichier ne pourrait pas être enregistré (espace disque insuffisant, problème réseau, droits mal configurés, etc.), alors le contenu sera stocké en base de données afin de ne pas être perdu.
### 2. Transfert des données en base vers le système de fichiers
Une fois votre configuration OK, un script vous permet de transférer tous les fichiers stockés dans votre base de données vers le système de fichiers, soulageant ainsi votre tablespace.
```bash
./bin/ose fichiers-vers-filesystem
```
### 3. Exploitation
Si OSE a besoin d'accéder au contenu d'un fichier, en mode "file", l'application ira chercher d'abord le contenu dans le système de fichier et s'il ne trouve rien il cherchera dans FICHIER.CONTENU.
# OSE : Correction d’une fiche de service
## Étape 1 : récupérer l’ID du service concerné
Dans la fiche service de l’intervenant, placer le curseur de la souris sur l’icône « Modifier » représentée par un crayon.
Ensuite, dans l’URL du lien qui s’affiche dans le bas de la fenêtre du navigateur, identifier l’ID (110746 dans l’exemple ci-dessus) et le mémoriser.
![Identifier un ID de service][service_correction_bdd]
## Étape 2 : Aller dans la base de données pour récupérer les volumes horaires concernés
Exécuter la requête suivante pour récupérer toutes les informations nécessaires à la suite de la procédure :
```sql
SELECT
/* Libellés pour retrouver la bonne ligne */
tvh.libelle type_vh,
ep.code element,
str.libelle_court structure,
p.libelle_court semestre,
ti.code type_intervention,
mnp.libelle_court motif_non_paiement,
src.code source,
vh.horaire_debut horaire_debut,
vh.horaire_fin horaire_fin,
/* Identifiants */
s.id service_id,
vh.id volume_horaire_id,
vh.auto_validation auto_validation,
vvh.validation_id validation_id,
vh.contrat_id contrat_id,
/* Heures */
vh.heures heures
FROM
volume_horaire vh
JOIN service s ON s.id = vh.service_id AND s.histo_destruction IS NULL
JOIN type_volume_horaire tvh on tvh.id = vh.TYPE_VOLUME_HORAIRE_ID
JOIN periode p on p.id = vh.periode_id
JOIN type_intervention ti on ti.id = vh.type_intervention_id
JOIN source src ON src.id = vh.source_id
LEFT JOIN motif_non_paiement mnp ON mnp.id = vh.motif_non_paiement_id
LEFT JOIN element_pedagogique ep ON ep.id = s.element_pedagogique_id
LEFT JOIN structure str ON str.id = ep.structure_id
LEFT JOIN VALIDATION_VOL_HORAIRE vvh on VVH.VOLUME_HORAIRE_ID = vh.id
LEFT JOIN validation v ON v.id = VVH.VALIDATION_ID AND v.histo_destruction IS NULL
WHERE
vh.histo_destruction IS NULL
AND s.id = /* ID DU SERVICE */
;
```
## Étape 3 : intervention en base de données
### Procédure
Une fois que vous avez identifié le ou les volumes horaires à traiter, plusieurs cas de figure se présentent :
* Si le volume horaire a un contrat, alors il est impossible de le modifier, il faut donc supprimer d’abord le contrat correspondant dans OSE avant de pouvoir le modifier.
* Si le volume horaire a une validation, alors il faut
* Soit supprimer la validation dans OSE (mais cela va impacter aussi d’autres volumes horaires)
* Soit retirer un volume horaire spécifique d’une validation (procédure ci-dessous).
Ensuite, procéder aux opérations suivantes :
* Historiser le volume horaire (procédure ci-dessous)
* Recalculer la feuille de route de l’intervenant : la fiche de service ayant changé, il convient de recalculer la feuille de route de l’intervenant, car cela peut avoir de l’influence sur l’état d’avancement du Workflow.
### Requêtes :
Retirer un volume horaire d’une validation (s’il ne fait pas l’objet d’un contrat) :
```sql
DELETE FROM VALIDATION_VOL_HORAIRE WHERE volume_horaire_id = /*VOLUME_HORAIRE ID*/
```
Historiser un volume horaire :
```sql
UPDATE volume_horaire SET histo_destruction=SYSDATE, histo_destructeur_id=/*UTILISATEUR_ID*/ WHERE volume_horaire_id = /*VOLUME_HORAIRE ID*/;
```
L’UTILISATEUR_ID doit être le vôtre. Il correspond à une valeur de la colonne UTILISATEUR.ID
[service_correction_bdd]: ./service_correction_bdd.png
\ No newline at end of file
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment