Closed GoogleCodeExporter closed 8 years ago
* In this feature I am considering enrolment number as unique identifier for each
user. So that if in some csv file same enrolment number appears as in data
base, it
is ignored. Also, if an entry in csv file doesn't have enrolment number, it is
also
ignored.
* This code is handling name field as:
o if it has 1 word, its a first name.
o if it has 2 words, its first name & last name.
o if it has 3 words, its first, middle & last name.
o if it has 4 words, its first, middle & last name with middle name as
concatenation of 2nd and 3rd word.
* Also, If the branch and degree does not exists in the master branch table,
master degree table respectively, it adds the entry in the respective table.
Original comment by gs.bajaj
on 27 Feb 2009 at 1:21
Issue 12 has been merged into this issue.
Original comment by gs.bajaj
on 27 Feb 2009 at 1:24
1. I like the name field handling bit.
2. Not accepting duplicate enrolment numbers is OK,
but
I Strongly recommend NOT ignoring the case where there is a missing enrolment
number.
There will be many such, esp in the case of MTech and PhD students who are
already in
the V1 system, and whose data we dont have from the univ.
Original comment by animesh
on 27 Feb 2009 at 3:37
Animesh: We need a field to identify the duplicate entry. Enrolment number
seemed to
be the best option. If we have a blank enrolment number, we wont be able to
check
duplicacy. Please suggest something on it.
Original comment by gs.bajaj
on 30 Mar 2009 at 11:28
Bajaj: I know life would be much easier if we had the info we wanted, but the
reality
is not that.
I suggest the following algo:
1. If enrolment number is present, and matches one in the DB, raise duplicate
exception
2. If enrolment number is absent, check for roll number and do the same.
3. If neither enrolment number nor roll number is present, check for branch,
degree
and year. [they should be present]. In that branch,degree,and year, see if
there is a
name match. If so, raise duplicate exception
what say?
Animesh
Original comment by animesh
on 30 Mar 2009 at 11:39
But in case 3 above, if same class(same branch, degree, year) is having 2
alumni/student with same name(both: Amit Kumar) then it'll be a problem.
Original comment by gs.bajaj
on 30 Mar 2009 at 11:59
Very good point bajaj, and that is why
"raise duplicate exception" != "ignore entry completely".
One suggestion for implementing "raise duplicate exception" is to
1. create new user. keep as inactive.
2. send notification email using "authorizer" chain of command [the multi-level
thing
we use when a new person registers] saying
"There seems to be a duplicate with the name $name in $branch $year of $degree.
Of
course, two people might have the same name too, so we have created a user but
kept
it inactive. Please have a look at it, esp the email addresses provided by the
users,
and proceed to approve or delete the new user. The info is below.
$info_of_existing_user
$info_of_new_user
[here info = name and email, plus link to profile of existing user, and maybe
link to
pending profile of new user]
3. done :)
Original comment by animesh
on 30 Mar 2009 at 12:05
Thanks Animesh,
For comment 5 : step 3 this seems to be a perfect solution.
But for comment 5 : step 2 & 3 also do you mean the same steps. because you
mentioned "raise duplicate exception" != "ignore entry completely".
If thats the case please reconsider as enrolment number should be unique. Also,
roll
number should be unique for same class(same branch, degree, year).
Moreover, whatever rows are not accepted bu the system, I can write them in a
separate file with date-time based naming conventions. Admin can check the file
anytime. If you want admin can check this file in a proper format in UI also.
Original comment by gs.bajaj
on 30 Mar 2009 at 12:21
Fair points again.
1. For enrolment and roll number, lets have a "hard exception". = do not create
ID.
But still inform the authorizer.
2. For name collision, lets follow the detailed method I stated.
The admin-seeing-log file in UI idea is good. Do that.
Original comment by animesh
on 30 Mar 2009 at 12:26
Original issue reported on code.google.com by
spvi...@gmail.com
on 3 Feb 2009 at 4:17