[OGo-Users] advanced search questions

[Adam Tauno Williams]

On Mon, 2006-12-11 at 16:45 -0200, Olivier Hallot wrote:
> Adam Tauno Williams escreveu:
> (...)
> > This ["(contactId={me})] should be *trivial* to implement,  probably
> > just WebUI stuff since -
> > #!/usr/bin/env python
> > import xmlrpclib,pprint
> > server = xmlrpclib.Server('http://adam:*********@localhost/RPC2')
> > fetchSpec = {}
> > fetchSpec['qualifier'] = "contactId = 27190"
> yes, I whish I knew how to  transform 27190 into a human-readable ogo
> account in the webUI...

I'd guess that the SkyContactSubEditor is what you want.  I'm only
learning this whole WebObjects thing but it seems like you could drop
that into the page.  SkyContactSubEditor is referenced as
"<#ContactEditor/>" in SkyPersonEditor.html to provide the little
contact selector widget.  In SkyPersonEditor.wod it looks like -

ContactEditor:      SkyContactSubEditor       { document = person; }

I wonder if you dropped it in LSWPersonAdvancedSearch.wod as something
like:
ContactEditor: SkyContactSubEditor { }
 - and referenced it in LSWPersonAdvancedSearch.html what would happen.
(?)

Probably won't work but it would be interesting.  I'd try it myself but
my test rig is currently buggered up with a different problem.

> > result = server.person.fetch(fetchSpec)
> > pprint.pprint(result)
> > - already works, so the required command logic must be completely in
> > place.
> (...)
> >> As for a search inside the contacts you own, this has been the major
> >> reason for a customer to drop OGo as they were not able to manage
> >> privacy the way users like (read: "my contacts are for me and not for
> >> you, period"). 
> > Like: "((ownerid == {me}) && (isPrivate = 1))" ?
> Yes. (ownerid={me}) was the main issue with this customer, used to
> oultook. (isPrivate = 1) was the request of the executive assistants who
> have sensitive data not  to be exposed to the rest of the enterprise.
> OGo also does not handle public & private address as well as public &
> private phone the way corporations expect. Private info should be kept
> restricted. With OGo, either you show all or you hide all. ACL for
> instance, applies to the whole record.  

Whole object, yes.  In part I think it depends on how you interpret
"private phone".  We've always taken it to mean residential phone
number.   I'm not certain what a "private" phone number would be,  if
you can see the contact record why wouldn't you be allowed to call them?

The only issue I can see with this operationally is that OGo is not
suitable for use as an HR/Payroll system as regulation in many places
require specific elements of an entry to be restricted.  Beyond that I
can't see sub-object based ACLs being used very often;  but I could be
overlooking some common application.

> One can think I am splitting
> hairs here, but believe me, privacy is a personnal security issue for
> many, many people and is taken very seriously (from inconveniences to
> threats).

There are private extended attributes.  It appears (I haven't tested)
that ACLs also apply to object properties (as in "obj_properties") as
well.

> Nevertheless, the completness of the data model in OGo makes me believe
> that such privacy issues enhancements are forseable.
> > Although this wouldn't be completely true as I believe ACLs trump the
> > privacy flag;  and I suspect ownerId == primary user is less frequently
> > true then one suspects (since owner == creator).  Using contactId seems
> > more correct.
> > <aside>"mine" is a dumb way to approach data, but I completely
> > understand what you mean.</aside>
> = selfish-ness. The Homo-Corporatus specie instinct is to "share
> nothing", as you know.

Yep.  A self-serving inclination for the Homo Corporatus, but generally
bad for the Corporation.

> >> Lesson taken: if you cannot mimick outlook, do not try to
> >> fix your user.