VegBank

No idea what this bug is?

When a person registers, this is supposed to either make certain that
there exists an appropriate party in the party table, and that when a
registered party edits his or her registration data, that updates any
necessary fields in the party table.his bug should remain until fixed or
we jointly agree we do not need it.

Bug is really divided into 2 Subparts.

Subpart 1:
Essentially, what we have here is that all new users who sign up for a VegBank
acount (i.e. a new user in the USERS database, logging in via
http://vegbank.nceas.ucsb.edu/vegbank/general/login.html or some such page) will
be added as a new record in the PARTY table (only the one party table, in the
plots module of the db). All their info that they gave the USER database should
be added to the tables: party, telephone, and address. Note that these parties
SHOULD NOT BE ADDED TO plantparty or commParty.

Subpart 2 :
When a user edits their USER information in the USER database via
http://vegbank.nceas.ucsb.edu/framework/servlet/usermanagement?action=changeusersettings
, then it would be nice to capture these changes and update their information in
the party,address, and telephone tables of VegBank.

Technical note about above revisions:
Since we are trying to maintain a perfectly archived database, the updated user
information should work like this:
1) The party table information (web: name and institution = party.surname,
partay.givenname and party.organizationName ) should be updated (if changed) and
and the appropriate old data stored in the revision table.

2) The address table information (Address, City, State, Country, Zip Code) could
work one of two ways: (Let's go with B for now for simplicity)
--A) insert a new record into address (for an address that is really new, i.e.
the person moved) and make the new record TRUE for address.currentflag and
startyDate = Now() -- then make the old record FALSE for address.currentflad
--B) update the old address record field(s) (for an address that is still the
same, only the zip code or city was spelled wrong) and insert the old data into
the revision table of VegBank.

3) The telephone table should get telephone.phoneNumber updated and the old
number inserted into revision.

4) Some parties may not have records in address or telephone. If they add an
address or telephone to their VegBank USER profile, then a new record will have
to be added to these tables. The only sticky point is the required field
telephone.phoneType, which will have to default to "Not specified"

from Bob:

1. There is the problem that there are party attributes that a user needs
to be able to update and which are not on the profile page that the user
edits. This should be added.

That is, the party table has attributes not on the "edit profile" form. We need
to either add these fields to that form, or we need to make a new form for
people to edit any party that they are the owner of.

Fields need to be added to the "edit profile" form to include:
all fields marked with a blue # on the form:
http://tekka.nceas.ucsb.edu/forms/certification.html

Comments really from Bob, on bug 803: [lee comments in brackets]
-----------------------------------------
We need some business rules here. Ownership is by a registered user. We
currently track registered users as unique by email address. We do not
require email for a party (we do not always know an email). How do we link
registered users with parties? And, how do we affect the transfer of
ownership from a second-party creator to a registered user who wants to take
over his own party?

I suggest:

1. We move to primary key as the unique identifier for a registered user so
that email is no longer the unique identifier. Upon logging in the registered
user should be able to edit his/her email address, just like other user
attributes.

[MTL - I like the idea of allowing users to change their email, provided the
email address they specify is not already on the system. Email would still be
the logon]

2. A new user when registering will create a new party by default. That user
can then send an email to the system manager requesting that one or more
extant parties be synonymized with the new party just created. This would
require that the manager reset part[y]:currentName_ID to point at the user’s
party record. This also suggests a new function needed in the management
interface.

3. We remove or minimize the redundancy between the user registration table
and the party table. We don’t want name, organization, address, etc stored in
both places.

[MTL - this also brings to mind that we currently have 4 party tables: party,
plantParty, commParty, referenceParty - perhaps simplifying to 1 would make
linking parties to parties/users more simple. And reduce redudancy.]

There is quite a lot of work here if I am to address all of your comments...

Right now I have this working without revisions, comment #4 and comment #6 issues

So do you really want the implimentation of revisions for version 1, do we want
comment #6 and comment #4 points implemented in Version 1????

At least give me a sense of priority and please stop piggybacking bugs onto
other bugs ;).

This is fixed for version one as I understand it.

Comment#6 point 1 is done but revisions, comment #4 and most of comment #6 are not.

OK, this works now. The email of the user matches party.email. For this to
always work, we will need to add all extant users to the party table. Once this
is done, we will be good to go and this bug can be marked resolved.

Party table has been manually populated from usig the user_info table of the
framework database, finishing the work need for this bug.

changed from components that are to be deleted to "misc" so that bugs don't get
deleted with component. Sorry for all the email.

Original Bugzilla ID was 852