Add Person.nr_ids to persons/creators/narrators fields

[gjost]

Enable ddr-cmdln/ddr-local to handle NRIDs in persons/creators/narrators fields

Look at e.g. http://ddrlocal.local/ui/entity/ddr-densho-16-2/

• more structured data in creators field
• less structured data in persons
• can you put more structured data in persons?
• can you add fields to creators data?

This

    "persons": [
        "Domoto, Sally",
        "Fujii, Kenji \"Kizi\""
    ],

should get automatically converted to this

    "persons": [
        {"namepart" : "Domoto, Sally"},
        {"namepart": "Fujii, Kenji \"Kizi\""}
    ]

You should then be able to add NRIDs like this

    "persons": [
        {"namepart" : "Domoto, Sally"},
        {"namepart": "Fujii, Kenji \"Kizi\"", "nr_id": "88922/nr014m435", "provisional":"true"}
    ]

sara.beckman: (Archival Team) In the names field, regardless of which style of cataloging you choose to complete, names must be written as Last name, First name “Nickname” (Maiden Name). A semi-colon must separate people. At a minimum, a last name and either a first name or nickname (without quotes) must be included in the field. If a first name or nickname is unknown, do not include in the names field, include in the description field only. (i.e. Yoda, Tats or Yoda, Tatsu are both acceptable, but just Mr. Yoda is not. If you find out that “Tats” is Tatsu’s nickname, change his name in every entry of the name field to Yoda, Tatsu “Tats”- goal is to have one name for every unique person in the database)

[gjost]

Saving nr_id to the creators field seems to work. This

nr_id:88922/nr014m435|namepart:Domoto, Sally|role:photographer;
nr_id:88922/nr014m435|namepart:Fujii, Kenji|role:writer

gets written to entity.json as this

{
    "creators": [
        {
            "namepart": "Domoto, Sally",
            "nr_id": "88922/nr014m435",
            "role": "photographer"
        },
        {
            "namepart": "Fujii, Kenji",
            "nr_id": "88922/nr014m435",
            "role": "writer"
        }
    ]
},

But loading breaks it: the nr_id values are screened out the next time the Entity is edited, looking like this in the field:

namepart:Domoto, Sally|role:photographer; namepart:Fujii, Kenji|role:writer

[gjost]

nr_id is present after Entity is loaded in the edit view:

creators | [{'namepart': 'Domoto, Sally',   'nr_id': '88922/nr014m435',   'role': 'photographer'},  {'namepart': 'Fujii, Kenji', 'nr_id': '88922/nr014m435', 'role': 'writer'}]

But it gets screened out in ddr-defs:repo_models/entity.py:formprep_creators() which calls DDR.converters.rolepeople_to_text()

[gjost]

Improvements to rolepeople parsing:

• [x] 1. Parse creators,person during form validation, before sending to Celery
• [x] 2. Print and accept spaces around formatting characters Currently: namepart:Domoto, Sally|nr_id:88922/nr014m435|role:photographer; Desired: namepart:Domoto, Sally | nr_id:88922/nr014m435 | role:photographer;
• [x] 3. Print names on separate lines by default (in the web UI) Treat newlines and semicolons interchangeably.
• [x] 4. ~~Reorder field data in forms. nr_id first for alignment, readability. nr_id:88922/nr014m435 | namepart:Domoto, Sally | role:photographer; nr_id:88922/nr014m435 | namepart:Fujii, Kenji | role:writer~~
• [x] 4. Preserve JSON file's field order when converting to text, preserve text's field order when converting to JSON.

[gjost]

Feedback:

Geoff:

1. Definitely!
2. This seems like a very good idea to me.
3. Also seems like better UI to me
4. I'll leave this to Sara's preference (or interpretation of our archivist crew's collective preference)...

Sara:

1. Validation sounds like a great idea. However - how would it deal with names that haven't been assigned an nr_id? (This will happen a lot in the creator field because we include Interviewers and Videographers in the creator fields for all our interviews) Also we don't have a role field for the person field.
2. This would be great. Easier to read and I feel like having spaces feels more natural to an archivist typing in Editor.
3. This will be great for readability in Editor
4. I'm not sure about this one. Right now the standard for our controlled vocabs with id is the term followed by the id. Having that be different for names would be weird. I think the archivist would like this to be uniform across the board.

[gjost]

Merged 314-person-nrids into develop for ddr-cmdln, ddr-local. Edits for ddr-defs remain on 314-person-nrids branch.

[gjost]

Reopening this issue. It's time to make persons a structured field like creators.

[gjost]

Pretty much done as of branch 314-person-nrids-II commit 802f748

[gjost]

Testing procedure https://gist.github.com/gjost/b63f0e94487285aec775bea275f69a73.js

[gjost]

Merged in to master branch and released as v5.8.1.