You are not logged in.
Je pense que les deux problèmes sont liés (et c'est vraisemblablement le même contenu qui plantait lors du script de migration)
Il s'agit d'un problème de données liées au workflow d'un contenu, donc rien à voir avec la vue de remontée de contenus que vous pouvez avoir surchargée.
Vous avez un contenu qui pointe sur une entrée de workflow qui manifestement n'a pas d'état courant, ce qui normalement est impossible...
Vous pouvez peut-être essayer d'ouvrir le contenu en question si vous arrivez à l'identifier
Si ca ne concerne qu'un seul contenu et que vous savez duquel il s'agit, il est vraisemblablement moins coûteux de le supprimer et de le recréer que d'essayer de réparer les données.
bon en fait, après avoir regardé le code, ca n'a surement rien à voir avec les données du workflow
mais il faut aller voir dans le repository quand même
Le mieux est d'aller dans l'application repository via _admin
et de dérouler l'arbre pour retrouver le contenu à partir de sa page :
ametys:root -> ametys:sites -> <site> -> ametys-internal:sitemaps -> fr -> <votre page> -> ametys-internal:zones -> <nom de votre zone> -> ametys-internal:zoneItems -> <le zoneItem qui contient votre contenu>Ensuite vous cliquez à droite sur la propriété ametys-internal:content et vous allez être redirigés vers le contenu lui-même et sa liste de propriétés.
Les propriétés impliquées dans l'alerte que vous mentionnez sont ametys:proposalDate (qui doit correspondre à la date de dernière proposition) et ametys:awaitingValidationLastDate (qui correspond à la date du dernier mail de relance)
Vous pouvez regarder dans les cas qui ne fonctionnent pas si ces propriétés existent et le cas échéant si leur valeur est cohérente.
c'est peut-être un bug...
l'état du workflow est stocké à deux endroits : un dans le workflow lui-même qui sert à afficher l'état du contenu, et l'autre sur le contenu lui-même, qui sert pour optimiser les requêtes et qui sert notamment pour la requête qui envoie les alertes.
S'il y a désynchro entre les deux, ça pourrait expliquer le problème rencontré, mais sans avoir vos données, je ne peux pas vraiment savoir.
Le mieux serait d'aller voir directement dans le repository pour savoir
pour les deux derniers problèmes, il me faudrait un extrait de logs plus grand, il n'y a pas l'exception initiale
Il semble qu'un de vos contenus soit corrompu...
pour finir d'exécuter le script pour pouvez essayer de le protéger par des try/catch :
importClass(org.ametys.workspaces.repository.ConsoleHelper);
var query = session.getWorkspace().getQueryManager().createQuery("//element(*, ametys:content)[not(@ametys-internal:currentStepId)]", javax.jcr.query.Query.XPATH);
var nodes = query.execute().getNodes();
var count = 0;
while (nodes.hasNext())
{
try
{
node = nodes.next();
ConsoleHelper.setProperty(node, "ametys-internal:currentStepId", new java.lang.Long(1));
node.save();
count++;
}
catch (e)
{
println("exception occurred while setting stepId");
}
}
println(count + " nodes modified");Sinon, ce script n'est pas non plus obligatoire, le bug ne concernait que les contenus qui n'avaient jamais été édités.
Bonjour Patrick,
Ces fichiers en version "générique" sont dispo à l'adresse :
Cédric
Nous avons livré une version de maintenance de la branche 3.1.
L'application de démo est disponible à l'adresse … 1.x/3.1.2/
Les différents plugins sont disponibles à
Cette version est directement compatible avec la 3.1 sans modifications ni migration
Il s'agit de la dernière version de maintenance de la branche 3.1.x, sauf bugs bloquants ou failles de sécurité
Hi,
I don't know much about cpanel. Could you ask them ?
Does it have a Java VM ?
Cédric
The release of Ametys version 3.2.1 is available at .
In addition to new features, over 250 bugs have been fixed:
Back-office UI
* Login page with form
* Splash screen when the CMS is loading
* Handling of keyboard shortcuts: Esc and Enter keys in dialog boxes
* While editing, ability to save without exiting (Save / Save and close)
* Management of tabs:
o Tabs can be closed all at once or by categories...
o Tabs are sorted by categories (pages, tools, content, help ...)
o Possibility to display one tab a color, one tab a tool or every tabs.
* Sitemap new features:
o Buttons to fold the whole site and refresh a page and its subpages
o Search filter
o A system for identifying the status of pages and color icons: heading / subheading, online / draft, redirect page, translated page...
Resource Explorer Tools
o Buttons to fold and refresh a directory
o Filter the names of files / directories
* Re-ordering of alias
* Consolidation of services and content by category in the Add Content menu and Add Service
* Icons and decorators in the site map
* Collapsable right panels (site map, resource explorer, ...)
Performance:
* Minify and concatenate CSS and JS files
* Performance improvements of the Front Office (improving the cache, domain name aliases, HTTP headers)
* Performance improvements between the Front Office and the Back Office (fewer queries, cache management)
... and also:
* Compatibility FF4 and FF5
* Ability to override the content type to add fields
* Choice of sight for the service "Show content" (8 votes on this ticket
Je vous annonce la sortie de la nouvelle version 3.2.1 d'Ametys, disponible à l'adresse
Parmi les nouveautés, outre la correction de plus de 250 bugs :
Ergonomie coté back-office:
* Page de connexion avec formulaire
* Splash screen pendant le chargement de l'application
* Gestion des raccourcis clavier : touches ECHAP et Entrée sur les boites de dialogues
* En édition, possibilité d'enregistrer sans quitter (Enregistrer / Enregistrer et fermer)
* Les onglets (choix dans les préférences utilisateurs) :
o Possibilité de fermer tous les onglets ouverts ou de conserver uniquement celui sélectionné
o Regroupement des onglets par type (pages, outils, contenus)
o Choix d'avoir un onglet par couleur, un onglet par outils ou tous
* Outils plan du site :
o Boutons pour plier tout le site et rafraichir une page et ses sous-pages
o Filtre sur le nom des pages
o Icônes et décorateurs reflétant la nature de la page (rubrique, invisible, accès directs, ...) et son état (en ligne)
* Outils explorateur de ressources
o Boutons pour plier et rafraichir un répertoire
o Filtres sur le nom des fichiers/répertoires
* Ré-ordonnancement des alias
* Regroupement des services et contenus par catégorie dans les menu Ajouter un contenu et Ajouter un service
* Icônes et décorateurs dans le plan du site
o Doc intégrateurs :
o Doc utilisateurs :
* Panneaux de droite (plan du site, explorateur de ressources, ...) rétractables
Performances :
* Minification et concaténation des fichiers CSS et JS
* Améliorations des performances côté FO (amélioration du cache, alias de nom de domaine, entête HTTP)
* Améliorations des performances entre le FO et le BO (diminution du nombre de requêtes, gestion du cache)
... et aussi :
* Compatibilité FF4 et FF5
* Possibilité de surcharger les types de contenus pour ajouter des champs
* Choix de la vue pour le service "Afficher un contenu" (8 votes sur ce ticket
en tout cas, ce qui est sûr c'est que quand le message "Access denied XXX" apparaît côté site, c'est que le back lui a renvoyé une erreur HTTP 403
Plusieurs explications possibles :
- le mécanisme de pages à accès limité, mais ça ne semble pas être le cas ici
- l'adresse IP du site vue par le CMS n'est pas dans la liste des IP configurées. Auquel cas vous avez dans les logs du CMS (répertoire WEB-INF/logs) une erreur du genre : "IP XXX.XXX.XXX.XXX is not allowed as front-office IP."
- un problème de configuration réseau si les deux applis ne sont pas sur le même serveur d'appli...
La seconde explication est en générale le problème le plus fréquemment rencontré.
Bonjour,
Excellente remarque !
Alors je vais essayer d'être clair :
Il y a trois concepts mis en oeuvre :
- La liste des utilisateurs du back (chez vous c'est LDAP), qui se configure dans le runtime.xml du CMS pour le point d'extension UsersManager
- La liste des utilisateurs du front, qui se configure de la même façon dans le runtime.xml du site. Par défaut, cette liste est restreinte à un seul utilisateur, qui s'appelle anonymous (via l'extension org.ametys.runtime.plugins.core.user.Static), d'où l'erreur que vous rencontrez.
- La liste des utilisateurs du front vus par le back, qui se configure dans le CMS dans le runtime.xml via le point d'extension org.ametys.runtime.user.UsersManager.FO
Par défaut, ce point d'extension part du principe que la liste est le même dans le back que dans le front, ce qui est votre cas.
Dans votre cas, il faut donc utiliser dans le front le UsersManager LDAP et le configurer de la même manière que dans le back.
N'oubliez pas également de configurer le CredentialsProvider avec CAS.
En fait ce n'est pas une question de configuration
Ce qui se passe, c'est que le site demande la page au CMS, qui lui répond "403 Access denied"
C'est ce qui arrive en général quand vous avez limité l'accès à une page (via le bouton "limiter l'accès" dans le CMS) à un certain utilisateur et que vous vous connectez au site avec un utilisateur différent.
Tout dépend du paramétrage de l'application site, mais par défaut, pour simplifier, vous êtes connecté au site en tant qu' "anonymous", qui est le login qu'on retrouve dans la page "Access denied" que vous obtenez.
Cédric
je ne suis pas expert, mais je crois que Google peut se servir de la balise description si elle est remplit pour afficher les quelques lignes de texte sous les liens
Donc peut-être qu'en la rajoutant avec la même valeur que DC.description, ca pourrait marcher
Le comportement que vous souhaitez n'est pas développé pour l'instant.
Pour faire ce que vous souhaitez, il faut instancier un nouveau CredentialsProvider, en se basant sur ceux qui existent.
Non, en effet c'est bizarre, les droits ne sont utilisés que côté CMS, pas côté site.
Le comportemennt dépend étroitement de la configuration choisie, il faut vous rapprocher de l'administrateur de votre CMS pour ça.
Il faut aussi veiller à utiliser des sessions de navigateur différentes pour simuler des utilisateurs différents (des onglets différentes ne suffisent pas) : idéalement des navigateurs différents pour être sûr : un sous IE et l'autre avec FF.
Les contenus restent verrouillés quand on rentre en édition et qu'on en sort sans sauvegarder.
Après ça, ils restent verrouillés 2h (valeur par défaut qui peut ête modifiée par un administrateur).
Pendant ces 2h, un administrateur ou la personne qui tient le verrou sur le contenu peut tout à fait le déverrouiller manuellement.
C'est ce qu'il fallait faire ;-)
Tu es sûre que ton application utilise le bon repository (celui qui est configuré dans le config.xml et auquel tu as enlevé le custom_nodetypes.xml) ?
Par défaut c'est dans WEB-INF/data/repository, mais tu as pu le mettre ailleurs.
Tu as installé l'application par dessus l'autre ou dans un nouveau répertoire à part ?
Bonjour Sandrine,
Sans doute un problème de custom_nodetypes dans le repository
Au moment de l'upgrade, il faut supprimer le fichier repository/repository/nodetypes/custom_nodetypes.xml, il est recréé tout seul.
Ce n'est pas indiqué dans la doc de mise à jour ?
pour le fichier de config WEB-INF/config/config.xml oui autant repartir de celui qui existe, de toutes façons si l'application a besoin de nouveaux paramètres elles vous le dira.
Pour le répertoire data, dans un système en production, je conseille dans tous les cas de ne pas avoir les données dans la même arborescence que l'application, histoire d'isoler données et programme
Il semble que vous ayiez dézippé la nouvelle appli sur l'ancienne ?
Ce n'est pas la bonne procédure, il faut bien que ce soit dans un nouveau dossier, et ensuite recopier ce qu'il faut de l'ancienne version (fichier de config, skins, ...)
et quand vous appelez les URL à la main, ça donne quoi ?
Parce qu'il ne faut trop se fier au favicon affichée par le navigateur. D'expérience, les caches de favicon sont relativement indépendants des caches normaux et IE et Firefox notamment ne gèrent pas bien du tout un changement de favicon pour un même domaine.
le moteur de recherche est un service intégré à une page, il suffit donc d'appeler la page en question avec le paramètre qu'attend le service (de mémoire, je crois qu'il s'appelle "textfield")
Normalement il devrait y avoir deux méthodes pour ça :
Soit ajouter la meta qui va bien dans votre skin : <link rel="icon" type="image/x-icon" href="/favicon.ico" />
Soit écrire une règle Apache qui redirige "/kernel/resources/img/runtime_favico.ico" vers votre fichier.
Dans la pratique, pour l'instant, seule la seconde fonctionne, parce que le système rajoute toujours celle d'Ametys en premier, même quand elle est spécifiée dans la charte.