Silverpeas » Silverpeas Components » GED

Nous sommes vraiment bloqués avec ces publications sur cette GED
EUROPE - MEA > BIR - BIRMINGHAM > DIRECTION > MAN 01 > CAPEX (API, ASI) > Common Capex Follow Up Template > Common Capex Follow up Template (https://www.mgicoutier.net/silverpeas/Publication/631003)

On a refait la même manipulation --> Le fonctionnement est bon
On va avoir plein de cas de ce type
C'est pour cela que je vous ai gardé la première version qui ne fonctionne pas.

J'ai pu isoler l'erreur (qui est en réalité un warning, et n'apparaissait donc pas dans le log). Voir PJ.
La ligne qui pose problème est :

template.setAttribute("attachmentAuthor", authorDetail.getFirstName() + " " + authorDetail.getLastName());

Le problème vient du fait que le modifieur ou le créateur de la dernière version du document n'est pas identifié. on peut le voir d'ailleurs dans l'historique des
versions.

Reste à comprendre pourquoi alors que le document de la publication dont elle est issue (via copie) comporte bien ces infos...

Est-ce que la publication 631003
est une copie de https://www.mgicoutier.net/silverpeas/Publication/632731 ?

• est une autre copie qui a bien fonctionné la deuxième fois
  L'erreur est sur https://www.mgicoutier.net/silverpeas/Publication/631003

Où est la publication d'origine ?

Non ce lien est la nouvelle GED.
La publication originale a été supprimé par le responsable de la GED

Marc Avenel a écrit :

La publication originale a été supprimé par le responsable de la GED

Elle doit donc être encore dans la corbeille... je réitère ma demande.

Par contre sur le serveur de TEST : L'original existe.

Dans la corbeille je regarde. ET je vous dis de suite...

La GED: EUROPE - MEA > BIR - BIRMINGHAM > DIRECTION > MAN 01 OLD
Mais ils ont supprimé la GED également.

• EUROPE - MEA > NES - NESLE > DIRECTION > MAN 01 OLD > CAPEX > Capex follow up
• Publication concernée: https://www.mgicoutier.net/silverpeas/Publication/559053
• Fichier suivant : Common Capex follow up Template NES.xlsx
  Dans ce cas la notification est correcte.

• EUROPE - MEA > NES - NESLE > DIRECTION > MAN 01 > CAPEX (API, ASI) > Capex follow up
• Publication copiée: https://www.mgicoutier.net/silverpeas/Publication/628650
• Fichier suivant: Common Capex follow up Template NES.xlsx

Dans ce cas la notification est en erreur.

• La première fois, ce n'est pas correct
• si on refait la même manipulation, la copie est correcte

Il apparait que le champ lastModifiedBy a changé entre l'original et la copie
Sa valeur vaut l'id de l'utilisateur dans l'original, et 'system' dans la copie.

A voir si cela est normal, mais le code lui ne gère pas ce cas de figure...
voir à partir de la ligne 94 dans KmeliaDocumentSubscriptionPublicationUserNotification.java

Path[/kmelia28812/attachments/simpledoc_1136410/file_fr]
% ls -l
/kmelia28812/attachments/simpledoc_1136410/file_fr
+-properties
| +-jcr:description: ''
| +-jcr:title: ''
| +-slv:creator: '8657'
| +-jcr:created: 2017-11-07T15:36:32.847+01:00
| +-slv:size: 464891
| +-jcr:primaryType: slv:simpleAttachment
| +-jcr:lastModifiedBy: '8657'
| +-slv:creationDate: 2017-11-07T15:36:32.841+01:00
| +-jcr:language: 'fr'
| +-jcr:createdBy: 'system'
| +-jcr:mimeType: 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'
| +-jcr:lastModified: 2018-01-26T17:26:59.748+01:00
| +-slv:name: 'Common Capex follow up Template NES.xlsx'
+-children

Dans la publication copiée :

Path[/kmelia30990/attachments/simpledoc_1236148/file_fr]
% ls
/kmelia30990/attachments/simpledoc_1236148/file_fr
+-properties
| +-jcr:description: ''
| +-jcr:title: ''
| +-slv:creator: '8657'
| +-slv:size: 464891
| +-jcr:created: 2018-02-22T16:28:12.778+01:00
| +-jcr:primaryType: slv:simpleAttachment
| +-jcr:lastModifiedBy: 'system'
| +-slv:creationDate: 2017-11-07T15:36:32.841+01:00
| +-jcr:language: 'fr'
| +-jcr:createdBy: 'system'
| +-jcr:mimeType: 'application/vnd.openxmlformats-officedocument.spreadsheetml.sheet'
| +-jcr:lastModified: 2018-01-26T17:26:59.748+01:00
| +-slv:name: 'Common Capex follow up Template NES.xlsx'
+-children

Votre question

J'aimerais savoir si la publication est copiée unitairement, par sélection groupée avec d'autres publications, par dossier, ou par GED ?

• Sélection de la publication
• Copie de la publication cible
• Copie de la publication dans la nouvelle GED
• Si tout est correct : alors suppression de la publication de la GED source et ensuite de la GED source quand plus de publication à copier

Avez vous pu avancer sur ce sujet?
Les utilisateurs des différents sites déplacent leur informations issus du MAN dans la nouvelle structure.
Doivent-ils attendre ou continuer en espérant aucune erreur ?
Merci à vous0

Marc Avenel a écrit :

Merci à vous
Ce que je ne comprends pas

• La première fois, ce n'est pas correct
• si on refait la même manipulation, la copie est correcte

Attention, ce comportement n'est pas systématique. Les 2-3 tests de copie que j'ai effectué, cela a fonctionné du 1er coup.

Marc Avenel a écrit :

Avez vous pu avancer sur ce sujet?
Les utilisateurs des différents sites déplacent leur informations issus du MAN dans la nouvelle structure.
Doivent-ils attendre ou continuer en espérant aucune erreur ?

Pour l'instant, il vaut mieux faire une pause sur ces opérations.

OK.
Mais les sites sont en pleine refonte de leur publications.
Pensez vous avoir une solution rapidement que j'informe les sites?
Merci à vous

• pas de workflow
• pas de template

Marc Avenel a écrit :

Si je prends cette publication :https://www.mgicoutier.net/silverpeas/Publication/631003

• Si je clique sur "All versions"
• Je vois que les deux premières versions sont associées à un utilisateur mais pas de la 3ème
• sur cette historique, je clique sur page 2 et je reviens sur page 1
• Les 3 premières sont maintenant avec des noms à ???

Voir copie écran

Vous pouvez saisir un autre ticket pour ce problème de pagination qui se mélange dans les langues ?

Non c'est bien le même ticket.
C'est bien l'historique de la publication que l'on cherche à déplacer.
C'est pour vous démontrer que l'historique se comporte de manière aléatoire.
Comme vous l'indiquez https://tracker.silverpeas.org/issues/9601#note-29

Je permets de vous relancer car nos utilisateurs sont bloqués.
D'avance je vous en remercie

Marc Avenel a écrit :

Non c'est bien le même ticket.
C'est bien l'historique de la publication que l'on cherche à déplacer.
C'est pour vous démontrer que l'historique se comporte de manière aléatoire.
Comme vous l'indiquez https://tracker.silverpeas.org/issues/9601#note-29

Le ticket d'origine parle d'une erreur lorsqu'on veut notifier un document...
Le comportement de la pagination sur les versions est un autre problème qu'il faut caractériser par un autre ticket.

Non pas d'accord avec vous.
C'est quand on copie une GED vers un autre espace qu'il y a un problème sur la notification et l'historique des versions
Le titre du ticket: GED-Copier/coller d'une publication-Erreur sur notification

Marc Avenel a écrit :

Non pas d'accord avec vous.
C'est quand on copie une GED vers un autre espace qu'il y a un problème sur la notification et l'historique des versions

Il n'a JAMAIS été qeustion de "copie de GED vers un autre espace" dans ce ticket...

• Notification HS
• Historique ne correspond pas d'une page à une autre

Pour qualifier correctement ce pb de rendu lors du passage d'une page à l'autre dans la pagination de l'historique des versions d'une publication, pouvez vous svp vérifier si celui ci a lieu qu'avec les publications copiées ou si elle est aussi existante avec les publications non issues de copies.

Ce que David voulait ici signifier est que cette demande est relative au problème des notifications avec les publications copiées.
Par conséquent, s'il y aussi pb avec l'historique des versions d'une publication copiée alors c'est une autre demande, même si issue apparemment d'une même opération, en l'occurrence la copie.

David Lesimple a écrit :

Les 10 premières versions ont une date au 24/1/2018 et 15h41, ces infos ne semblent pas correctes, tout d'abord parce que faie 10 version en 1 minutes parait étrange..
mais surtout parce que la date ne correspond pas à la date indiquée dans les commentaires (version 31).

Est-ce que c'est correct dans la publication à l'origine de la copie ?

Miguel Moquillon a écrit :

Pour qualifier correctement ce pb de rendu lors du passage d'une page à l'autre dans la pagination de l'historique des versions d'une publication, pouvez vous svp vérifier si celui ci a lieu qu'avec les publications copiées ou si elle est aussi existante avec les publications non issues de copies.

Je viens de faire un test avec une publication existante crée précemment dans une GED de test, et le problème de perte de contexte de langue après pagination est bien reproduite également.

Nicolas Eysseric a écrit :

David Lesimple a écrit :

Les 10 premières versions ont une date au 24/1/2018 et 15h41, ces infos ne semblent pas correctes, tout d'abord parce que faie 10 version en 1 minutes parait étrange..
mais surtout parce que la date ne correspond pas à la date indiquée dans les commentaires (version 31).

Est-ce que c'est correct dans la publication à l'origine de la copie ?

Pour cet exemple, la publication d'origine a été supprimée par l'utilisateur.
mais par contre, il y a cet autre exemple, avec l'ancienne et la nouvelle publication
https://tracker.silverpeas.org/issues/9601#note-18

Les deux PR, après validation, ont été intégrés dans Silverpeas 5.15.7-SNAPSHOT.
Il ne reste plus qu'à mettre à jour votre plate-forme Silverpeas avec cette version.

Nous devons récupérer Silverpeas 5.15.7-SNAPSHOT.
Celle que vous avez installé sur le serveur de TEST le 08/03/2017 est à remplacer?
Merci à vous.

Marc Avenel a écrit :

Nous devons récupérer Silverpeas 5.15.7-SNAPSHOT.
Celle que vous avez installé sur le serveur de TEST le 08/03/2017 est à remplacer?
Merci à vous.

oui, avec

  mvn clean install -U

Ce correctif a bien été validé sur la version 5.15.7-SNAPSHOT, sur notre environnement de test.
Il s'agit d'un bug important et nous voudrions l'installer au plus vite sur notre environnement de Production.

Pouvez-vous nous donner une date de sortie de la version 5.15.7 ?

Merci

• Comme il y a une mise à jour de bibliothèque pour le workflow RFQ
• Que notre serveur n'a plus besoin d'être relancé

Nous désirons faire qu'un seul arrêt de serveur.
D'avance je vous en remercie

Merci pour l'information
Pas prévu de 5.15.8 ?
C'est bien cela.

Lié avec le ticket 9612.
Si c'est bien le cas c'est intégré dans la 5.15.7
Merci