Bon, je viens de faire un clear cache sur ce endpoint et:
- Le message d’alerte 403 est disparu à la connexion mais il apparait et réapparait par la suite
- le clear cache était aussi lent que quand le le fais directement depuis l’interface simplicité
Pour mémoire votre pb de 403 est visiblement lié aux droits sur l’objet WebNews => assurez vous que votre user à bien, d’une manière ou d’une autre, les droits sur cet objet.
Pour la lenteur du clear cache je ne vois à priori pas d’explication autre que liée à votre infra. Avez vous testé sur une instance déployée sur le serveur cloud qu’on vous met à disposition ?
oui j’ai ajouté l’utilisateur designer
j’ai après redémarrer aussi l’environnement mais cette alerte est toujours là
Non pas encore
Il faut à nouveau regarder dans la console “Network” du navigateur quel(s) appel(s) finissent en 403, si ça se trouve c’est cette fois-ci un autre objet ou alors ce droit que vous avez ajouté ne correspond pas à ce qu’utilise le user connecté qui a ces popups 403…
Pour les perfs, on ne peut pas investiguer sur une infra à laquelle on a pas accès. Donc la seule chose à faire c’est d’essayer de reproduire le pb sur une instance qui tourne sur une infra à laquelle on a accès. Et s’il n’y a pas de pb ça confirmera que le pb est plutôt du coté de votre infra.
OK le 403 semble toujours se produire sur l’objet WebNews…
Le user connecte a-t-il accès à l’objet WebNews, Si oui il est accessible dans le domaine Web, est-ce le cas ?
Si c’est le cas pouvez vous essayer de créer une news (c’est pour vérifier que l’objet est bien fonctionnel) ?
Oui, c’est le cas
j’ai essayé de créer un News mais je n’arrive pas:
Voici les messages d’erreur/info qui s’affichent en essayant d’enregistrer un nouveau Objet New:
2021-01-25 18:37:40,079 INFO [com.simplicite.util.tools.SQLTool] SIMPLICITE|http://de9cf55799ea:8080||INFO|system|com.simplicite.util.tools.SQLTool|rebuildSequence||Event: Sequence web_news_row_id_seq has been created
2021-01-25 18:37:40,064 INFO [com.simplicite.util.tools.SQLTool] SIMPLICITE|http://de9cf55799ea:8080||INFO|system|com.simplicite.util.tools.SQLTool|rebuildSequence||Event: Rebuild PostgreSQL sequence web_news_row_id_seq
2021-01-25 18:37:39,836 ERROR [com.simplicite.util.engine.ObjectManager] SIMPLICITE|http://de9cf55799ea:8080||ECOREDB001|system|com.simplicite.util.engine.ObjectManager|create||Error SQL query: Create failed for object WebNews and row ID = 5
2021-01-25 18:37:39,828 INFO [com.simplicite.util.tools.SQLTool] SIMPLICITE|http://de9cf55799ea:8080||INFO|system|com.simplicite.util.tools.SQLTool|rebuildSequence||Event: Sequence web_news_row_id_seq has been created
2021-01-25 18:37:39,817 INFO [com.simplicite.util.tools.SQLTool] SIMPLICITE|http://de9cf55799ea:8080||INFO|system|com.simplicite.util.tools.SQLTool|rebuildSequence||Event: Rebuild PostgreSQL sequence web_news_row_id_seq
2021-01-25 18:37:39,601 INFO [com.simplicite.util.tools.SQLTool] SIMPLICITE|http://de9cf55799ea:8080||INFO|system|com.simplicite.util.tools.SQLTool|rebuildSequence||Event: Sequence web_news_row_id_seq has been created
2021-01-25 18:37:39,591 INFO [com.simplicite.util.tools.SQLTool] SIMPLICITE|http://de9cf55799ea:8080||INFO|system|com.simplicite.util.tools.SQLTool|rebuildSequence||Event: Rebuild PostgreSQL sequence web_news_row_id_seq
OK Il y a donc bien un pb bizarre sur cet objet…
Dans nos test d’upgrade 4.0 (à jour) => 5.0 (à jour) sur PostgreSQL on a pas constaté de pb sur cet objet, donc il doit y avoir un truc “atypique” ici…
Pourrait on avoir un export XML complet du module WebContent de cette instance ?
Merci
c’est peut etre du au fait que, suite à l’upgarde, la version de ce module est resté à 4.0?
WebContent-4.0.xml (92.3 KB)
Non le numéro de version n’est qu’indicatif, il manque effectivement la mise à jour de ce numéro de version (4.0 => 5.0) pour les modules systèmes dans les patches, on va l’ajouter, c’est un oubli.
On va regarder ce que donne l’import de ce module sur une instance 5.0 à jour, on verra si on reproduit le pb. Je vous tiens au courant
1 Like
J’ai importé votre module sur une instance 5.0 à jour (5.0.8) sur POstgreSQL 10 et je ne reproduis pas le “error saving object” (ni votre pb de 403)
Je suis désolé je ne vois donc vraiment pas d’où peut venir ce pb.
@Francois, si tu as des idées… (idem pour ce qui concerne la “lenteur” constatée sur le clear cache global).
Pouvez vous nous confirmer la version exacte que vous utilisez ?
Bonjour,
Votre table web_news a dû mal migrer, l’erreur est au niveau du create. D’ailleurs on voit que Simplicité essaye de créer 3 fois au cas où ce soit un pb de séquence désynchronisée, on va ajouter la stack du SQLException dans les logs car là on ne voit pas pas la cause du problème SQL.
Une erreur de insert SQL est souvent lié à :
- une colonne manquante ou de mauvais type
- une violation d’index unique (primary ou user key)
- une colonne obligatoire manquante
Le passage en V5 implique d’avoir de nouvelles colonnes. Dans votre copie d’écran il manque la langue, le display est bien présent.
ALTER TABLE web_news ADD COLUMN nws_lang varchar(3);
-- ou alors
ALTER TABLE web_news ALTER COLUMN nws_lang TYPE varchar(3);
ALTER TABLE web_news ALTER COLUMN nws_lang SET NOT NULL;
ALTER TABLE web_news ADD COLUMN nws_display varchar(10);
DROP INDEX IF EXISTS web_news_uk;
CREATE UNIQUE INDEX web_news_uk ON web_news (nws_lang,nws_date,nws_title);
update web_news set nws_lang='ANY' where nws_lang is null;
commit;
Essayez de repasser ces patchs SQL.
et de façon préventive repassez tout le patch SQL de la version.
tomcat\webapps\ROOT\WEB-INF\patches\V5\P00\upgradedb_postgresql.sql
NB:
On est ici sur un déploiement Docker/K8S, donc pas d’accès aux fichiers patches…
La manière de forcer un repassage de tous les patches systèmes 5.0 c’est de changer (via la page DB access) le param système PATCH_LEVEL via SQL:
update m_system set sys_value='5;P00;x' where sys_code='PATCH_LEVEL'
Et de faire un arret/relance
PS: sinon @Francois pour “remettre au carré” la table de l’objet il ne suffit pas d’aller sur la définition de l’objet et d’enregister ?
oui si la définition de l’objet est bonne.
Il faut auditer la colonne nws_lang en base et dans l’objet car on voit bien qu’il y a quelque chose qui ne va pas entre la copie d’écran sans le champ et le create qui plante. La colonne est peut être là et obligatoire en base, mais le field n’est pas dans l’objet (par exemple mais je pense que c’est ça).
A priori la définition est bonne car le module exporté de cette instance et importé sur une instance de test out of the box n’a pas posé de pb.
Mais bon forcer le repassage de tous les patches 5.0 (comme indiqué ci-dessus) ne me semble pas une mauvaise chose de toute façon
Alors pourquoi il n’y a pas l’attribut d’objet de nws_lang dans le fichier joint un peu plus haut ?
@Francois j 'ai pas compris ta réponse…
Le nws_lang est bien dans le XML du module WebContent fourni
Et sur mon instance de test où j’ai importé ce module (avec diff final) il est bien toujours là et dans le bon module:
@Marwa_Tifafi essayez de réimporter ce module (et si possible faites la manip de repassage des patches 5.0)
Non
Soit je suis miro, soit je ne trouve l’attribut d’objet (et pas l’attribut) de nws_lang…
Il y a bien l’attribut dans le XML:
Mais effectivement pas l’attribut d’objet, et donc pas à l’arrivée:
Mais cela ne pose visiblement pas de pb sur cette instance là. Car sans doute la colonne avait été créé à un moment ou un autre ce qui n’est pas le cas sur l’instance upgradée.
On va regarder pourquoi il manque cet attribut d’objet et, si besoin, l’ajouter dans les patches 5.0 à titre conservatoire. En attendant @Marwa_Tifafi ajoutez le manuellement sur votre objet ça devrait résoudre votre pb