Then I propose to remove user_creation (and derivates) property usage from the class and fetch it externally.
Regards, *Marcos García* marcos...@gmail.com 2015-01-11 20:14 GMT+01:00 Laurent Destailleur (aka Eldy) < e...@destailleur.fr>: > sure, having user_creation allows to know fk_user_creation. > But this means, each time we load an objet to also loadd all child object. > In most cases, we store only the id and we make the load/fetch toi get and > store object only if we really need it. > > 2015-01-06 9:09 GMT+01:00 Marcos García <marcos...@gmail.com>: > >> Well, I just think that these two properties have the same data (all of >> them identify an user) >> >> >> - fk_user_creation id user creating object >> - user_creation object User creating object >> >> >> So, if we set and get the user_creation property we will be able to get >> it is ID. It is interesting to know and/or decide which property of the 2 >> is the most used and deprecate the other one to have an unique >> representation of the user that created the object. >> >> Regards, >> >> >> *Marcos García* >> >> marcos...@gmail.com >> >> >> 2015-01-04 19:22 GMT+01:00 Destailleur Laurent <e...@destailleur.fr>: >> >>> Currently, properties were using a lot of different name. Each >>> developer used to add properties with its onw name, so there is no >>> correct answer. >>> >>> It is time to normalize this. I started to suggest values for such >>> properties (user of creation, date and author) on this page. What do >>> you think of this rule on name: >>> >>> http://wiki.dolibarr.org/index.php/Langages_et_normes#Classes >>> >>> >>> >>> >>> 2014-12-28 19:27 GMT+01:00 Marcos García <marcos...@gmail.com>: >>> > Can I also know which of the following properties is the correct? >>> > >>> > /** >>> > * TODO: Which is the correct one? >>> > * Author of the contract >>> > * @var >>> > */ >>> > var $user_author; >>> > >>> > /** >>> > * TODO: Which is the correct one? >>> > * Author of the contract >>> > * @var User >>> > */ >>> > public $user_creation; >>> > >>> > /** >>> > * TODO: Which is the correct one? >>> > * Author of the contract >>> > * @var int >>> > */ >>> > public $fk_user_author; >>> > >>> > /** >>> > * TODO: Which is the correct one? >>> > * Author of the contract >>> > * @var int >>> > */ >>> > public $user_author_id; >>> > >>> > Different functions use different parameters that mean to be the >>> same... >>> > $user_author is the one that is not used around the code but was the >>> only >>> > one declared in the class. >>> > >>> > Regards, >>> > >>> > >>> > Marcos García >>> > >>> > marcos...@gmail.com >>> > >>> > >>> > 2014-12-28 17:59 GMT+01:00 Marcos García <marcos...@gmail.com>: >>> >> >>> >> Ok, thanks. >>> >> >>> >> And which of this two properties is deprecated? >>> >> >>> >> $this->socid = $result["fk_soc"]; >>> >> $this->fk_soc = $result["fk_soc"]; >>> >> >>> >> I'm improving the documentation of the class right now and was >>> wondering >>> >> about it. >>> >> >>> >> Regards, >>> >> >>> >> >>> >> Marcos García >>> >> >>> >> marcos...@gmail.com >>> >> >>> >> >>> >> 2014-12-27 1:12 GMT+01:00 Destailleur Laurent <e...@destailleur.fr>: >>> >>> >>> >>> The 3 first fields are used: >>> >>> >>> >>> - date_creation is date when user insert into database (not asked to >>> >>> user) = field datec into database >>> >>> - date_validation when user make last update (not asked to user) >>> >>> >>> >>> - date_contrat is date of contrat (date when contract was signed), >>> >>> asked when creating a new contrat. into the create, you may not have >>> >>> the field inserted, it may be inserted by calling the update inside >>> >>> the create. = date_contrat into database. >>> >>> - date_cloture is no more used because we close line of contract, not >>> >>> a contract. >>> >>> >>> >>> >>> >>> Both date_creation and date_contrat should be found into the create >>> >>> method and both into the fetch. >>> >>> >>> >>> >>> >>> >>> >>> 2014-12-26 12:22 GMT+01:00 Marcos García <marcos...@gmail.com>: >>> >>> > Hi all, >>> >>> > >>> >>> > I was looking at bug [ bug #1767 ] Contract document is not >>> generated >>> >>> > properly which is caused because it is trying to retrieve a >>> >>> > non-existent >>> >>> > property $object->datec as date of contract. >>> >>> > >>> >>> > But when I look at the Contrat class, I see like a lot of >>> properties >>> >>> > related >>> >>> > to date >>> >>> > >>> >>> > var $date_creation; >>> >>> > var $date_validation; >>> >>> > >>> >>> > var $date_contrat; ¿? >>> >>> > var $date_cloture; >>> >>> > >>> >>> > In fetch function, date_contrat is filled but date_creation is >>> not, and >>> >>> > in >>> >>> > create function, date_creation is but date_contrat is not. >>> >>> > >>> >>> > Which is the property I should get? >>> >>> > >>> >>> > Regards, >>> >>> > >>> >>> > >>> >>> > Marcos García >>> >>> > >>> >>> > marcos...@gmail.com >>> >>> > >>> >>> > >>> >>> > _______________________________________________ >>> >>> > Dolibarr-dev mailing list >>> >>> > Dolibarr-dev@nongnu.org >>> >>> > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >>> >>> > >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> Laurent Destailleur (alias Eldy) >>> >>> >>> >>> >>> ------------------------------------------------------------------------------------ >>> >>> Social networks of my OpenSource projects: >>> >>> Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ >>> >>> Dolibarr Facebook: https://www.facebook.com/dolibarr >>> >>> Dolibarr Twitter: http://www.twitter.com/dolibarr >>> >>> AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ >>> >>> AWStats Facebook: https://www.facebook.com/awstats.org >>> >>> AWStats Twitter: http://www.twitter.com/awstats_project >>> >>> >>> >>> _______________________________________________ >>> >>> Dolibarr-dev mailing list >>> >>> Dolibarr-dev@nongnu.org >>> >>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >>> >> >>> >> >>> > >>> > >>> > _______________________________________________ >>> > Dolibarr-dev mailing list >>> > Dolibarr-dev@nongnu.org >>> > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >>> > >>> >>> >>> >>> -- >>> Laurent Destailleur (alias Eldy) >>> >>> ------------------------------------------------------------------------------------ >>> Social networks of my OpenSource projects: >>> Dolibarr Google+: https://plus.google.com/+DolibarrOrg/ >>> Dolibarr Facebook: https://www.facebook.com/dolibarr >>> Dolibarr Twitter: http://www.twitter.com/dolibarr >>> AWStats Google+: https://plus.google.com/+AWStatsOrgPoject/ >>> AWStats Facebook: https://www.facebook.com/awstats.org >>> AWStats Twitter: http://www.twitter.com/awstats_project >>> >>> _______________________________________________ >>> Dolibarr-dev mailing list >>> Dolibarr-dev@nongnu.org >>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >>> >> >> >> _______________________________________________ >> Dolibarr-dev mailing list >> Dolibarr-dev@nongnu.org >> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev >> >> > > _______________________________________________ > Dolibarr-dev mailing list > Dolibarr-dev@nongnu.org > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev > >
_______________________________________________ Dolibarr-dev mailing list Dolibarr-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
