Projet

Général

Profil

Development #27994

texte riche pour les commentaires (usagers/agents)

Ajouté par Frédéric Péters il y a plus de 5 ans. Mis à jour il y a plus de 2 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Version cible:
-
Début:
14 novembre 2018
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

via #27990,

Ckeditor devienne aussi l'éditeur pour :

Éventuellement l'action de worfklow commentaire (mais là il s'agit d'avoir un ckeditor dans l'interface de traitement, y a peut-être des soucis différents. C'est moins important que le reste).


Fichiers


Demandes liées

Lié à w.c.s. - Development #56456: Zone commentaire d'un traitement d'une demande // Mise en forme du texte saisiFermé30 août 2021

Actions
Lié à w.c.s. - Development #58808: utiliser bleach pour le nettoyage HTMLFermé21 novembre 2021

Actions

Révisions associées

Révision 7338e136 (diff)
Ajouté par Frédéric Péters il y a plus de 2 ans

misc: allow "rich" text in comments (#27994)

Révision 0ec6a37b (diff)
Ajouté par Frédéric Péters il y a plus de 2 ans

trivial: make sure an empty form_comment is the empty string (#27994)

Historique

#1

Mis à jour par Thomas Noël il y a presque 5 ans

À noter qu'il faudra alors gérer l'inclusion de ces commentaires html dans les mails ou documents odt (peut-être à l'aide de filtres à écrire, ou juste |safe pour les mails s'ils sont eux aussi édités en html, cf #27990)

#2

Mis à jour par Benjamin Dauvergne il y a presque 5 ans

Thomas Noël a écrit :

À noter qu'il faudra alors gérer l'inclusion de ces commentaires html dans les mails ou documents odt (peut-être à l'aide de filtres à écrire, ou juste |safe pour les mails s'ils sont eux aussi édités en html, cf #27990)

Pour ODT c'est juste, comment dire, ... il n'y pas de sous-ensemble d'éléments dans le schéma ODT qui permette une mise en forme simple, tout passe par les styles et donc même avec une lib faite exprès ça donne ça :

https://github.com/lpod/lpod-python-recipes/blob/master/Examples/create_a_text_document_from_plain_text_with_layout.py


# master style, using the precedent layout for the actual document
_style_master = odf_create_element(u"""\
<style:master-page style:name="Standard" \
style:page-layout-name="MyLayout"><style:footer><text:p text:style-name="Footer">\
<text:tab/><text:tab/><text:page-number \
text:select-page="current"/> / <text:page-count \
style:num-format="1">15</text:page-count></text:p></style:footer>\
</style:master-page>""")

Pas glop.

#3

Mis à jour par Frédéric Péters il y a plus de 2 ans

  • Lié à Development #56456: Zone commentaire d'un traitement d'une demande // Mise en forme du texte saisi ajouté
#4

Mis à jour par Frédéric Péters il y a plus de 2 ans

#5

Mis à jour par Frédéric Péters il y a plus de 2 ans

  • Statut changé de Nouveau à En cours
  • Assigné à mis à Frédéric Péters
#6

Mis à jour par Frédéric Péters il y a plus de 2 ans

Il y a déjà du code qui peut être relu dans la branche, juste ça utilise ckeditor pour tester en attendant #59578.

#8

Mis à jour par Frédéric Péters il y a plus de 2 ans

Voilà avec l'intégration godo. Le truc de l'utilisation sous forme de module js, ça fait que l'infra "add_javascript" ne peut pas être utilisée, donc pas de switch entre version minifiée ou pas selon le debug activé ou pas.

À part ça, le truc important c'est que le commentaire est désormais enregistré dans son propre objet (WorkflowCommentPart) plutôt que directement dans un attribut "comment" de l'objet Evolution. Ça correspond à ce qu'on a toujours fait pour les fichiers attachés et les informations ajoutées via l'action "Message dans l'historique" et ce qui est désormais aussi fait pour l'action "formulaire". L'attribut "comment" reste utilisé à la marge ("Administrator reassigned status" et "Form exported in a model") et ça pourra disparaitre.

Pour compatibilité avec un éventuel existant le commentaire reste tapé en vrac dans workflow_data, dans une version sans balisage.

Le commentaire était également utilisé de manière automatique dans un {{form_evolution}}, je pense que plus personne n'utilise ça mais pareil une version sans balisage y est posée.

Il y a aussi {{form_comment}} et pareil pas clair que ça soit encore utilisé (chercher form_comment ne donne aucun résultat sur le site de la doc) mais même plan ici, version sans balisage.

#9

Mis à jour par Benjamin Dauvergne il y a plus de 2 ans

Frédéric Péters a écrit :

Voilà avec l'intégration godo. Le truc de l'utilisation sous forme de module js, ça fait que l'infra "add_javascript" ne peut pas être utilisée, donc pas de switch entre version minifiée ou pas selon le debug activé ou pas.

Je ne comprends pas bien la différence avec un bout de js normal; est-ce que tu vois quelque chose que je peux changer au packaging pour améliorer ça ? Il me semble que leaflet est aussi packagé sous forme xstatic.

#10

Mis à jour par Frédéric Péters il y a plus de 2 ans

Je ne comprends pas bien la différence avec un bout de js normal.

C'est un "module js". Il ne se trouve pas chargé via un <script src="..."> (gérée via response.add_javascript, qui a du code pour choisir une version minifiée si pas debug); ici il est chargé "inline" par une ligne :

import Godo from "/static/xstatic/js/godo.js";

(et oui il y aurait moyen d'exposer le booléen comme quoi on est en mode debug et l'utiliser ici pour faire varier le chemin, mon propos est que ça ne matche pas l'infra actuelle) (côté godo j'avais créé #59585 qui couvrait un peu ça) (ça n'est pas bien grave, c'est gzipé 70ko à transférer en plus, ne passons pas de temps ici sur cette partie).

#11

Mis à jour par Benjamin Dauvergne il y a plus de 2 ans

  • Statut changé de Solution proposée à Solution validée

Ok. Je verrai bien l'ajout de strip=True à bleach.clean() à son propre commit, ça n'a pas l'air lié particulièrement à ce nouveau widget ou alors je veux bien une explication (j'ai donné un coup d’œil à la doc1 de bleach, j'ai l'impression que ça aurait du déjà être la bonne valeur à appliquer avant ce ticket).

1 https://bleach.readthedocs.io/en/latest/clean.html#bleach.clean

#12

Mis à jour par Frédéric Péters il y a plus de 2 ans

Le strip=True est introduit ici parce que c'est ici qu'on introduit une limitation sévère sur les balises autorisées. Comme elles étaient toutes autorisées avant, ça n'avait pas d'incidence.

#13

Mis à jour par Frédéric Péters il y a plus de 2 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit 7338e136e5df7ce7a569a479f9cc4731b035c22c
Author: Frédéric Péters <fpeters@entrouvert.com>
Date:   Tue Dec 14 10:43:44 2021 +0100

    misc: allow "rich" text in comments (#27994)
#14

Mis à jour par Frédéric Péters il y a plus de 2 ans

  • Statut changé de Résolu (à déployer) à Solution déployée
#15

Mis à jour par Transition automatique il y a environ 2 ans

Automatic expiration

Formats disponibles : Atom PDF