Re: [Dolibarr-dev] Gestion de projet

[Oxo]

Merci Eddy.

Je pense que c'est une excellente solution. En effet, intégrer une 
gestion de projet dans Dolibarr me semble compliquer. En effet, toutes 
les sociétés sont loin d'avoir les mêmes besoins. La notion même de 
gestion de projet peu différer d'un secteur à l'autre.

Cette solution permet donc de lier Dolibarr à d'autres logiciels 
spécifiques (gestion de projet, gestion de prod, timesheet - pour ceux 
qui veulent utiliser la notion de projet light de Dolibarr et gérer les 
temps- solution de publishing ...)

Il me semble important de ne pas trop partir dans tous les sens. Pour 
moi, Dolibarr est le : CRM et gestion commerciale allant jusqu'à la 
facturation. Il est plus important de renforcer les fonctionnalités dans 
ces domaines que de faire un CRM-ERP like qui fait un peu de tout (je ne 
vais pas en citer, mais il y en a beaucoup)
Bien entendu, ce n'est que mon point de vue d'utilisateur et de 
responsable SI. Je préfère prendre les meilleures briques logicielles 
quite à en avoir 3 ou 4, mais très performantes, que dans avoir une mais 
moyenne.

En conclusion, cette solution répond parfaitement à mon besoin et à ma 
vision stratégique de mon SI.

Voilà, c'était ma pensée du matin.

A+

Mathias


Eldy a écrit :

> Mathias WOLFF wrote:
>
> > Ce type de fonctionnement que tu proposes me convient parfaitement. 
> > Les mises à
> > jour peuvent-elles aussi être gérées de la même façon ?
> >
> > On peut donc imaginer le workflow suivant :
> > Validation de commande dans Dolibarr, crée une fiche projet dans 
> > dotproject ?
> >
> > Est-ce que je me trompe ?
> >
> >  
> C'est ca.
> Toute action Dolibarr (disons les principale actions métiers, 
> création/modification/suppression d'une 
> commande/facture/société/produit) appellerait une méthode 
> "run_triggers" (avec un s) en envoyant 5 paramètres: un code propre à 
> l'action, l'objet concerné par l'action, la variable $langs, $user et 
> $conf.
> Libre ensuite à l'intégrateur de placer dans le répertoire 
> includes/modules/triggers un fichier php (ou plusieurs) qui contiendrait
> une methode run_trigger (sans le s cette fois). La methode 
> run_triggers (avec le s) appellerait toutes les methodes run_trigger 
> (sans s) qu'elle trouve dans ce répertoire (si elle en trouve). 
> L'intégrateur y met le code qu'il veut dans cette fonction. Et comme 
> cette fonction reçoit le code de l'évênement Dolibarr, l'objet 
> concerné et la conf et la langue de l'utilisateur, il peut en faire ce 
> qu'il veut pour une interaction avec l'extérieur.
>
> Cette solution d'interfaçage est juste une solution générique pour 
> permettre à n'importe quel développeur d'interfacer Dolibarr 
> facilement dans les plupart des situations avec une appli extérieur 
> (sans forcément de rapport avec la discussion actuelle sur la gestion 
> des projets mais l'idée m'est venu à ce moment là, et l'idée crée le 
> besoin chez moi :-) . En résumé, c'est une solution pour créer ou 
> plutôt "permettre de créer" un workflow Dolibarr vers extérieur.
>
>
> > Mathias
> >
> > Selon Eldy <address@hidden>:
> >