[Kolab-devel] Adding features to kolab2.schema

[Gunnar Wrobel]

Quoting Bernhard Reiter <bernhard at intevation.de>:

> Am Donnerstag, 26. Februar 2009 12:50:46 schrieb Martin Konold:
>> In general I would like to hear your opinion about the proposed change.
>
> There is a notion when dealing with data privacy and this is that  
> forms should
> be as simple as possible. The problem with many empty slots is that there are
> some sort of people that will try to fill all values in. So an empty slot
> for dateOfBirth, placeOfBirth and birthName will create entries in there in
> some case. Companies might get in trouble filling this data in germany.
> Some organisations need this like the citizen registration of the  
> muncipality.
> So I guess I am looking for the use case for some of the values.
> This is at least an argument against some of the values.
>
> Also they would clutter of the screen in web-admin.

I guess one would not necessarily need to add full support to the web  
admin immediately. The web admin does not need to be as rigid as it is  
now about the user data. If it would behave a little bit more like  
Turba from Horde does it would be easy for a sys-admin to define the  
attributes he actually wants to support. So the web admin would only  
display these.

For that it would be good to have the basic schema so that admins can  
rig their system to their needs without much hassle.

This might also make the current global address book more valuable.

Cheers,

Gunnar

>
>> Especially I would like to know if you think that the added complexity of
>> seperating legal person (like a company or a foundation) from a natural
>> person (individual) is worthwile?
>>
>> (I have my doubts because mail for a company is not so much different from
>> mail for an individual)
>
>  Ideally someone would want define relationships between objects, like
> users A,B,D are a member of company X and can be reached at subsidery M.
> I guess that many directory services are not up to this yet, they seem to be
> focussed on digital identities. Given that many companies do have a major
> email and street address, keeping one entry for both seems fine to me.
>
> For billing purposes I would propose a folder with "contact" objects  
> in Kolab.
> Still those do not represent the relationships I have mentioned above.
>
> Best,
> Bernhard
>
>
> --
> Managing Director - Owner: www.intevation.net       (Free Software Company)
> Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
> Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
> Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
>



-- 
______ http://kdab.com _______________ http://kolab-konsortium.com _

p at rdus Kolab work is funded in part by KDAB and the Kolab Konsortium

____ http://www.pardus.de _________________ http://gunnarwrobel.de _
E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                          Bundesstrasse 29
Fax    : +49 721 1513 52322                          D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digitale PGP-Unterschrift
URL: <http://lists.kolab.org/pipermail/devel/attachments/20090301/8eec791c/attachment.sig>