***UNCHECKED*** Marital Status not managed properly in Person entity

[Suraj Khurana-2]

Hello,

Currently, *maritalStatus* is managed as an indicator (Y/N) in *Person*
entity. I think we can enhance it and make it derived from *Enumeration*
pattern.

*Classification of legal marital status*

   - 1 - Married (and not separated) ...
   - 2 - Widowed (including living common law) ...
   - 3 - Separated (and not Divorced) ...
   - 4 - Divorced (including living common law) ...
   - 5 - Single (including living common law)

Please share your thoughts.

--
Best regards,
Suraj Khurana
TECHNICAL CONSULTANT
mobile: [phone]
email: [hidden email]
*www.hotwax.co <http://www.hotwax.co/>*

[Jacques Le Roux]

+1

Jacques

Le 09/04/2019 à 09:20, Suraj Khurana a écrit :

> Hello,
>
> Currently, *maritalStatus* is managed as an indicator (Y/N) in *Person*
> entity. I think we can enhance it and make it derived from *Enumeration*
> pattern.
>
> *Classification of legal marital status*
>
>     - 1 - Married (and not separated) ...
>     - 2 - Widowed (including living common law) ...
>     - 3 - Separated (and not Divorced) ...
>     - 4 - Divorced (including living common law) ...
>     - 5 - Single (including living common law)
>
> Please share your thoughts.
>
> --
> Best regards,
> Suraj Khurana
> TECHNICAL CONSULTANT
> mobile: [phone]
> email: [hidden email]
> *www.hotwax.co <http://www.hotwax.co/>*
>

[Swapnil M Mane]

+1


- Best Regards,
Swapnil M Mane,
ofbiz.apache.org



On Tue, Apr 9, 2019 at 12:51 PM Suraj Khurana <[hidden email]>
wrote:

> Hello,
>
> Currently, *maritalStatus* is managed as an indicator (Y/N) in *Person*
> entity. I think we can enhance it and make it derived from *Enumeration*
> pattern.
>
> *Classification of legal marital status*
>
>    - 1 - Married (and not separated) ...
>    - 2 - Widowed (including living common law) ...
>    - 3 - Separated (and not Divorced) ...
>    - 4 - Divorced (including living common law) ...
>    - 5 - Single (including living common law)
>
> Please share your thoughts.
>
> --
> Best regards,
> Suraj Khurana
> TECHNICAL CONSULTANT
> mobile: [phone]
> email: [hidden email]
> *www.hotwax.co <http://www.hotwax.co/>*
>

[adityasharma]

+1

Best Regards,
Aditya Sharma,
http://ofbiz.apache.org


On Tue, Apr 9, 2019 at 1:09 PM Swapnil M Mane <[hidden email]>
wrote:

> +1
>
>
> - Best Regards,
> Swapnil M Mane,
> ofbiz.apache.org
>
>
>
> On Tue, Apr 9, 2019 at 12:51 PM Suraj Khurana <[hidden email]>
> wrote:
>
> > Hello,
> >
> > Currently, *maritalStatus* is managed as an indicator (Y/N) in *Person*
> > entity. I think we can enhance it and make it derived from *Enumeration*
> > pattern.
> >
> > *Classification of legal marital status*
> >
> >    - 1 - Married (and not separated) ...
> >    - 2 - Widowed (including living common law) ...
> >    - 3 - Separated (and not Divorced) ...
> >    - 4 - Divorced (including living common law) ...
> >    - 5 - Single (including living common law)
> >
> > Please share your thoughts.
> >
> > --
> > Best regards,
> > Suraj Khurana
> > TECHNICAL CONSULTANT
> > mobile: [phone]
> > email: [hidden email]
> > *www.hotwax.co <http://www.hotwax.co/>*
> >
>

[Pierre Smits-3]

Although I am inclined to agree with having the options come from
appropriate records/values in the Enumeration entity, I must caution about
how the final solution will be implemented in our code base. We all know
that this falls in the category of sensitive data which has come under a
tighter scrutiny due to GDPR and security breaches.

