<![CDATA[Crème CRM - Bugs]]> https://www.cremecrm.com/forum/ Thu, 14 May 2026 12:19:33 +0000 MyBB <![CDATA[[connu] L'interface ne s'adapte pas dynamiquement à la fenêtre]]> https://www.cremecrm.com/forum/showthread.php?tid=62 Wed, 18 Jun 2014 15:49:31 +0200 Saga]]> https://www.cremecrm.com/forum/showthread.php?tid=62
J'ai repéré un bug. Le positionnement et la taille des éléments html sur l'interface de Crème ne s'adapte que lors du chargement de la page. Par exemple quand je redimensionne mon navigateur, voici ce qu'il se passe :

[PJ non disponibles]

Également, je pense qu'il est important (mais ne le prenez pas mal) de professionnaliser l'interface. Je suis en stage dans une entreprise qui cherche à remplacer Sugar CRM devenu propriétaire et cette interface trop "geek" à l'air de faire douter de la qualité de ce CRM qui est mieux que ce qu'il peut laisser penser, et c'est là qu'il y a un problème.

Je comprend par contre que vous soyez attaché à cette sympathique interface mais je préfère être honnête.

Bonne fin de journée à vous, vous faîtes du super boulot !  Smile]]>
J'ai repéré un bug. Le positionnement et la taille des éléments html sur l'interface de Crème ne s'adapte que lors du chargement de la page. Par exemple quand je redimensionne mon navigateur, voici ce qu'il se passe :

[PJ non disponibles]

Également, je pense qu'il est important (mais ne le prenez pas mal) de professionnaliser l'interface. Je suis en stage dans une entreprise qui cherche à remplacer Sugar CRM devenu propriétaire et cette interface trop "geek" à l'air de faire douter de la qualité de ce CRM qui est mieux que ce qu'il peut laisser penser, et c'est là qu'il y a un problème.

Je comprend par contre que vous soyez attaché à cette sympathique interface mais je préfère être honnête.

Bonne fin de journée à vous, vous faîtes du super boulot !  Smile]]> <![CDATA[Bug version développement 1.4 alpha : migration de rapports]]> https://www.cremecrm.com/forum/showthread.php?tid=43 Mon, 25 Nov 2013 14:37:25 +0100 genglert]]> https://www.cremecrm.com/forum/showthread.php?tid=43
Aussi, si vous avez mis à jour le code entre le commit (1944f314c5da du 8 octobre 2014) et le cff09a7299eb, et que vous avez réussi a faire cette migration , vous devrez, pour mettre à jour votre base de données avec le code actuel, faire 2 manipulations de la base de données à la main :
  • Dans la table "south_migrationhistory", supprimez la ligne correspondant à la migration "0006_v1_4__rename_field_report".
  • Dans la table "reports_field", renommez la colonne "sub_report_id" en "report_id".

Si vous n'utilisez pas de version de développement, ou que vous n'êtes pas dans le cas précis décrit ci-dessus, vous n'avez rien à faire de particulier.]]>
Aussi, si vous avez mis à jour le code entre le commit (1944f314c5da du 8 octobre 2014) et le cff09a7299eb, et que vous avez réussi a faire cette migration , vous devrez, pour mettre à jour votre base de données avec le code actuel, faire 2 manipulations de la base de données à la main :
  • Dans la table "south_migrationhistory", supprimez la ligne correspondant à la migration "0006_v1_4__rename_field_report".
  • Dans la table "reports_field", renommez la colonne "sub_report_id" en "report_id".

