Intégration GIT

Support
61

Le field est de taille 10 donc la colonne devrait être du varchar(10).
Sur une 5.0.21 out of the box sur PostgreSQL c’est bien le cas:

simplicite=# \d m_module
                             Table "public.m_module"
      Column      |            Type             | Collation | Nullable | Default
------------------+-----------------------------+-----------+----------+---------
 row_id           | integer                     |           | not null |
 created_dt       | timestamp without time zone |           | not null |
 created_by       | character varying(100)      |           | not null |
 updated_dt       | timestamp without time zone |           | not null |
 updated_by       | character varying(100)      |           | not null |
 mdl_name         | character varying(100)      |           |          |
 mdl_version      | character varying(10)       |           |          | <=========== varchar(10) ici
 mdl_xml          | integer                     |           |          |
 mdl_url          | text                        |           |          |
 mdl_lastparam_dt | timestamp without time zone |           |          |
 mdl_audit        | character(1)                |           |          |
 mdl_comment      | text                        |           |          |
 mdl_log          | text                        |           |          |
 mdl_autoupd      | character(1)                |           |          |
 mdl_lastupd      | timestamp without time zone |           |          |
 mdl_prefix       | character varying(25)       |           |          |
Indexes:
    "m_module_pkey" PRIMARY KEY, btree (row_id)
    "m_module_uk" UNIQUE, btree (mdl_name)

A l’endroit indiqué dans le stacktrace c’est la valeur passée via --form version=... qui est utilisée, pas celle dans le fichier du module.

Donc s’il y a plus de 10 caractères dans votre variable $PROJECT_VERSION ça peut induire ce pb.

PS: Cela dit je pense que cet argument version pourrait être facultatif dans tous les cas, car l’import de module l’écrasera de toute façon avec la valeur paramétrée.

62

D’accord je vais ignorer ce paramètre à ce moment là. Ca sera le plus simple.

63

Pour le moment il est obligatoire mais mettez --form version=0

Le rendre facultatif est une évolution, on verra si c’est faisable et backportable

64

En ce qui nous concerne ça n’a pas d’importance et il n’y a, de mon point de vue, pas de besoin pour nous de le backporter

65

C’est l’occasion de se replonger dans cette partie du code qui date, en grande partie, des origines de Simplicité et qui se traine visiblement encore des contraintes qui n’ont plus forcément raison d’être.

66

Dans la série “actualisation de vieux trucs” on va devoir changer le nom du fichier descripteur de module des formats ZIP/Git de package.json à module-info.json.

En effet ce nom package.json est plutôt dévolu au mode Javascript et cela créé donc des ambiguïtés et des warning inutiles dans les IDEs.

Le fichier package.json présent dans d’anciens exports fonctionnera encore (en fallback du nouveau fichier), mais les nouveaux exports de modules génèreront un module-info.json.

Par souci d’homogénéité on souhaite backporter ce changement sur toutes les branches 5 et 4.0

Dites moi si ça a des impacts chez vous

67

De mon point de vue aucun. On se base sur le descripteur de module pour recouper sa version et pas sur le package.json.

68

Ok parfait. On poussera ça sans doute dans la 5.0.22

69

On peut envisager d’agrandir le champ mdl_version du Module si besoin, il est surtout informatif et ça n’aura aucun impact.

70

Oui c’est vrai que 10 caractères c’est faible => si on met 12.45.26-beta2 ça dépasse.
On le passe à 50 ?

71

Ok je vais pousser ça.

72

C’est fait sur la 5.2, je backporterai à l’occasion

73

Pour le paramètre EXPORT_MODULE_EXPLODED, quelle est la meilleure manière de le setter ?
Nous avons 3 modules, je pensais créer une dispotion sur le le module de paramètrage technique pour porter cette variable, c’est viable ?

74

Pour toute surcharge de param système il y a 2 options:

  1. utiliser la “Overriden value” => cette approche implique un process manuel par saisie de la UI ou l’import d’un patch XML du genre:
<?xml version="1.0" encoding="UTF-8"?>
<simplicite xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.simplicite.fr/base" xsi:schemaLocation="http://www.simplicite.fr/base https://www.simplicite.io/resources/schemas/base.xsd">
<object>
	<name>SystemParam</name>
	<action if="exists">update</action>
	<data>
		<sys_code>EXPORT_MODULE_EXPLODED</sys_code>
		<sys_value2>yes</sys_value2>
	</data>