Such privacy sensitive element should be implemented in tighter permissions
applied than we generally apply to screens/forms/fields etc.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Tue, Apr 9, 2019 at 10:19 AM Aditya Sharma <[hidden email]>
wrote:

> +1
>
> Best Regards,
> Aditya Sharma,
> http://ofbiz.apache.org
>
>
> On Tue, Apr 9, 2019 at 1:09 PM Swapnil M Mane <[hidden email]>
> wrote:
>
> > +1
> >
> >
> > - Best Regards,
> > Swapnil M Mane,
> > ofbiz.apache.org
> >
> >
> >
> > On Tue, Apr 9, 2019 at 12:51 PM Suraj Khurana <[hidden email]>
> > wrote:
> >
> > > Hello,
> > >
> > > Currently, *maritalStatus* is managed as an indicator (Y/N) in *Person*
> > > entity. I think we can enhance it and make it derived from
> *Enumeration*
> > > pattern.
> > >
> > > *Classification of legal marital status*
> > >
> > >    - 1 - Married (and not separated) ...
> > >    - 2 - Widowed (including living common law) ...
> > >    - 3 - Separated (and not Divorced) ...
> > >    - 4 - Divorced (including living common law) ...
> > >    - 5 - Single (including living common law)
> > >
> > > Please share your thoughts.
> > >
> > > --
> > > Best regards,
> > > Suraj Khurana
> > > TECHNICAL CONSULTANT
> > > mobile: [phone]
> > > email: [hidden email]
> > > *www.hotwax.co <http://www.hotwax.co/>*
> > >
> >
>

[Suraj Khurana-2]

+1.

Technically, as per Pierre, we should also mark this field as encrypted in
the entity definition.

--
Best Regards,
Suraj Khurana
TECHNICAL CONSULTANT
mobile: [phone]
email: [hidden email]
*www.hotwax.co <http://www.hotwax.co/>*






On Tue, Apr 9, 2019 at 2:08 PM Pierre Smits <[hidden email]> wrote:

> Although I am inclined to agree with having the options come from
> appropriate records/values in the Enumeration entity, I must caution about
> how the final solution will be implemented in our code base. We all know
> that this falls in the category of sensitive data which has come under a
> tighter scrutiny due to GDPR and security breaches.
>
> Such privacy sensitive element should be implemented in tighter permissions
> applied than we generally apply to screens/forms/fields etc.
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Tue, Apr 9, 2019 at 10:19 AM Aditya Sharma <[hidden email]>
> wrote:
>
> > +1
> >
> > Best Regards,
> > Aditya Sharma,
> > http://ofbiz.apache.org
> >
> >
> > On Tue, Apr 9, 2019 at 1:09 PM Swapnil M Mane <[hidden email]>
> > wrote:
> >
> > > +1
> > >
> > >
> > > - Best Regards,
> > > Swapnil M Mane,
> > > ofbiz.apache.org
> > >
> > >
> > >
> > > On Tue, Apr 9, 2019 at 12:51 PM Suraj Khurana <[hidden email]
> >
> > > wrote:
> > >
> > > > Hello,
> > > >
> > > > Currently, *maritalStatus* is managed as an indicator (Y/N) in
> *Person*
> > > > entity. I think we can enhance it and make it derived from
> > *Enumeration*
> > > > pattern.
> > > >
> > > > *Classification of legal marital status*
> > > >
> > > >    - 1 - Married (and not separated) ...
> > > >    - 2 - Widowed (including living common law) ...
> > > >    - 3 - Separated (and not Divorced) ...
> > > >    - 4 - Divorced (including living common law) ...
> > > >    - 5 - Single (including living common law)
> > > >
> > > > Please share your thoughts.
> > > >
> > > > --
> > > > Best regards,
> > > > Suraj Khurana
> > > > TECHNICAL CONSULTANT
> > > > mobile: [phone]
> > > > email: [hidden email]
> > > > *www.hotwax.co <http://www.hotwax.co/>*
> > > >
> > >
> >
>

[Jacques Le Roux]

+1

Jacques

