When register, link to party & then update
RKP - Status??
#2 Updated by Michael Lee over 19 years ago
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.
#3 Updated by Michael Lee over 19 years ago
Bug is really divided into 2 Subparts.
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
, 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"
#4 Updated by Michael Lee over 19 years ago
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.
#5 Updated by Michael Lee over 19 years ago
Fields need to be added to the "edit profile" form to include:
all fields marked with a blue # on the form:
#6 Updated by Michael Lee about 19 years ago
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?
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
[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
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
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
[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.]
#7 Updated by Gabriel Farrell about 19 years ago
There is quite a lot of work here if I am to address all of your comments...
At least give me a sense of priority and please stop piggybacking bugs onto
other bugs ;).