Sync with gnome releases

[Michael Fair]

> The situation I'm trying to avoid is one where the gnucash user has set
the
> contact address to e.g.
>
> MyISP Inc.
> MailStop 1234
> 111 Main St.
> Anytown USA
>
> and the LDAP sysadmin (who has write priveleges0 looks at this and says,
> 'oh gee, my technical contact is not at M/S 1234, he's at 1235' and
changes
> the entries.  Suddenly, payments are not going the the billing dept. but
> to the technical contact!

But for those of us who want an external storage for addresses and contacts,
having non-GNUCash applications being able to read/modify the address data
is exactly the point.  In these installations, GNUCash is not the center
of our world for managing address data.  Some other application is and we
expect GNUCash to receive all updates and changes (including adding and
deleting contacts (though you may not really ever be able to delete a
contact) and handle them appropriately.

Your example is not a GNUCash problem, it's a policy problem at the
installation in question.  Also, to address the specific example you
raise (although your point is more of a data control issue), a contact
MUST have multiple addresses and contact names at each of those addresses.
Amdinistrative Address, Billing Address, Shipping Address, and Other
Address, would be the minimum requirements, and ideally should be able
to have any number of arbitrary addresses associated to a contact.

Secondarily, if the above was not enough, then the sysAdmin should have
creted a new contact called MyISP tech contact at M/S 1235.  The system
can't distinguish between a valid update and an invalid one.  Enforcing
read/write permissions is about the best it can do.  If it could do better
than that then it wouldn't need a human to type the data in to begin with.
;)

I wouldn't even think to hold GNUCash responsible if I hired a dumb
sysAdmin.  That's my problem, and the mistakes in the data of my
database are my problem.  GNUCash can do things to help me, and let
me know if some data doesn't make any sense, and I would appreciate
that, but in the end, I, as the end user installation, am solely
responsible for the accuracy of the data in the database (this of
course assumes that the applications are technically correct, which
the concerns posed above seemed to assume as well).

As I mentioned in another email, this shared backend isn't required by
all users.  It would only be desirable to business and
super-technically-savvy
end users.  I realize that GNUCash is trying to retain control over the
data for integrity purposes, and I think that it should for the single end
user and small business that does not share contact data with other
applications.
However, once the data has been outsourced to another storage architecture
that GNUCash is not the sole maintainer of, data validity is no longer
GNUCashes problem.  GNUCash can only take responsibility for its part.
It also is of course now forced to deal with the possibility of no longer
accessible data.  For instance, a customer could be deleted between the
instances of GNUCash being run and needs to be able to deal with such
"disappearances".

-- Michael --