Le 09/04/2019 à 10:59, Suraj Khurana a écrit :

> +1.
>
> Technically, as per Pierre, we should also mark this field as encrypted in
> the entity definition.
>
> --
> Best Regards,
> Suraj Khurana
> TECHNICAL CONSULTANT
> mobile: [phone]
> email: [hidden email]
> *www.hotwax.co <http://www.hotwax.co/>*
>
>
>
>
>
>
> On Tue, Apr 9, 2019 at 2:08 PM Pierre Smits <[hidden email]> wrote:
>
>> Although I am inclined to agree with having the options come from
>> appropriate records/values in the Enumeration entity, I must caution about
>> how the final solution will be implemented in our code base. We all know
>> that this falls in the category of sensitive data which has come under a
>> tighter scrutiny due to GDPR and security breaches.
>>
>> Such privacy sensitive element should be implemented in tighter permissions
>> applied than we generally apply to screens/forms/fields etc.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
>> *Apache Directory <https://directory.apache.org>, PMC Member*
>> Apache Incubator <https://incubator.apache.org>, committer
>> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
>> since 2008*
>> Apache Steve <https://steve.apache.org>, committer
>>
>>
>> On Tue, Apr 9, 2019 at 10:19 AM Aditya Sharma <[hidden email]>
>> wrote:
>>
>>> +1
>>>
>>> Best Regards,
>>> Aditya Sharma,
>>> http://ofbiz.apache.org
>>>
>>>
>>> On Tue, Apr 9, 2019 at 1:09 PM Swapnil M Mane <[hidden email]>
>>> wrote:
>>>
>>>> +1
>>>>
>>>>
>>>> - Best Regards,
>>>> Swapnil M Mane,
>>>> ofbiz.apache.org
>>>>
>>>>
>>>>
>>>> On Tue, Apr 9, 2019 at 12:51 PM Suraj Khurana <[hidden email]
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Currently, *maritalStatus* is managed as an indicator (Y/N) in
>> *Person*
>>>>> entity. I think we can enhance it and make it derived from
>>> *Enumeration*
>>>>> pattern.
>>>>>
>>>>> *Classification of legal marital status*
>>>>>
>>>>>     - 1 - Married (and not separated) ...
>>>>>     - 2 - Widowed (including living common law) ...
>>>>>     - 3 - Separated (and not Divorced) ...
>>>>>     - 4 - Divorced (including living common law) ...
>>>>>     - 5 - Single (including living common law)
>>>>>
>>>>> Please share your thoughts.
>>>>>
>>>>> --
>>>>> Best regards,
>>>>> Suraj Khurana
>>>>> TECHNICAL CONSULTANT
>>>>> mobile: [phone]
>>>>> email: [hidden email]
>>>>> *www.hotwax.co <http://www.hotwax.co/>*
>>>>>

[Rishi Solanki]

+1.

Best Regards,
--
*Rishi Solanki* | Sr Manager, Enterprise Software Development
HotWax Systems <http://www.hotwaxsystems.com/>
Plot no. 80, Scheme no. 78 Part 2, Near Brilliant Convention Center, Indore,
M.P 452010
Linkedin: *Rishi Solanki*
<https://www.linkedin.com/in/rishi-solanki-62271b7/>
Direct: [phone]


On Tue, Apr 9, 2019 at 4:46 PM Jacques Le Roux <[hidden email]>
wrote:

