Menu

#1238 Create an Edit History page for publications

Approved
closed
None
5
2021-01-11
2018-12-26
Ahasuerus
No

Create an Edit History page for publications. From a Community Portal discussion:

"link Publication records to the submissions that originally created and subsequently modified them. We can easily do it for "New Publication" submissions because we added a "New Record ID" field to the submission table a few years ago. Linking to "Edit Publication" submissions is currently impossible because submissions do not store the IDs of the publications that they modify in a structured manner. However, it should be possible to extract them from the body of each submission and create a new field."

Discussion

  • Ahasuerus

    Ahasuerus - 2019-05-24

    Excerpted from http://www.isfdb.org/wiki/index.php/ISFDB:Community_Portal/Archive/Archive42#Queue_for_Changes_to_Verified_Pubs.3F :

    Re: "a snapshot of all OLD values". Unfortunately, it would require a significant effort. Granted, it would be easy to do for fields like "ISBN" and "Price". However, consider publishers. The way the database works, we store publisher numbers (1, 2, 3, etc) in publication records. Then, when we display a publication, we retrieve the name of the publisher, including its transliterated name(s), from other parts of the database and display them.

    This works well when displaying current data. However, suppose we were to save a verified publication record as it existed prior to submission approval. We would store publisher ID 12345 in the saved record. Then, a few months later, publishers 12345 and 12346 are merged, so publisher 12345 no longer exists in the database. When the original verifier goes back to check this pub's history, there is no publisher 12345 to display. The same thing can happen to publication series, authors and titles. Actually, it can get even more complicated with authors and titles if we want to preserve the pseudonymous/VT/series relationships as they existed at the time.

    The ultimate way to address this issue would be to build a snapshot of the then-current version of each about-to-be-changed Publication Web page and store it in a separate database location prior to submission approval. We could then have a list of snapshots for every publication and display them on demand.

    We'll need to add a warning about potentially broken links, but the textual part should be very close to what the data looked like as of the time of the edit.

    [comments about the impact of this change on disk space omitted since testing has shown it to be manageable, especially if we compress the data]

    [related comment:] We started work on a "history" system -- basically a log of changed data -- in 2007. However, we quickly ran into the problems outlined above and more. I spent many man-hours trying to get it to work in the early 2010s, but eventually had to give up because the underlying approach was flawed. Ahasuerus 18:42, 10 January 2017 (UTC)

    From a may 2019 discussion:

    ... implementing Wiki-like "version history", including the ability to revert changes, would be time-consuming and not feasible at this time.

    However, what I outlined above is more modest in scope. The filing software would simply capture the HTML version of each about-to-be-changed primary-verified publication record. It would then compress the HTML "blob" and store it in some table. Each "blob" would be linked to its publication ID and its submission ID. That way the HTML would be accessible from View Submission pages as well as from Publication pages. That shouldn't be too difficult to implement, I hope. Ahasuerus 17:00, 23 May 2019 (EDT)

     
  • Ahasuerus

    Ahasuerus - 2019-12-02
    • status: open --> open-accepted
    • assigned_to: Ahasuerus
     
  • Ahasuerus

    Ahasuerus - 2019-12-02

    Part 1 - Publication creation submissions only:

    biblio/TARGETS
    biblio/myrecent.py
    biblio/pub_history.py
    biblio/recent.py
    common/library.py
    mod/list.py
    mod/recent.py
    scripts/add_new_record_id_index.sql
    

    Installed in SVN 477 on 2019-12-01. Keeping the FR open since we still need to implement the ability to view Edit Pub submissions.

     
  • Ahasuerus

    Ahasuerus - 2020-03-05

    Part 2 - rename the New record ID field in the submissions table:

    biblio/pub_history.py
    mod/isfdblib.py
    scripts/rename_submissions_new_record_id.sql
    

    Installed in SVN 502 on 2020-03-05. Keeping the FR open.

     
  • Ahasuerus

    Ahasuerus - 2020-03-06

    Part 3 - Add Edit Publication submissions:

    biblio/pub_history.py
    common/isfdb.py
    mod/pa_update.py
    scripts/populate_affected_record_for_editpubs.py
    

    Installed in SVN 503 on 2020-03-06. Keeping the FR open.

     
  • Ahasuerus

    Ahasuerus - 2020-03-06

    Part 4 - Corrected the date when New Pub submissions began populating the affected_record_id field in the submissions table:

    biblio/pub_history.py
    common/isfdb.py
    

    Installed in SVN 504 on 2020-03-06.

     
  • Ahasuerus

    Ahasuerus - 2020-03-07

    Part 5 - Add Import/Export submissions:

    biblio/pub_history.py
    mod/ca_new.py
    mod/isfdblib.py
    scripts/populate_affected_record_for_imports.py
    

    Installed in SVN 505 on 2020-03-07.

     
  • Ahasuerus

    Ahasuerus - 2020-03-07

    Part 6 - Added Remove Title submissions:

    biblio/pub_history.py
    common/isfdb.py
    mod/ta_remove.py
    scripts/populate_affected_record_for_remove_title.py
    

    Installed in SVN 507 on 2020-03-07.

     
  • Ahasuerus

    Ahasuerus - 2020-05-07

    Part 7 - Added Delete Publication submissions:

    biblio/pl.py
    biblio/pub_history.py
    common/SQLparsing.py
    common/isfdb.py
    mod/pa_delete.py
    scripts/populate_affected_record_for_delete_pubs.py
    

    Installed in SVN 522 on 2020-05-07. Keeping the FR open.

     
  • Ahasuerus

    Ahasuerus - 2021-01-11
    • status: open-accepted --> closed
     
  • Ahasuerus

    Ahasuerus - 2021-01-11

    Closing the FR since the basic functionality has been implemented. More advanced features like creating snapshots of publication records at the time they were changed will require additional FRs.

     

Anonymous
Anonymous

Add attachments
Cancel





MongoDB Logo MongoDB