Re: [Dolibarr-dev] Which column is correct?

[Laurent Destailleur (aka Eldy)]

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 <address@hidden>:

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

address@hidden

2015-01-04 19:22 GMT+01:00 Destailleur Laurent <address@hidden>:

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 <address@hidden>:
> 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
>
> address@hidden
>
>
> 2014-12-28 17:59 GMT+01:00 Marcos García <address@hidden>:
>>
>> 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
>>
>> address@hidden
>>
>>
>> 2014-12-27 1:12 GMT+01:00 Destailleur Laurent <address@hidden>:
>>>
>>> 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 <address@hidden>:
>>> > 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
>>> >
>>> > address@hidden
>>> >
>>> >
>>> > _______________________________________________
>>> > Dolibarr-dev mailing list
>>> > address@hidden
>>> > 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
>>> address@hidden
>>> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>>
>>
>
>
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> 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
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev

_______________________________________________
Dolibarr-dev mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev