You are not logged in.
Alors en v4, la déconnexion fonctionne correctement et redirige vers une page de confirmation, dans laquelle vous êtes réellement déconnecté.
A partir du moment où vous repartez vers Ametys, vous prenez le risque d'être automatiquement reconnectés (cookie du formulaire ou SSO)
Je ne pense pas que le rôle d'Ametys soit de vous déconnecter aussi de votre SSO...
Ceci étant dit, il s'agirait du coup de réaliser une redirection navigateur cas/logout ; par exemple en surchargeant la page de déconnexion ?
Bonjour,
est-ce que vous parlez bien de la v4 d'Ametys ?
Bonjour,
en effet, les mails utilisent l'adresse renseignée dans la configuration du back-office dans la catégorie CMS
en effet, la vue visible dans F12 transforme le DOM ; il convient d'afficher le source pour voir ce qu'il en est vraiment.
Merci Laurence.
Bonjour
votre problème est en effet étrange.
Ce genre de problème peut être dû à des namespaces ou à un problème de chemin relatif.
De mémoire, il n'y a pas de namespace utilisé ici, donc regardons du côté des chemins.
Je vous invite à commencer par tester successivement un copy-of de "content" puis de "content/orgunit"
Bonjour et merci pour ce retour.
Pour l'instant, le champs que l'on demande dans l'administration est de nommer l'authentification et c'est un libellé que l'on voit notamment dans les écrans d'administration.
Dans l'idéal, il faudrait ajouter un deuxième champ "Libellé du bouton de connexion"... pour l'instant on ne l'avait pas fait pour éviter de demander trop de choses... mais on va finir par y arriver car c'est un problème récurrent surtout pour CAS.
Dans votre XSL, tout se passe dans cette instruction
<xsl:import href="plugin:web://pages/frontoffice-login/login.xsl"/>
Cette XSL en question, commence par importer
<xsl:import href="plugin:core-ui://pages/login/login_form.xsl"/>
qui est celle dont vous parlez plus haut.
Donc, c'est bien la bonne : par contre, ce n'est pas elle qui s'occupe de générer la balise <html> ou la balise <body>.
Il en est de même dans les templates.
Donc vous ne pouvez pas mettre
class='front-login-bg'
sur la balise <body>
mais par contre tout ce qui est à l'intérieur de cette balise est recopié tel quel, donc
<body id="default">
<div class="front-login-bg">
<xsl:call-template name="body"/>
</div>
</body>
Hi srini_r,
could you post a new thread in the english section of the forum
thank you
Bonjour
La XSL que vous cherchez est dans skins/XXXX/services/web/pages/frontoffice-login/login.xsl
Attention, cependant, cette XSL effectue des traitements génériques et vous risquez de casser pas mal de chose dans le formulaire de connexion en touchant à cela
Je vois que la clef que vous spécifiez est utilisée à 3 endroits différent dans ce fichier, mais dans tous les cas, je vous conseille de faire un test du type
<xsl:if test="additionalLabel = 'CAS'">...</xsl:if>
En v3, vous trouverez la description du ribbon dans les fichiers cms/WEB-INF/param/cms-ribbon*.xml
Il se trouve que le bouton à retirer est généralement directement dans ce fichier, dans c'est facile : mettez en commentaire la ligne qui référence l'identifiant "org.ametys.cms.edition.character.AlignJustify".
Normalement, pas besoin de redémarrer.
Bonjour,
la réponse dépend de votre version d'Ametys.
C'est assez simple en v4 par exemple...
Quelle version utilisez-vous ?
Bonjour
il arrive souvent des confusions entre application front et sites.
Notamment dans la configuration.
Côte back office, dans la configuration générale, on demande à un moment l'url des applications fronts : à cet endroit, pour vous, saisir "http://localhost:8080"
Coté front office, le paramètre équivalent doit être valué à "http://localhost:8080/cms
Ensuite, de nouveau côté back-office, dans la configuration site par site, vous inscrivez là l'url finale pour votre visiteur : par exemple
Ensuite, au niveau tomcat, il ne faut pas régler le SSL, mais seulement indiquer au niveau du <connector> que la connexion est sécurisée (secure=true ou qqchose comme ça) et que le proxyPort est 443.
(pour conserver votre configuration "simple" je pars du principe que le backoffice sera aussi accédé en https)
Et ensuite, c'est au niveau d'apache que vous configurez la redirection http->https ; et que vous gérez le certificat SSL
Je vous laisse appliquer ça et me dire si cela résous votre problème
Bonjour,
Dans ce ticket il est indiqué qu'il est le doublon du ticket en fait.
Et ce ticket est marqué corrigé pour la version 2.2.0 qui n'est pas encore livrée.
Vous pouvez soit tester sur une version "snapshot" [1], mais à vos risques et périls ; soit attendre que la 2.2.0 finale sorte.
[1]
Alors, Cédric vous a enduit d'erreur : en effet, si les pages finales de l'annuaire utilisent le gabarit "user-page", les pages intermédiaires utilisent, elles, le gabarit "page".
Donc votre hiérarchie est : Racine (page) > A (page) > B (page) > ABert (user-page)
Ce qui explique le résultat que vous avez pour l'héritage de zones.
Je vous invite à ouvrir une demande d'amélioration (sur le jira en anglais), pour que les nœuds intermédiaires utilisent un troisième gabarit (s'il existe)
Alors, je viens de relancer un annuaire et l'héritage fonctionne de manière classique.
J'ai testé avec la skin demo fournie dans le template ; sur la zone-1.
Il n'y a donc pas de problème induit par le mélange page réelle/page virtuelle ; et cela signifie que le problème se situe dans votre déclaration d'héritage probablement.
Dans la démo, les templates page et user-page sont décrits ainsi :
<zones>
<zone id="default" type="primary">
<label i18n="true">SKIN_BO_ZONING_USERPAGE_MAIN_LABEL</label>
<description i18n="true">SKIN_BO_ZONING_USERPAGE_MAIN_DESCRIPTION</description>
</zone>
<zone id="zone-1" inherit="blog->about,index->,*->zone-1" type="secondary">
<label i18n="true">SKIN_BO_ZONING_USERPAGE_Z1_LABEL</label>
<description i18n="true">SKIN_BO_ZONING_USERPAGE_Z1_DESCRIPTION</description>
</zone>
<zone id="zone-2" inherit="blog->aside,index->,*->zone-2" type="secondary">
<label i18n="true">SKIN_BO_ZONING_USERPAGE_Z2_LABEL</label>
<description i18n="true">SKIN_BO_ZONING_USERPAGE_Z2_DESCRIPTION</description>
</zone>
<zone id="invisible-zone-sidebar1" inherit="index->,*->invisible-zone-sidebar1" type="secondary">
<label i18n="true">SKIN_BO_ZONING_USERPAGE_INVISIBLEZ1_LABEL</label>
<description i18n="true">SKIN_BO_ZONING_USERPAGE_INVISIBLEZ1_DESCRIPTION</description>
</zone>
</zones>
d'après la doc, si votre zone dans la page parente s'appelle bien "left", l'héritage est automatique par défaut
Cependant vous être dans un cas spécial, puisque vous avez une page réelle (racine de l'annuaire) et des sous-pages virutelles... peut être la règle de l'héritage est différente dans ce cas.
Oui d'accord, pardon.
Dans ce cas, c'est que la remontée de contenus, se limite à des contenus "traditionnels", ce qui n'est pas le cas des contenus synchronisés...
En attendant une refonte en profondeur de la remontée de contenus prévue l'année prochaine, il semble donc qu'une évolution soit nécessaire sur ce service.
Est-ce que vous pouvez faire le test en ne mettant aucune étiquette, lorsque vous utilisez la valeur TOUS ?
si avec cela, tous les contenus agent remontent, il faudra simplement construire une étiquette inter-site
Dans votre contexte de recherche vous avez choisi "Site de recherche : Actuel" et cela n'inclut pas les contenus hors-site...
Vous pouvez tenter avec la valeur "Tous", mais je n'ai pas d'instance sous la main pour tester...
Bonjour,
Les contenus de l'annuaire sont "inter-site".
Il faudrait en effet nous partager le paramétrage du service.
Pour pouvoir insérer, une image, il ne faut pas utiliser "Réponse rapide" en bas de page, mais cliquer sur "Répondre au post"
Bonjour,
Peut être que simplement cette page n'est plus publiée ?
Est-ce qu'elle existe toujours dans le CMS ?
Bonjour,
ces divs sont, en effet, insérés par page.xsl et théoriquement vous pouvez surcharger le traitement du tag "<zone>" dans votre template.xsl.
Par contre, je pense que le backoffice ne va plus fonctionner s'il ne trouve pas son div englobant de zone ou de zone-item.
donc la réponse est plutôt négative
Si le groupe est déjà présent dans le LDAP, le plus simple est de l'utiliser tel quel ; sinon il est plus rapide pour un contributeur de constituer son groupe dans Ametys.
Il est tout à fait possible de combiner les deux : avoir des groupes Ametys et des groupes LDAP.
Pour être complet, les groupes Ametys permettent d'avoir des utilisateurs de différentes sources, alors que les groupes du LDAP se limitent aux utilisateurs du LDAP
Par curiosité, vous auriez souhaité quoi comme libellé ?
On parle de V4.
Dans l'admin, au moment où vous créez la population, vous pouvez donner un libellé au mode de connexion "Se connecter par C.A.S." est là valeur par défaut