peterwebster / henson

Master data store for the Hensley Henson Journals project, and issue tracker. The application code is kept elsewhere.
1 stars 1 forks source link

Manual edit of lists of journal pages shown on (mostly) person pages #256

Open peterwebster opened 3 years ago

peterwebster commented 3 years ago

There is an edge case where (in the repo GUI), project staff need to alter XML to correct an annotation: eg. in journal entry 1 Sep 1917 (17-09-01), changing an annotation from person123 to person456. This can be executed now.

However, person 123 and person456 both have their own pages (people/person123 etc) in which there are lists of the XML journal pages on they are mentioned. The 'Rescan All XML' function adds a link to file 17-09-01 at people/person456. However, it does not remove the now incorrect link at people/person123.

So the requirement is for a means to edit that list direct from people/person123/edit to remove the connection with file 17-09-01

peterwebster commented 3 years ago

@ojlyytinen for information, but not action just yet. Connects with #254 although I think that this issue is not solved by amending the Rescan All XML function.

Lots of examples at (closed) #245

peterwebster commented 2 years ago

Option 1 is an on-demand rescan triggered from the annotation view person/pers123: ie. the app checks for XML files (or perhaps the Solr?) for markup referring to person123, adds any it finds are not already connected to pers123, and also (having done that) deletes any connections between person123 and journal entries that no longer exist.

Option 2 is from "the other end". At the same time as performing the new process in #263 (on saving edits to a journal entry) the application checks all persons/places etc for connections to the newly edited journal entry, checks that list against the current state of the XML markup, and deletes from person/place if a previously created connection is now no longer correct.

The third (and most difficult) is a direct editing function in the GUI at the person/pers123 page, so this is least favoured now.

peterwebster commented 2 years ago

One to fix, if and when this enhancement can be made: https://github.com/peterwebster/henson/issues/263#issuecomment-1149907172

alisonrclarke commented 2 years ago

Given the changes made to #263 I've gone for option 2: saving or rescanning a journal entry should now check for unused person references and remove them.

peterwebster commented 2 years ago

One to fix, if and when this enhancement can be made: #263 (comment)

@dpl0js a new fix by @alisonrclarke now means that, if one opens and then saves a journal entry, the application checks all the markup in that entry, adds connections to person/org/ref page if they are new, and also removes those that are no longer in the XML. eg. I opened and saved https://henson.durham.ac.uk/journals/22-06-18, as you did yesterday. Your new markup for James Barrie is still there, and so is the item in the list for Barrie at https://henson.durham.ac.uk/people/person5449

Now, however, 18 June 1922 has also disappeared from James Meston's list at https://henson.durham.ac.uk/people/person5458

I shall continue to test these, but this is what we wanted, I think.

peterwebster commented 2 years ago

@dpl0js @alisonrclarke I've now tested several more of these, which were the leftovers of previous amendments that Hilary listed for me. I've been able successfully to deal with them, so I now think this works well.

NB. Alison had time to do this for people and refs. Having run out of time, I agreed that we would not implement the fix for places or organisations, since they are (largely) unused now. We can add new orgs and places, but not remove old ones, so care is needed when adding new ones, as mistakes are hard to reverse. (Easy in the XML, not possible in the bullet lists, without asking David to intervene directly in the data.)

dpl0js commented 2 years ago

@alisonrclarke @peterwebster Thanks so much to you both. This is grand. I will take the greatest of care with orgs and places, should they ever be necessary.