Bug #803


Party entry and edit -- design / evaluate /connect and implement form

Added by Michael Lee over 21 years ago. Updated about 19 years ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:



Related issues

Is duplicate of VegBank - Bug #784: [863] Party entry and edit -- design:reviewResolvedRobert Peet11/13/2002

Actions #1

Updated by Gabriel Farrell over 23 years ago

This is fixed

Actions #2

Updated by John Harris over 21 years ago

Bugs the require new feature to allow vb users to add information to the plots
database directly -- ie, not via adding a plot.

Actions #3

Updated by Michael Lee over 21 years ago

This is a more commonly used bit of data that users will want to add outside of
a plot. Also somewhat simple in implementation -- simple form linked to one or
two tables. (A bit more for community -- but this functionality is quite
central to what we're working on.)

Actions #4

Updated by Michael Lee almost 21 years ago

current form development from MTL can be viewed at:

Actions #5

Updated by Michael Lee almost 21 years ago

Bob please evaluate the party forms on tekka in mtl's webspace as listed in
above comment and pass this bug to Gabe when/if you are satisfied with the
design of the form. If it needs revision, pass the bug back to michael

Actions #6

Updated by Robert Peet almost 21 years ago

Comments on the draft new “Party Form”

Make field names closer to real English rather than being exactly equal to the
field names. Capitalize each.

salutation --> Salutation
givenName --> First name
middleName --> Middle name/initial
surname --> Last name
organizationName --> Organization
contactInstructions --> Contact Instructions

Make similar changes for the other fields.

Remove the option for owner. The owner is the registered user who creates the
party until the system administrator changes this.

Of course, Gabe will need to implement the permissions function that restricts
editing to the owner.

Let’s not require phone number

The line immediately after the add button needs some rewriting.

The click here for data dictionary is confusing because the user is not
directed to a specific table, and it is less than intuitive that three tables
must be examined. I suppose we should list all three and provide hotlinks to

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

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: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
both places.

Actions #7

Updated by Michael Lee almost 21 years ago

  • Bug 784 has been marked as a duplicate of this bug. ***
Actions #8

Updated by Michael Lee almost 21 years ago

Is now the new form that has renamed field labels, more explanations, hot-links
to datadictionary fields.

The other comments from Bob deal with a different bug, so I will copy them and
add them to bug 852. Starting with "We need some business rules here:"

If the form is good as is, then this bug should be passed to gabe for

Actions #9

Updated by Robert Peet almost 21 years ago

The proposed form looks good, except that you need a pulldown menu for the
alternate identifier type.

Actions #10

Updated by Michael Lee almost 21 years ago

Alternate identifier type ? Is this the system? This is not a closed list, but
rather a system URL that the user owns that can uniquely identify the system
(always). See the data dictionary:
Identifier is also not a closed list, as the user will select any name they want
for that.

Am I missing something? If it's good as is, then it should be passed to gabe
for implementation.

Actions #11

Updated by Robert Peet almost 21 years ago

Not sure what notes 8 & 9 refer to. ALternative identifier comments probably
pertain to the reference form rather than the party form, and in that case I
agree with Mike's assessment as to how they work, but there is still a
compelling need for the user of the reference form to be able to select from
alternatiav identifier types already in the system (or to add a new one).
Mike, perhaps you can shift this note over to the reference form bug, and then
forward the party form to Gabe for implementation.

Actions #12

Updated by Michael Lee almost 21 years ago

Party form seems ready to go. Other comments are about the reference form.

Actions #13

Updated by Michael Lee about 19 years ago

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

Actions #14

Updated by Redmine Admin about 11 years ago

Original Bugzilla ID was 803


Also available in: Atom PDF