> +1
>
> Jacques
>
> Le 09/04/2019 à 10:59, Suraj Khurana a écrit :
> > +1.
> >
> > Technically, as per Pierre, we should also mark this field as encrypted
> in
> > the entity definition.
> >
> > --
> > Best Regards,
> > Suraj Khurana
> > TECHNICAL CONSULTANT
> > mobile: [phone]
> > email: [hidden email]
> > *www.hotwax.co <http://www.hotwax.co/>*
> >
> >
> >
> >
> >
> >
> > On Tue, Apr 9, 2019 at 2:08 PM Pierre Smits <[hidden email]>
> wrote:
> >
> >> Although I am inclined to agree with having the options come from
> >> appropriate records/values in the Enumeration entity, I must caution
> about
> >> how the final solution will be implemented in our code base. We all know
> >> that this falls in the category of sensitive data which has come under a
> >> tighter scrutiny due to GDPR and security breaches.
> >>
> >> Such privacy sensitive element should be implemented in tighter
> permissions
> >> applied than we generally apply to screens/forms/fields etc.
> >>
> >> Best regards,
> >>
> >> Pierre Smits
> >>
> >> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> >> *Apache Directory <https://directory.apache.org>, PMC Member*
> >> Apache Incubator <https://incubator.apache.org>, committer
> >> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without
> privileges)
> >> since 2008*
> >> Apache Steve <https://steve.apache.org>, committer
> >>
> >>
> >> On Tue, Apr 9, 2019 at 10:19 AM Aditya Sharma <[hidden email]>
> >> wrote:
> >>
> >>> +1
> >>>
> >>> Best Regards,
> >>> Aditya Sharma,
> >>> http://ofbiz.apache.org
> >>>
> >>>
> >>> On Tue, Apr 9, 2019 at 1:09 PM Swapnil M Mane <[hidden email]
> >
> >>> wrote:
> >>>
> >>>> +1
> >>>>
> >>>>
> >>>> - Best Regards,
> >>>> Swapnil M Mane,
> >>>> ofbiz.apache.org
> >>>>
> >>>>
> >>>>
> >>>> On Tue, Apr 9, 2019 at 12:51 PM Suraj Khurana <
> [hidden email]
> >>>> wrote:
> >>>>
> >>>>> Hello,
> >>>>>
> >>>>> Currently, *maritalStatus* is managed as an indicator (Y/N) in
> >> *Person*
> >>>>> entity. I think we can enhance it and make it derived from
> >>> *Enumeration*
> >>>>> pattern.
> >>>>>
> >>>>> *Classification of legal marital status*
> >>>>>
> >>>>>     - 1 - Married (and not separated) ...
> >>>>>     - 2 - Widowed (including living common law) ...
> >>>>>     - 3 - Separated (and not Divorced) ...
> >>>>>     - 4 - Divorced (including living common law) ...
> >>>>>     - 5 - Single (including living common law)
> >>>>>
> >>>>> Please share your thoughts.
> >>>>>
> >>>>> --
> >>>>> Best regards,
> >>>>> Suraj Khurana
> >>>>> TECHNICAL CONSULTANT
> >>>>> mobile: [phone]
> >>>>> email: [hidden email]
> >>>>> *www.hotwax.co <http://www.hotwax.co/>*
> >>>>>
>

[Nicolas Malin-2]

All information on Person are sensitive in terms of personal privacy :)
, but I'm not against limit the access.

Enumeration is a good step to improve the poor maritalStatus, personally
I'm more in favor to use a party classification if you want to know the
lifespan of each state. The next level would be be use PartyRelationship
to determinate the marital status ... but it's a high level ^^

Nicolas

On 09/04/2019 10:37, Pierre Smits wrote:

> Although I am inclined to agree with having the options come from
> appropriate records/values in the Enumeration entity, I must caution about
> how the final solution will be implemented in our code base. We all know
> that this falls in the category of sensitive data which has come under a
> tighter scrutiny due to GDPR and security breaches.
>
> Such privacy sensitive element should be implemented in tighter permissions
> applied than we generally apply to screens/forms/fields etc.
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Tue, Apr 9, 2019 at 10:19 AM Aditya Sharma <[hidden email]>
> wrote:
>
>> +1
>>
>> Best Regards,
>> Aditya Sharma,
>> http://ofbiz.apache.org
>>
>>
>> On Tue, Apr 9, 2019 at 1:09 PM Swapnil M Mane <[hidden email]>
>> wrote:
>>
>>> +1
>>>
>>>
>>> - Best Regards,
>>> Swapnil M Mane,
>>> ofbiz.apache.org
>>>
>>>
>>>
>>> On Tue, Apr 9, 2019 at 12:51 PM Suraj Khurana <[hidden email]>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> Currently, *maritalStatus* is managed as an indicator (Y/N) in *Person*
>>>> entity. I think we can enhance it and make it derived from
>> *Enumeration*
>>>> pattern.
>>>>
>>>> *Classification of legal marital status*
>>>>
>>>>     - 1 - Married (and not separated) ...
>>>>     - 2 - Widowed (including living common law) ...
>>>>     - 3 - Separated (and not Divorced) ...
>>>>     - 4 - Divorced (including living common law) ...
>>>>     - 5 - Single (including living common law)
>>>>
>>>> Please share your thoughts.
>>>>
>>>> --
>>>> Best regards,
>>>> Suraj Khurana
>>>> TECHNICAL CONSULTANT
>>>> mobile: [phone]
>>>> email: [hidden email]
>>>> *www.hotwax.co <http://www.hotwax.co/>*
>>>>