Si vous n'utilisez pas de version de développement, ou que vous n'êtes pas dans le cas précis décrit ci-dessus, vous n'avez rien à faire de particulier.]]> <![CDATA[Bug version développement 1.2 alpha : SIREN migration]]> https://www.cremecrm.com/forum/showthread.php?tid=7 Fri, 09 Mar 2012 12:04:06 +0100 jcaruana]]> https://www.cremecrm.com/forum/showthread.php?tid=7
Aux utilisateurs de la version développement Crème 1.2 alpha. Suite à une erreur de conception vous risquez de rencontrer un problème lors de la migration de vos données si vous avez créer une base correspondant à une version comprise entre le 28 février 2012 (changeset eef168788a2f) et le 08 mars 2012 (changeset 420a73d639db). Nous sommes en effet revenus sur nos pas concernant le SIREN des organisations. Conceptuellement unique, ce champ ne doit pour autant pas être obligatoire pour créer une organisation et en fonction des SGBD un champ nullable peut engendrer une violation si ce dernier est unique et apparait à plusieurs reprises.

Afin de corriger cette anomalie vous pouvez exécuter la commande SQL suivant sur votre base afin d'effacer cette modification de l'historique de votre migration :

Code :
DELETE FROM `south_migrationhistory` WHERE migration='0002_v1_2__add_unique_organisation_siren';
]]>
Aux utilisateurs de la version développement Crème 1.2 alpha. Suite à une erreur de conception vous risquez de rencontrer un problème lors de la migration de vos données si vous avez créer une base correspondant à une version comprise entre le 28 février 2012 (changeset eef168788a2f) et le 08 mars 2012 (changeset 420a73d639db). Nous sommes en effet revenus sur nos pas concernant le SIREN des organisations. Conceptuellement unique, ce champ ne doit pour autant pas être obligatoire pour créer une organisation et en fonction des SGBD un champ nullable peut engendrer une violation si ce dernier est unique et apparait à plusieurs reprises.

Afin de corriger cette anomalie vous pouvez exécuter la commande SQL suivant sur votre base afin d'effacer cette modification de l'historique de votre migration :

Code :
DELETE FROM `south_migrationhistory` WHERE migration='0002_v1_2__add_unique_organisation_siren';
]]> <![CDATA[Bug version développement 1.2 alpha : south migration]]> https://www.cremecrm.com/forum/showthread.php?tid=6 Fri, 20 Jan 2012 15:11:04 +0100 jcaruana]]> https://www.cremecrm.com/forum/showthread.php?tid=6
Aux utilisateurs de la version développement Crème 1.2 alpha. Si vous avez créer une base correspondant à une version comprise entre le 12/12/2011 (changeset 50fa73945943) et aujourd'hui 20/01/2012 (changeset e6e4eed863b9) alors vous allez rencontrer un problème lors de la migration de vos données. Ce problème de nommage se résout en exécutant les 3 commandes SQL ci-dessous.

Code :
UPDATE `south_migrationhistory` SET migration='0006_v1_2__in_line_table_delete_credit_ispaid_modify_quantity_add_new_vat_fields' WHERE migration='0006_v1_1__in_line_table_delete_credit_ispaid_modify_quantity_add_new_vat_fields';
UPDATE `south_migrationhistory` SET migration='0007_v1_2__migrate_vat' WHERE migration='0007_v1_1_migrate_vat';
UPDATE `south_migrationhistory` SET migration='0008_v1_2__del_field_line_vat' WHERE migration='0008_v1_1__del_field_line_vat'
]]>
Aux utilisateurs de la version développement Crème 1.2 alpha. Si vous avez créer une base correspondant à une version comprise entre le 12/12/2011 (changeset 50fa73945943) et aujourd'hui 20/01/2012 (changeset e6e4eed863b9) alors vous allez rencontrer un problème lors de la migration de vos données. Ce problème de nommage se résout en exécutant les 3 commandes SQL ci-dessous.

Code :
UPDATE `south_migrationhistory` SET migration='0006_v1_2__in_line_table_delete_credit_ispaid_modify_quantity_add_new_vat_fields' WHERE migration='0006_v1_1__in_line_table_delete_credit_ispaid_modify_quantity_add_new_vat_fields';
UPDATE `south_migrationhistory` SET migration='0007_v1_2__migrate_vat' WHERE migration='0007_v1_1_migrate_vat';
UPDATE `south_migrationhistory` SET migration='0008_v1_2__del_field_line_vat' WHERE migration='0008_v1_1__del_field_line_vat'
]]>