ideas for names redesign
| Affects | Status | Importance | Assigned to | Milestone | |
|---|---|---|---|---|---|
| Gratian |
New
|
Low
|
Unassigned | ||
Bug Description
Attached doccument from teffania regarding ideas about name redesign and cases of name types that actually occur. Not quite finished, but good enough to give ideas. not quite knowing what she was doing either, so please forgive silly ideas, and just appreciate any good ones.
this probably should be in the blueprints area, but the silly thing insists on everything being stored offsite.
Conversation with bat, edited highlights:
*majority of names are located in a large table and tagged with attribute
*Bat: primary SCA and primary mundane go in the canon_person table, for speed of look-up. The canon_former table will hold everything else.
*Bat: suppose I decided to change my SCA name to Karl Faustus, but hadn't gotten around to it yet. I'd have sca name = Karl Faustus, mundane = Paul Sleigh, registered = Karl Faustus von Aachen, nickname = Eric the Fruitbat, former name = Eric of Tobar Mhuire, former name = Eric of Tobermory.
*Where Gratian just has a list of former names now, it would become a list with attribute labels.
*You could have any number of some of them (eg a woman who has been married twice and changed her name both times would have two former mundane names).
*possible attributes:
Here's a list:
former mundane name
current alias or nickname
registered name
former registered name
device
badge
blog
Facebook
email
website
former name (no longer used), alternate name (eg alternate persona, persona nicknames), former mundane name, registered name, former registered name (officially changed), misspellings (found on official documentation)...
*mispellt name
Bat: Why do we need to track misspellings? Better to just kill them on sight, surely?
Teffania: because when I audit old records, I want to know it was the same person. and be able to search for them. (old mispellt records) (but not shown in canonlore)
*Teffania: re pictures and stuff - too much data entry. I'm barely keeping up with the amount of data entry i need to do from fix me's. Which comes back to not enough gratian enabled helpers which comes back to1) ease of installation, where the problems now seem to be with wampserver and 2) not enough pedant's who aren't already busy.
Bat: Yes, it's the sort of feature I can put in now and leave dormant. When (if) you ever get enough helpers, then they can go wild with it. There are always features like that, disabled for lack of time.
Teffania: built capability for them in if you like, but with firm instructions not to unleash it in canonlore so no-one knows about it until a canon is willing to take it on as a project. contact adresses are generally ephemeral. pics would be nice, but initially create a big workload on implementation, and then create a slow trickle of later increased workload. I worry about finding later canons who can cope with the work. And finding pedants who can delegate - not easy.
Bat: This is one of those features that are easier to do all in one go then disable, rather than just building part of it.
*We're basically just talking a big list of key-value pairs. Easy to implement, easy to use.
Every one would be handled slightly differently in CL, but in Gratian they'd all be dead easy to edit.
* http://
Teffania other ideas not clarified in conversation:
*Having primary sca and mundane name seperate for quicker searchign sounds good, but there would be a certain flexibility if the primary name could be selected from the list of attribues, so that when we find out one of the names was incorrect, and one of the presumed mispelligs is actually the correct one, she can jsut change the attribute. So she suggests the primary mundane and sca names at least visually to the user remain in the attribute list, so the user can just select a different attribute to change them to a different name type. It's probably a good idea to have a read only display of primary names in bold seperate from the attribute list.
*Teffania suggested mulitple attributes because there are some convoluted combinations of attributes, and do you really want to create an attribute tag for each? eg alternate registered name (mispelt registered name is even an option- that's why they publish errarta- but I think we can delete those)
*If you really want to later program in an O&A checking function on names marked as registered names, that wouldn't be a bad thing. But it would be a low down on the wishlist thing. (stage 2 of the project) Perhaps it would be good as a soft verification tool - ie it either gives an ignorable error message when you enter a name as registered that can't be found in the O&A (rememebr it has occasioal errors, so not a hard rule), or there is a verification report that lists people whose registered name doesn't match the O&A that can be run occasionally. note so many names have special characters in them - O&A checker would either have to discard them or find a version of wildcard replace that works or something like that.
see also related: https:/
(note teffania has started data colection of registered names, former names, alternate names, devices, alternate devices, badges. She does wish for each to be verified by addition of the date and kingdom text.)
| Paul Harrison (paul-francis-harrison) wrote | #1 |
| Changed in gratian: | |
| importance: | Undecided → Medium |
| Eric TF Bat (bat-flurf) wrote | #2 |
| Teffania (teffania) wrote | #3 |
| Changed in gratian: | |
| importance: | Medium → Low |
I would recommend not worrying about performance unless it becomes an issue.
I like the idea of multiple attributes.
As I understand this, we are talking about two tables, people and names. Each name entry has a field, person_id, allowing a person to have multiple names. If each person entry had a primary_name_id field the primary name would be guaranteed unique, and the SQL would be fairly painless.
Not so keen on using this system for device, badge, blog, email, facebook. This is straying too far toward the Inner-Platform antipattern. For things that will not be displayed on the website, a freeform text field should suffice. Even for things that will be displayed on a the website, a freeform blurb is worth considering. Failing this, fields in the person table.