[Jacques Le Roux]

Le 09/04/2019 à 14:08, Nicolas Malin a écrit :
> personally I'm more in favor to use a party classification if you want to know the lifespan of each state.
+1, but needs more work...

Jacques

[Pierre Smits-3]

Lifespan settings on certain entity types is something this community does
not care about that deeply. I tried that once.

Best regards,

Pierre Smits

*Apache Trafodion <https://trafodion.apache.org>, Vice President*
*Apache Directory <https://directory.apache.org>, PMC Member*
Apache Incubator <https://incubator.apache.org>, committer
*Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
since 2008*
Apache Steve <https://steve.apache.org>, committer


On Tue, Apr 9, 2019 at 3:10 PM Jacques Le Roux <[hidden email]>
wrote:

> Le 09/04/2019 à 14:08, Nicolas Malin a écrit :
> > personally I'm more in favor to use a party classification if you want
> to know the lifespan of each state.
> +1, but needs more work...
>
> Jacques
>
>

[Devanshu Vyas-2]

+1

Thanks & Regards,
Devanshu Vyas.


On Tue, Apr 9, 2019 at 12:51 PM Suraj Khurana <[hidden email]>
wrote:

> Hello,
>
> Currently, *maritalStatus* is managed as an indicator (Y/N) in *Person*
> entity. I think we can enhance it and make it derived from *Enumeration*
> pattern.
>
> *Classification of legal marital status*
>
>    - 1 - Married (and not separated) ...
>    - 2 - Widowed (including living common law) ...
>    - 3 - Separated (and not Divorced) ...
>    - 4 - Divorced (including living common law) ...
>    - 5 - Single (including living common law)
>
> Please share your thoughts.
>
> --
> Best regards,
> Suraj Khurana
> TECHNICAL CONSULTANT
> mobile: [phone]
> email: [hidden email]
> *www.hotwax.co <http://www.hotwax.co/>*
>

[Suraj Khurana-2]

Thanks, everyone for your inputs.

Nicolas,
Yes, we can manage things with PartyClassification to maintain time span of
it as well, it brings some complexities to handle now, as a party can be in
multiple classifications on the same time, etc etc, maintaining
PartyRelationship is a high-level idea, I liked it :)

Currently, I think we can go with managing the *current* marital status of
the party, as we all have experienced during surfing the web, which can be
achieved by Enumeration thing.

--
Best Regards,
Suraj Khurana
TECHNICAL CONSULTANT
mobile: [phone]
email: [hidden email]
*www.hotwax.co <http://www.hotwax.co/>*






On Wed, Apr 10, 2019 at 11:54 AM Devanshu Vyas <[hidden email]>
wrote:

> +1
>
> Thanks & Regards,
> Devanshu Vyas.
>
>
> On Tue, Apr 9, 2019 at 12:51 PM Suraj Khurana <[hidden email]>
> wrote:
>
>> Hello,
>>
>> Currently, *maritalStatus* is managed as an indicator (Y/N) in *Person*
>> entity. I think we can enhance it and make it derived from *Enumeration*
>> pattern.
>>
>> *Classification of legal marital status*
>>
>>    - 1 - Married (and not separated) ...
>>    - 2 - Widowed (including living common law) ...
>>    - 3 - Separated (and not Divorced) ...
>>    - 4 - Divorced (including living common law) ...
>>    - 5 - Single (including living common law)
>>
>> Please share your thoughts.
>>
>> --
>> Best regards,
>> Suraj Khurana
>> TECHNICAL CONSULTANT
>> mobile: [phone]
>> email: [hidden email]
>> *www.hotwax.co <http://www.hotwax.co/>*
>>
>

[Suraj Khurana-2]

Hello,

I have created a ticket here
<https://issues.apache.org/jira/browse/OFBIZ-10921>.

--
Best Regards,
Suraj Khurana
TECHNICAL CONSULTANT
mobile: [phone]
email: [hidden email]
www.hotwax.co






On Thu, Apr 11, 2019 at 6:14 PM Suraj Khurana <[hidden email]>
wrote:

> Thanks, everyone for your inputs.
>
> Nicolas,
> Yes, we can manage things with PartyClassification to maintain time span
> of it as well, it brings some complexities to handle now, as a party can be
> in multiple classifications on the same time, etc etc, maintaining
> PartyRelationship is a high-level idea, I liked it :)
>
> Currently, I think we can go with managing the *current* marital status
> of the party, as we all have experienced during surfing the web, which can
> be achieved by Enumeration thing.
>
> --
> Best Regards,
> Suraj Khurana
> TECHNICAL CONSULTANT
> mobile: [phone]
> email: [hidden email]
> *www.hotwax.co <http://www.hotwax.co/>*
>
>
>
>
>
>
> On Wed, Apr 10, 2019 at 11:54 AM Devanshu Vyas <[hidden email]>
> wrote:
>
>> +1
>>
>> Thanks & Regards,
>> Devanshu Vyas.
>>
>>
>> On Tue, Apr 9, 2019 at 12:51 PM Suraj Khurana <[hidden email]>
>> wrote:
>>
>>> Hello,
>>>
>>> Currently, *maritalStatus* is managed as an indicator (Y/N) in *Person*
>>> entity. I think we can enhance it and make it derived from *Enumeration*
>>> pattern.
>>>
>>> *Classification of legal marital status*
>>>
>>>    - 1 - Married (and not separated) ...
>>>    - 2 - Widowed (including living common law) ...
>>>    - 3 - Separated (and not Divorced) ...
>>>    - 4 - Divorced (including living common law) ...
>>>    - 5 - Single (including living common law)
>>>
>>> Please share your thoughts.
>>>
>>> --
>>> Best regards,
>>> Suraj Khurana
>>> TECHNICAL CONSULTANT
>>> mobile: [phone]
>>> email: [hidden email]
>>> *www.hotwax.co <http://www.hotwax.co/>*
>>>
>>

[Suraj Khurana-2]

Hello,

Here <https://issues.apache.org/jira/browse/OFBIZ-10921> is the Jira ticket
for this improvement.

--
Best Regards,
Suraj Khurana
Technical Consultant






On Tue, Apr 9, 2019 at 7:34 PM Pierre Smits <[hidden email]> wrote:

> Lifespan settings on certain entity types is something this community does
> not care about that deeply. I tried that once.
>
> Best regards,
>
> Pierre Smits
>
> *Apache Trafodion <https://trafodion.apache.org>, Vice President*
> *Apache Directory <https://directory.apache.org>, PMC Member*
> Apache Incubator <https://incubator.apache.org>, committer
> *Apache OFBiz <https://ofbiz.apache.org>, contributor (without privileges)
> since 2008*
> Apache Steve <https://steve.apache.org>, committer
>
>
> On Tue, Apr 9, 2019 at 3:10 PM Jacques Le Roux <
> [hidden email]>
> wrote:
>
> > Le 09/04/2019 à 14:08, Nicolas Malin a écrit :
> > > personally I'm more in favor to use a party classification if you want
> > to know the lifespan of each state.
> > +1, but needs more work...
> >
> > Jacques
> >
> >
>