Date: Thu, 28 Mar 2024 14:30:36 +0100 (CET) Message-ID: <297068823.72.1711632636002@confluence-esup.uphf.fr> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_71_1787684033.1711632636002" ------=_Part_71_1787684033.1711632636002 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Cette page a pour objet de pr=C3=A9senter toutes les informations utiles= au param=C3=A9trage et =C3=A0 l'adaptation de SOF =C3=A0 votre environneme= nt.
Elle sera mise =C3=A0 jour r=C3=A9guli=C3=A8rement en fonction des quest=
ions et des r=C3=A9ponses pos=C3=A9es sur la liste odf-utilisateurs.
Attention
La lecture de ce document doit se faire en lien avec les diff=C3=A9rents= MPD qui sont fournis au format PDF et qui sont disponibles dans le r=C3=A9= pertoire docs/database/mpd
SOF permet de r=C3=A9cup=C3=A9rer des donn=C3=A9es d'une base de donn=C3= =A9es de scolarit=C3=A9 (typiquement Apog=C3=A9e).
Un ensemble de requ=C3=AAtes sont livr=C3=A9es de base avec SOF pour fai= re ce lien mais il est possible pour chaque site de les adapter =C3=A0 ses = besoins.
Il est aussi possible de ne pas connecter SOF =C3=A0 une base de donn=C3= =A9es de scolarit=C3=A9.
La connexion =C3=A0 la base de scolarit=C3=A9 externe est d=C3=A9finie d= ans le fichier sql-scol.properties.
Les requ=C3=AAtes permettant d'importer des donn=C3=A9es ou des listes d= e valeurs depuis cette base dans SOF sont d=C3=A9finies dans le fichier sql= -import-scol.xml.
Il faut, avant de lancer SOF pour la premi=C3=A8re fois, modifier le fic= hier csof.xml afin de lui indiquer de ne pas chercher =C3=A0 r=C3=A9cup=C3= =A9rer l'=C3=A9tablissement par d=C3=A9faut dans la base de scolarit=C3=A9 = : <scol initEnabled=3D"N"/>Ensuite, il faudra supprimer l'acc=C3=A8s = aux menus "importer" et "synchroniser" (voir paragraphe consacr=C3=A9 au pa= ram=C3=A9trage des menus).
Un ensemble de requ=C3=AAtes sont livr=C3=A9es avec SOF et permettent de= retrouver des donn=C3=A9es dans Apog=C3=A9e.
Elles se trouvent dans le fichier sql-import-scol.xml :
Vous avez la possibilit=C3=A9 de remplacer les requ=C3=AAtes d'importati= on d'objets livr=C3=A9es dans SOF par les votres (connexion =C3=A0 une autr= e base qu'Apog=C3=A9e ou recherche d'autres valeurs par exemple).
Vous devez ajouter ces requ=C3=AAtes dans le fichier sql-specif-scol.xml= en prenant garde aux points suivants :
Ainsi si vous avez ajout=C3=A9 une requ=C3=AAte nomm=C3=A9e getEtbNancy2= dans sql-specif-scol.xml pour l'importation des =C3=A9tablissements, vous = devez ajouter dans csof.xml :
<opt= ions> <query name=3D"getEtablissement" value=3D"getEtbNancy2"/> </options>
Il est possible, lors de la premi=C3=A8re initialisation de SOF, d'initi= aliser des listes de valeurs de SOF avec le r=C3=A9sultat de requ=C3=AAtes = sur une base externe (Apog=C3=A9e).
L'initialisation ne concernera que la langue fran=C3=A7aise.
Un certain nombre de requ=C3=AAtes permettant d'initialiser des listes = =C3=A0 l'aide d'Apog=C3=A9e sont livr=C3=A9es de base (voir plus haut) mais= si voulez importer de nouvelles listes ou ne pas utiliser Apog=C3=A9e, voi= ci la marche =C3=A0 suivre :
Les informations =C3=A0 utiliser pour chaque type d'objet sont pr=C3=A9s= entes dans la table FUN_INFO_TYP
Selon la valeur de la colonne TYP_SYNC_INF, l'information sera :
Note
Dans le cas de la synchronisation de donn=C3=A9es d'un objet d=C3=A9j=C3=
=A0 existant, ne seront synchronis=C3=A9es que les informations pour lesque=
lles FUN_INFO.TEM_MOD_INF =3D 'I'
Pour modifier le comportement par d=C3=A9faut du m=C3=A9canisme de synch= ronisation, il convient donc de d=C3=A9finir sa propre classe =C3=A9tendant= l'interface ISync et d'adapter en cons=C3=A9quence les lignes suivantes da= ns le fichier de configuration du canal :
<cla= ssfactory name=3D"syncPers" class=3D"fr.unire.portal.channels.fun.csof.sync= .SyncDefLDAP"/> <classfactory name=3D"syncAll" class=3D"fr.unire.portal.channels.fun.cso= f.sync.SyncDefImpl"/>
Cette section pr=C3=A9sente la structure fondamentale du r=C3=A9f=C3=A9r= entiel en pr=C3=A9cisant les tables impact=C3=A9es et ce que vous pouvez ad= apter.
Chaque ann=C3=A9e poss=C3=A8de les attributs suivants :
Deux ann=C3=A9es sp=C3=A9cifiques ont =C3=A9t=C3=A9 cr=C3=A9=C3=A9es pou= r repr=C3=A9senter les valeurs minimales et maximales, appel=C3=A9es "Premi= =C3=A8re ann=C3=A9e" et "Derni=C3=A8re ann=C3=A9e". Ces ann=C3=A9es ne doiv= ent pas =C3=AAtre supprim=C3=A9es.
Si vous importez des objets faisant r=C3=A9f=C3=A9rence =C3=A0 des ann= =C3=A9es qui n'existent pas dans SOF, celles-ci seront automatiquement cr= =C3=A9=C3=A9es.
Les informations d'un objet peuvent =C3=AAtre d=C3=A9finies en plusieurs= langues(voir la table FUN_OBJ_LANG).
La liste des langues possibles est d=C3=A9finit dans la table FUN_LANGUE= , leurs libell=C3=A9s =C3=A9tant sp=C3=A9cifi=C3=A9s dans la table FUN_LIB_= DET_LOV via la table FUN_DET_LOV. Il est ainsi possible de sp=C3=A9cifier l= eurs libell=C3=A9s en plusieurs langues.
De mani=C3=A8re g=C3=A9n=C3=A9rale, toutes les listes de valeurs de l'ap= plication peuvent potentiellement =C3=AAtre traduites dans les langues sp= =C3=A9cifi=C3=A9es.
La langue par d=C3=A9faut est sp=C3=A9cifi=C3=A9e dans la table FUN_PARA= M (LANG_DEF).
Les groupes d'objets correspondent aux diff=C3=A9rents types d'objets qu= e l'on retrouve dans CDM :
A ces 4 groupes a =C3=A9t=C3=A9 ajout=C3=A9 le groupe header (ou titres,=
n=C2=B04) qui n'existe pas dans CDM mais nous servira =C3=A0 mod=C3=A9lise=
r des titres pour certaines listes (listes de parcours, listes d'=C3=A9l=C3=
=A9ments...).
Ces groupes sont des invariants dans SOF. Il n'est donc pas possible d'en =
ajouter.
Les types d'objets sont des instances des groupes d'objets. Par exemple,= le type d'objet Dipl=C3=B4me appartiendra au groupe program, comme le type= d'objet parcours ou sp=C3=A9cialit=C3=A9
On retrouvera les types d'objets dans la table FUN_TYP_OBJ.
Il est possible d'ajouter ses propres types (voir exemple plus bas).
Les groupes d'informations permettent de regrouper logiquement des infor= mations li=C3=A9es =C3=A0 un groupe d'objet.
Pour un type d'objet, une information ne pourra appartenir qu'=C3=A0 un = et un seul groupe d'information.
La r=C3=A9partition des informations entre les groupes est fondamentale = car on donnera ensuite des droits de modification aux utilisateurs globalem= ent sur un groupe.
Il faudra donc regrouper entre elles les informations pour lesquelles on= souhaite donner des droits identiques.
Les groupes d'informations se trouvent dans la FUN_GRP_INFO.
Il est possible de ne pas afficher/saisir une groupe d'information pour = un type d'objet pr=C3=A9cis en jouant sur la table FUN_GRP_INFO_TYP.
Pour qu'un utilisateur ait les droits de modifications sur un groupe, il= faut qu'il y ait une occurence dans la table FUN_DRT_PROF_UTI avec son cod= e profil, le code du groupe et le num=C3=A9ro du groupe de l'objet.
Exemple : Autorisation des utilisateurs de profil "Scolarit=C3=A9" =C3= =A0 modifier le groupe "Informations g=C3=A9n=C3=A9rales" des objets de typ= e "Dipl=C3=B4me"
insert = into FUN_DRT_PROF_UTI values('SCOL','GEN',2,'');
Les informations sont li=C3=A9es =C3=A0 un groupe d'information unique. = Elles permettent de d=C3=A9finir les r=C3=A8gles de saisie d'un =C3=A9l=C3= =A9ment CDM.
Une information est d=C3=A9finie :
Les informations sont contenues dans la table FUN_INFO.
Les liste de valeurs permettent de restreindre les valeurs prises par ce= rtaines informations =C3=A0 une liste fixe.
Pour cela, les informations doivent avoir un FUN_INFO.TYP_INF=3DLOV et f= aire r=C3=A9f=C3=A9rence =C3=A0 une liste de valeur dans FUN_INFO.COD_LOV.<= /p>
Les listes de valeurs peuvent =C3=AAtre multilingues.
Voici les tables contenant les donn=C3=A9es des listes de valeurs :
Dans cet exemple nous allons voir les diff=C3=A9rentes =C3=A9tapes pour = ajouter le type d'objet Ann=C3=A9e qui appartiendra au groupe Titres(n=C2= =B04) et qui sera li=C3=A9 =C3=A0 une version d'=C3=A9tape dans Apog=C3=A9e= .
select = distinct GI.COD_GI, GI.NUM_GRP_OBJ, IT.NUM_TYP_OBJ from FUN_GRP_INFO GI, FUN_INFO_TYP IT, FUN_INFO I where GI.TES_GI =3D 'O' and I.NUM_GRP_OBJ =3D GI.NUM_GRP_OBJ and I.COD_GI =3D GI.COD_GI and IT.COD_INF =3D I.COD_INF and IT.NUM_GRP_OBJ =3D I.NUM_GRP_OBJ order by IT.NUM_TYP_OBJ, GI.NUM_GRP_OBJ;
Par exemple :
<cla= ssfactories> ... <classfactory name=3D"syncAll" class=3D"fr.unire.portal.channels.fun.cso= f.sync.SyncDefImplPerso"/> ... </classfactories>
Il existe deux types de profils qui peuvent intervenir quand on travaill= e avec le canal SOF :
Il existe une exception =C3=A0 cette r=C3=A8gle :
Si une personne poss=C3=A8de un profil statique ADMIN, le profil dynamiq= ue n'intervient jamais. On dit que le profil statique ADMIN est bloquant (c= e comportement peut se r=C3=A9gler au niveau de la table FUN_PROF_UTI de la= base de donn=C3=A9es de SOF).
Quand une personne n'a pas de profil dynamique pour l'objet courant et q= u'elle n'a pas de profil statique, le profil statique ANONYME lui est attri= bu=C3=A9 par d=C3=A9faut.
Il y a actuellement 3 types de profils dynamiques :
Selon l'objet courant, la personne peut avoir l'un de ces trois profils =
(ou un profil statique si elle ne poss=C3=A8de aucun droit correspondant =
=C3=A0 ces profils dynamiques). Pour un objet donn=C3=A9, on ne peut avoir =
qu'un seul profil dynamique (on ne peut =C3=AAtre en m=C3=AAme temps RESPDI=
P et RESP d'un objet de l'offre de formation).
Ces profils sont donc qualifi=C3=A9s de dynamiques : ils d=C3=A9pendent de=
l'endroit o=C3=B9 se situe la personne dans l'offre de formation (une pers=
onne peut ainsi avoir un profil RESP pour un semestre, RESPSUP pour une UE =
de ce semestre, aucun profil temporaire pour les =C3=A9lements de formation=
d'une composante =C3=A0 laquelle elle n'est point rattach=C3=A9e, etc.).=
p>
Par d=C3=A9faut, l'ordre d'=C3=A9valuation des profils dynamiques est le= suivant : RESP, RESPDIP, RESPSUP. Cet ordre peut =C3=AAtre modifi=C3=A9 po= ur mettre en oeuvre une autre politique de gestion de droits sur les =C3=A9= l=C3=A9ments de l'offre de formation. Il faut alors cr=C3=A9er une classe i= mpl=C3=A9mentant l'interface Iprofil (particuli=C3=A8rement la m=C3=A9thode= calcDynamicProfil) et r=C3=A9f=C3=A9rencer ensuite cette classe dans le fi= chier csof.xml : <classfactory name=3D"profil" class=3D"NomDeLaNouvelleC= lasse"/>Le profil dynamique RESP est attribu=C3=A9 =C3=A0 une personne q= uand elle travaille sur un objet (dipl=C3=B4me, semestre, UE, etc.) dont el= le est responsable (sous-entendu : responsable direct).
Le profil dynamique RESPSUP est attribu=C3=A9 =C3=A0 une personne quand = elle travaille sur un objet qui est un descendant d'un objet dont elle est = responsable. Typiquement, si une personne est responsable (RESP) d'un semes= tre, lorsqu'elle travaillera sur une UE de ce semestre, elle sera RESPSUP (= sauf si, par exemple, elle a aussi =C3=A9t=C3=A9 d=C3=A9sign=C3=A9e comme r= esponsable de cette UE ; cas o=C3=B9 elle sera alors RESP pour cette UE - c= f. l'ordre d'=C3=A9valuation des profils dynamiques dont nous avons parl=C3= =A9 pr=C3=A9c=C3=A9demment).
Le profil dynamique RESPDIP est affect=C3=A9 =C3=A0 une personne respons= able (RESP) d'un dipl=C3=B4me quand elle travaille sur un objet qui est un = descendant de ce dipl=C3=B4me. L=C3=A0-aussi, l'ordre d'=C3=A9valuation des= profils dynamiques peut faire que la personne ait un profil RESP pour un s= emestre appartenant au dipl=C3=B4me dont il est question.
La responsabilit=C3=A9 d'un objet (RESP) peut =C3=AAtre attribu=C3=A9e = =C3=A0 une personne par une personne poss=C3=A9dant un profil statique "for= t" (comme ADMIN), ou par un RESPSUP de l'objet (ceci d=C3=A9pendant alors d= es pouvoirs effectifs du profil dynamique RESPSUP).
Les diff=C3=A9rents droits des profils dynamiques RESP, RESPSUP et RESPD= IP sont fix=C3=A9s par les entr=C3=A9es des tables FUN_DRT_PROF_UTI et FUN_= MEN_PROF_UTI.
Les 3 profils dynamiques que nous venons de d=C3=A9crire sont stock=C3= =A9s dans la table FUN_PROF_UTI.
Il existe actuellement dans SOF 3 profils statiques :
Un profil statique est attribu=C3=A9 au login d'une personne (hormis le =
cas particulier du profil statique ANONYME).
Les associations entre login et profil statique sont stock=C3=A9es dans la=
table FUN_PROF_UTI_PERS de la base de donn=C3=A9es de SOF.
Exemples d'associations possibles
Login |
Profil statique |
ingenp01 |
ADMIN |
secrep01 |
SCOL |
secrep02 |
SCOL |
Pour l'objet courant, le profil statique n'entre en compte que s'il n'y = a pas de profil dynamique. Toutefois, certains profils statiques ont la pro= pri=C3=A9t=C3=A9 d'=C3=AAtre bloquants : ils emp=C3=AAchent l'=C3=A9valuati= on du profil dynamique et sont ainsi attribu=C3=A9s =C3=A0 la personne. C'e= st le comportement par d=C3=A9faut du profils statique ADMIN. Ce n'est pas = le cas de SCOL et ANONYME.
L'aspect bloquant ou non d'un profil statique peut =C3=AAtre modifi=C3= =A9 en mettant =C3=A0 jour le champ TEM_CAL_PRO_UTI de la table FUN_PROF_UT= I pour l'enregistrement correspondant au profil statique auquel on s'int=C3= =A9resse.
Le profil statique ANONYME entre en jeu quand une personne examine un ob= jet de l'offre de formation pour lequel elle n'a aucun profil dynamique (el= le n'a aucune responsabilit=C3=A9 vis =C3=A0 vis de cet objet) et quand le = login de cette personne n'est pas li=C3=A9 =C3=A0 un profil statique. Dans = cette situation, la personne se voit attribuer le profil statique ANONYME q= ui dispose de droits tr=C3=A8s faibles.
Ainsi, un membre du personnel de l'Universit=C3=A9 sans rapport avec la = formation n'aura pas de profil dynamique (un administrateur ou un responsab= le d'un objet de la formation ne lui aura pas donn=C3=A9 de profil dynamiqu= e en le rendant responsable d'un semestre ou d'une UE). C'est donc son prof= il statique qui entrera en compte. Comme ce membre du personnel n'aura pas = d'entr=C3=A9e dans la table FUN_PROF_UTI_PERS, il se retrouvera, pour chaqu= e =C3=A9l=C3=A9ment de l'offre de formation, avec comme droits ceux du prof= il statique par d=C3=A9faut : ANONYME.
Les profils statiques ADMIN et SCOL disposent des droits maximaux. Ils p= euvent modifier la hi=C3=A9rarchie de l'offre de formation (d=C3=A9truire u= n objet et tous ses enfants, en cr=C3=A9er d'autres, modifier les donn=C3= =A9es descriptives d'un objet, etc.).
A l'inverse, le profil statique ANONYME ne permet que de consulter l'off= re de formation.
Les diff=C3=A9rents droits des profils statiques ADMIN, SCOL et ANONYME = sont fix=C3=A9s par les entr=C3=A9es des tables FUN_DRT_PROF_UTI et FUN_MEN= _PROF_UTI.
Les 3 profils statiques que nous venons de pr=C3=A9senter sont stock=C3= =A9s dans la table FUN_PROF_UTI.
Les menus sont d=C3=A9finit dans la table FUN_MENU.
Chaque menu est compos=C3=A9 d'un ensemble d'entr=C3=A9es, stock=C3=A9es= dans la table FUN_DET_MENU.
Prenons l'exemple du menu d'un objet.
<=
/p>
Note
Cette section se r=C3=A9f=C3=A8re au menu par d=C3=A9faut propos=C3=A9 d= ans le fichier referentiel.sql
insert = into FUN_MENU values('OBJ','Objet');Il est compos=C3=A9 des entr=C3=A9es su= ivantes :
Note
Le canal v=C3=A9rifie =C3=A0 chaque appel d'une action que le profil de l'=
utilisateur lui permet de l'ex=C3=A9cuter. A partir du moment o=C3=B9 l'uti=
lisateur a les droits sur une entr=C3=A9e d'un menu, il est autoris=C3=A9 =
=C3=A0 ex=C3=A9cuter l'ensemble des actions associ=C3=A9es.
Le canal fournit un m=C3=A9canisme de worflow pour la validation/publica= tion d'un objet. Ce m=C3=A9canisme permet aux sites d'enrichir les phases d= e validation/publication de traitements qui leurs sont sp=C3=A9cifiques.
L'impl=C3=A9mentation de ce m=C3=A9canisme est effectu=C3=A9e dans le pa= ckage workflow. Ce package contient :
<cla= ssfactory name=3D"workflowValidation" class=3D"fr.unire.portal.channels.fun= .csof.workflow.WorkflowValidationDefImpl"/>
Deux points de sortie sont pr=C3=A9vus :
La m=C3=A9thode publicationObjet de l'interface IWorkflowValidation perm= et de publier un document CDM connaissant
WorkflowValidationDefImpl est l'impl=C3=A9mentation SOF type de IWorlflo= wValidation. Elle effectue les op=C3=A9rations suivantes :
Il a aussi =C3=A9t=C3=A9 pr=C3=A9vu de pouvoir retirer le CDM d'un objet= du serveur d'affichage de l'offre de formation
Ceci est r=C3=A9alis=C3=A9 par la m=C3=A9thode suppressionObjet de l'int= erface IWorkflowValidation
L'impl=C3=A9mentation type WorkflowValidationDefImpl effectue les op=C3= =A9rations suivantes en cas de suppression :
Cette section d=C3=A9crit le principe par d=C3=A9faut de publication des= objets SOF au format CDM et comment l'adapter =C3=A0 vos besoins
Les profils qui sont autoris=C3=A9s ont acc=C3=A8s =C3=A0 un menu Public=
ation disponible uniquement sur les dipl=C3=B4mes de publication.
D=C3=A9finition
On appelle dipl=C3=B4me de publication un dipl=C3=B4me(objet du groupe P= rogram) situ=C3=A9 directement sous un objet de type orgUnit
C'est la m=C3=A9thode generate de la classe CDM qui est charg=C3=A9e de = cette t=C3=A2che.
Chaque groupe d'objet peut disposer d'une classe sp=C3=A9cifique =C3=A0 = la g=C3=A9n=C3=A9ration de sa structure au format CDM. Cette classe doit im= pl=C3=A9menter l'interface IObjCdm.
Par structure on entend la mani=C3=A8re dont sont imbriqu=C3=A9s les =C3= =A9l=C3=A9ments CDM entre eux (par exemple pour g=C3=A9n=C3=A9rer la struct= ure d'un dipl=C3=B4me ou d'un cours).
Par d=C3=A9faut dans SOF, la classe ObjCdmDefImpl g=C3=A9n=C3=A9re le CD= M de tout type d'objet. Ceci est pr=C3=A9cis=C3=A9 ainsi dans le fichier cs= of.xml : <classfactory name=3D"cdmAll" class=3D"fr.unire.portal.channels= .fun.csof.cdm.ObjCdmDefImpl"/>Si vous voulez par exemple mettre en oeuvr= e une classe diff=C3=A9rente pour g=C3=A9n=C3=A9rer le CDM d'une personne, = cr=C3=A9ez votre propre classe et faites y r=C3=A9f=C3=A9rence dans csof.xm= l ainsi : <classfactory name=3D"cdmPers" class=3D"fr.unire.portal.channe= ls.fun.csof.cdm.PersCdmDefImpl"/>
Il est possible aussi dans SOF de param=C3=A9trer o=C3=B9 sont cherch=C3= =A9es les donn=C3=A9es pour chaque type d'objet CDM
Les interfaces definissant les donn=C3=A9es =C3=A0 g=C3=A9n=C3=A9rer en = CDM sont d=C3=A9finies dans :
Il est cependant possible de red=C3=A9finir vos propres classes et d'y f= aire r=C3=A9f=C3=A9rence dans le fichier csof.xml ainsi :
<cla= ssfactory name=3D"cdmGenOrgUnit" class=3D"fr.unire.portal.channels.fun.csof= .cdm.CdmOrgUnitPerso"/> <classfactory name=3D"cdmGenProgram" class=3D"fr.unire.portal.channels.f= un.csof.cdm.CdmProgramPerso"/> <classfactory name=3D"cdmGenCourse" class=3D"fr.unire.portal.channels.fu= n.csof.cdm.CdmCoursePerso"/> <classfactory name=3D"cdmGenPerson" class=3D"fr.unire.portal.channels.fu= n.csof.cdm.CdmPersonPerso"/>
Cette op=C3=A9ration est faite via la classe JAXPValidator et par rappor= t au sch=C3=A9ma CDMv2.01.xsd (indiqu=C3=A9 dans la classe ApplicationConte= xt)
La liste des web-services de publication est disponible dans la table FU= N_WS_PUB.
Cette table est livr=C3=A9e vide, il vous faut l'alimenter pour pouvoir = publier vos fichiers.
Par d=C3=A9faut un objet de publication est publi=C3=A9 sur tous les web= -services disponibles dans cette table.
Par contre d=C3=A8s lors qu'un web-service est pr=C3=A9sent dans la tabl= e FUN_WSP_NOT_OBJ pour un objet alors il n'est pas utilis=C3=A9 pour la pub= lication.
Asynchronous JavaScript And XML(AJAX) est une m=C3=A9thode de d=C3=A9vel= oppement de sites web utilis=C3=A9e dans SOF afin de modifier seulement un = partie de l'affichage du canal plut=C3=B4t que de rafraichir tout l'ENT (ce= qui peut =C3=AAtre plus lent).
AJAX utilise intensivement javascript, ce qui peut poser des probl=C3=A8= mes de compatibilit=C3=A9 avec certains navigateurs (par exemple SOF n'a pa= s =C3=A9t=C3=A9 test=C3=A9 avec Safari pour Mac)
Si vous rencontrez des soucis d'affichage dus =C3=A0 l'utilisation d'Aja=
x vous avez la possibilit=C3=A9 de d=C3=A9sactiver ce type d'affichage en m=
odifiant le param=C3=A8tre suivant dans le fichier csof.xml : <ajax enab=
led=3D"O"/>
Il faudra alors passer l'attribut enabled =C3=A0 N.
Il est possible d'adapter un certain nombre d'=C3=A9l=C3=A9ments du look= en modifiant le fichier webpages/stylesheets/fr/unire/portal/channels/fun/= csof/actions/templates/constantes.xsl
Il est possible de sp=C3=A9cifier pour chaque ic=C3=B4ne l'image utilis= =C3=A9e. Le chemin indiqu=C3=A9 est relatif au mediaPath du canal.
Exemple :
<xsl= :param name=3D"IMG_ACCUEIL">home.gif</xsl:param>
Les fonds des zones sp=C3=A9cifiques (comme le cartouche d'ent=C3=AAte d= 'un objet) peuvent =C3=AAtre adapt=C3=A9s.
Exemple :
<xsl= :param name=3D"FOND_OBJ">uportal-input-text</xsl:param>
Il est en de m=C3=AAme pour les couleurs utilis=C3=A9es pour mettre en = =C3=A9vidence les champs ayant le focus ou =C3=A9tant disabled (disponible = uniquement sous FireFox 1.5)
Exemple :
<xsl= :param name=3D"FOND_FOCUS_INPUT">#FFFFCC</xsl:param> <xsl:param name=3D"TEXT_FOCUS_INPUT">#000000</xsl:param>
Pour obtenir des libell=C3=A9s de taille plus importante (notamment pour= voir int=C3=A9gralement le nom de votre universit=C3=A9) dans le r=C3=A9ca= pitulatif de l'arborescence, modifiez la valeur du param=C3=A8tre LENGTH_LI= B_OBJ :<xsl:param name=3D"LENGTH_LIB_OBJ">20</xsl:param>
Les langues sont des listes de valeurs.
Cependant, la table FUN_LANGUE est n=C3=A9cessaire pour pouvoir d=C3=A9f= inir facilement les libell=C3=A9s des listes de valeurs en plusieurs langue= s.
select = DL.*, LDL.LIB_DET_LOV from FUN_DET_LOV DL, FUN_LIB_DET_LOV LDL where DL.COD_LOV=3D'TYP_OBJ' and LDL.NUM_DET_LOV =3D DL.NUM_DET_LOV
Voici les modifications =C3=A0 apporter au fichier Logger.properties afi=
n d'avoir des logs d=C3=A9taill=C3=A9s sur l'application SOF
#######= ################################################### log iBATIS ########################################################## log4j.category.com.ibatis=3D DEBUG, IBATIS log4j.logger.com.ibatis.common.jdbc.ScriptRunner=3DDEBUG, IBATIS log4j.logger.com.ibatis.common.jdbc.SimpleDataSource=3DDEBUG, IBATIS log4j.logger.java.sql.Connection=3DDEBUG, IBATIS log4j.logger.java.sql.Statement=3DDEBUG, IBATIS log4j.logger.java.sql.PreparedStatement=3DDEBUG, IBATIS log4j.additivity.com.ibatis =3D false log4j.appender.IBATIS =3D org.apache.log4j.RollingFileAppender log4j.appender.IBATIS.File =3D C:/esupdev/ibatis.log log4j.appender.IBATIS.Encoding=3DUTF-8 log4j.appender.IBATIS.MaxFileSize=3D3000KB log4j.appender.IBATIS.MaxBackupIndex=3D10 log4j.appender.IBATIS.layout=3Dorg.apache.log4j.PatternLayout log4j.appender.IBATIS.layout.ConversionPattern=3D%5p %t %c {2}.[%x] %d{MMM/dd HH:mm:ss} - %m%n ########################################################## # log CSOF ########################################################## log4j.category.fr.unire.portal.channels.fun.csof=3D DEBUG, CSOF log4j.additivity.fr.unire.portal.channels.fun.csof =3D false log4j.appender.CSOF =3D org.apache.log4j.RollingFileAppender log4j.appender.CSOF.File =3D C:/esupdev/cSof.log log4j.appender.CSOF.Encoding=3DUTF-8 log4j.appender.CSOF.MaxFileSize=3D3000KB log4j.appender.CSOF.MaxBackupIndex=3D10 log4j.appender.CSOF.layout=3Dorg.apache.log4j.PatternLayout log4j.appender.CSOF.layout.ConversionPattern=3D%5p [%t] %c{2}.%x %d {MMM/dd HH:mm:ss}- %m%n