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