</object>
</simplicite>
  1. utiliser un param système de disposition associé à la disposition “default” => cette approche permet un packaging dans un module ad hoc

image
image2529×1244 215 KB

Perso j’utilise toujours l’approche 2) car, justement, elle permet de packager dans des modules

75

Merci beaucoup.
Par quel moyen peut-on préciser l’identité de la personne qui commit ? Faut-il obligatoirement avoir son propre user nominatif en local ?

76

C’est le user qui est utilisé.

Il faut donc avoir un user personnel, ce qui est de toute façon une bonne chose pour ne pas utiliser “designer” qui est l’équivalent Simplicite du “root” Linux et qu’il faut donc éviter d’utiliser.

77

Est-ce possible d’avoir le/les user dès le départ en faisant un import de données pour ne pas avoir a les recréer à chaque fois qu’on redéploie l’environnement ? Faut-il les lier ces users à un module supplémentaire ?

Je cherche à optimiser le fonctionnement pour le développement car en faisant mes tests je me rend compte que ça peut être assez fastidieux à l’initialisation et je souhaite que ce soit le plus fluide pour tout le monde.

78

Un user et ses responsabilités peuvent être mis dans un de vos modules. Il n’y a que le password qui n’est pas exportable/importable ainsi mais on peut le forcer via un patch XML du genre:

<?xml version="1.0" encoding="UTF-8"?>
<simplicite xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.simplicite.fr/base" xsi:schemaLocation="http://www.simplicite.fr/base https://www.simplicite.io/resources/schemas/base.xsd">
<object>
    <name>UserPwd</name>
    <action>update</action>
    <data>
        <usr_login_read>admin</usr_login_read>
        <usr_password>mypassword</usr_password>
    </data>
</object>
</simplicite>

On peut aussi avoir un patch XMLqui contient, le bloc de creation du user, de ses responsabilités et qui force son password.

Si on parle de users de dev différents d’un env à l’autre je procéderait plutôt comme ça avec un XML “template” dans lequel je substituerais à la volée le user que je veux créer, genre:

<?xml version="1.0" encoding="UTF-8"?>
<simplicite xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://www.simplicite.fr/base" xsi:schemaLocation="http://www.simplicite.fr/base https://www.simplicite.io/resources/schemas/base.xsd">
<object>
	<name>User</name>
	<action>upsert</action>
	<data>
		<usr_login>admin</usr_login>
		<usr_first_name>Admin</usr_first_name>
		<usr_last_name>ADMIN</usr_last_name>
		<usr_lang>FRA</usr_lang>
		<usr_email>admin@mydomain.com</usr_email>
		<usr_active>1</usr_active>
		<usr_home_id.viw_name>MyAdminHome</usr_home_id.viw_name>
		<row_module_id.mdl_name>ApplicationUsers</row_module_id.mdl_name>
	</data>
</object>
<object>
	<name>Responsability</name>
	<action>upsert</action>
	<data>
		<rsp_login_id.usr_login>admin</rsp_login_id.usr_login>
		<rsp_group_id.grp_name>MY_ADMIN</rsp_group_id.grp_name>
		<rsp_start_dt>2019-04-09</rsp_start_dt>
		<rsp_end_dt/>
		<rsp_activ>1</rsp_activ>
		<row_module_id.mdl_name>ApplicationUsers</row_module_id.mdl_name>
	</data>
</object>
(...)
<object>
    <name>UserPwd</name>
    <action>update</action>
    <data>
        <usr_login_read>admin</usr_login_read>
        <usr_password>mypassword</usr_password>
    </data>
</object>
</simplicite>

Attention un patch XML doit être importé via l’ import XML simple (curl --form service=xmlimport ...), pas par l’import de module (pour ne pas supprimer les éventuels autres items de paramétrage du module avec le diff final)

1 Like
79

Super c’est exactement ce que je cherchais, merci.

80

Bonjour,

Vu qu’on est amené à modifier régulièrement ce paramètre pour changer de branche, est-il possible de corriger ce bug ? Souvent, même avec une modification “neutre”, il reste toujours sur la branch develop.