RickMath wrote:See my post on reports & stats. Maybe this is the same problem that I am experiencing as the papers do not line up with the right user/submitting author.
I think it may be a bug worth submitting. Keep in mind that the PKP team is hard at work on version 2.3 so feedback is useful.
I have had a look at your post and the thread and it's not really the same issue. What I am talking about isn't a bug, it's more a question of the structure of the database at the planning level, something related to, but not necessarily the case here, called "normalisation" of the database. A "normalised" database tries NOT to reproduce (make redundant) information because a modification of one item (email for example) requires all instances to be modified. In the paperpresenters
table we have and entry for the email
of a paper presenter, but the person who initiated this paper also had to register to go through the process and this information was taken already through user
table. Hence it's possible to have 2 different emails, and I don't see why it's necessary to duplicate Name, Surname, email, etc. in a single database.
I understand that its possible to have paper presenters who don't actually register into the system. For example, second authors, keynotes, etc. So my question is more about the user
table, how it relates to the paperpresenter
table. It seems to me it has a very fuzzy relationship because in the end, regardless of who did or didn't register, paperpresenters
is linked through paperID
to the papers
table, and in there, we find the userID
, suggesting all paper presenters ought to have a userID
, ie., be registered.
This is what I am seeking clarification on at the moment. The LOGIC behind this a) separation of IDs and b) Duplication of personal data in the case of presenters.
(note: references to tables are in bold
, references to fields are in italics