Indexer model and User model
jwang44 opened this issue · 16 comments
The chant objects and source objects have fields like proofread_by, melodies_entered_by, and indexed_by. These fields are not consistently pointing to the same model.
For example, the proofread_by field of the chant model points to Users, while the proofreaders field of the source model points to Indexers.
We need to figure out how to unify the two in a way that make sense.
I don't see a proofreader field in the chants themselves--only the box about the source (which points to indexers). In OldCantus I can (now that I am a Debra) see "Authoring information", which does point to the users--but nothing about the proofreaders. (Maybe this shows up on NewCantus, if I were to log in...).
That said...
The people who get pointed to as "indexers" all seem to have been added from the dropdowns in edit-source; the "user" stuff (when it's visible) seems to be for things generated (by Django?), like who created the source. So one is public-facing ("indexers") and one isn't ("users").
Conceivably one could just replace/redirect the indexer information to user information, but I can see reasons to leave them separate; e.g. if somebody indexed the whole manuscript, we would want them under "indexer", but maybe we don't want a "user" who added a tiny thing later to also be listed.
And I guess it's theoretically possible you might want to list a proofreader who isn't a user--somebody who indexed a manuscript in print before Cantus, someone who's been removed from the user set, some generalized group like "Members of the Cantus-Is-Awesome Workshop 2022"...
It makes perfect sense that "indexer" is public-facing and "user" is what we use to keep internal records. However, in the old Cantus, they are two sets of people that do not completely overlap. @annamorphism Do you know how a "user" may become an "indexer" in the old Cantus? For example, I have an account in the old Cantus, so I'm a "user". I have the power to create manuscripts and chants, but I am not in the "indexer" list.
There's a "Add Indexer" button in accessible to Debras...let me see what it does...
@jwang44 Indexer Junhao is now inventorying this test source! User Anna created it, but isn't listed as inventorying it.
It looks like there is no association between indexer and user profiles in old cantus--I can guess that both Junhaos are the same, but there's no way of indicating that. It would probably be a good idea to make the indexer profiles linked to the user profiles...
Actually I wonder if "indexer" needs to be a separate category at all--what if instead one could choose which of the users already associated with a manuscript were to be publicly visible?
I guess the problem in that case would be what to do if there are non-users or ex-users to be listed (or people who were users and ceased to be?). And somebody would have to match all the current "indexer" information to "user" information, which sounds like a hassle.
Have we reached any conclusions with regard to this?
@jacobdgm probably best to consult with the Debra on how best to keep/merge/modify the user/indexer models.
Okay - in drafting an email to Debra, I think I've figured out why some fields point to Indexers and some to Users:
- Indexers are outward-facing, each with a page that can be navigated to and viewed. Indexers are also manually created - someone needs to go in and spell out their name and institution. Users, on the other hand, are just internal - each User is an individual who can log in with their username and password, and we keep a record of which User added/edited what in order to keep track of the internal operation of the database.
- Users and Indexers should not necessarily be linked with each other. Some users are not indexers (e.g. an undergraduate student who proofreads just a few chants as part of a course, or Jan the developer, who has a couple of user accounts for testing purposes but is not doing research) and some indexers are not users (e.g. I understand that in years/decades past, researchers prepared inventories which were distributed via hard drive, and which were later incorporated into the database. But the people who originally did the inventorying do not have accounts for CantusDB). This explains the discrepancies between the list of Users and the list of Indexers.
- For Sources: There are some fields in Source objects that we want to be publicly visible:
proofreaders,inventoried_by,full_text_entered_by,melodies_entered_by,indexed_by, and perhapsother_editors, so these fields are associated with Indexers. For internal use, we'll also have one or two fields that point to Users (e.g.current_editors) to control which users have access to edit the chants in that source. - For individual chants, however, the public doesn't need to see such fine-grained detail, so there should be no fields for Chants that point to Indexers (we still want to keep track of whether individual chants have been proofread and by whom, so we keep a
proofread_byfield that points to a User) - All this said, I don't see a reason that having Users linked to Indexers would be useful for anything, so I suggest that we don't attempt to link them.
A few observations to sum up:
- Indexers are only ever associated with Sources, and never with Chants. Some users are associated with Sources, but only to control edit access to the chants within those sources.
- Fields that point to Indexers will always be manually specified, while some fields (specifically, Chant fields) that point to Users are automatically generated (for example, when a user presses save on the proofreading form, they are automatically added to the relevant chant as a
proofread_by)
Does this all make sense?
Yes, this makes sense. Thanks to you both!
This all makes sense, and more or less corresponds to what I'd worked out myself. It still seems weird and inelegant to me that many people working on Cantus have two associated models and profiles that pop up for different but related things. (I think Cantus Index, for example, makes do with just a user model.) But it sounds like it might be sort of baked in at this point?
If I were designing this from scratch--but this is purely my fantasy--I think all these things could be users, and what we now call an "Indexer" is just a user that has been made public information on the source page--"published", basically. (This would also potentially make it really easy to acknowledge later contributions to extant sources: wow, user X fixed up 153 links in this old source index? let's publish their name as a proofreader!).
The problem with my fantasy is that it breaks on the set of indexers that aren't users. So maybe it doesn't really pass the cost/benefit analysis (cost: having to harmonize all the old Indexers; benefit: less duplicate information, much easier to see/recognize who did what.)
New idea
Ich came up with the idea of building a "master list" named "indexers" (or "musicologists", name pending) that is a union of the current "indexer" list and the "user" list. At the same time, we also keep a separate "account list" of only usernames (emails) and passwords, for all people in the current "user" list. In the master list, those who have an account (i.e., username and password) will be linked to their corresponding entries in the account list.
For displaying a list of contributors to Cantus DB (like the indexer list that we have now), we display the master list. For each individual source, the displayed proofreader, contributor, etc. will all point to the entry in the master list.
For internal book keeping, when a logged-in user make changes to the database, we find the master list entry linked to their account, and record that for fields like "created by" or "last_updated_by".
This way we use the master list for both public facing things and internal book keeping. Any suggestions and thoughts?
This is not so very different in practice from what I was imagining, although the implementation is different (so it gets rid of the problem with indexers who aren't users.) But won't a simple union still mean there will be duplicate accounts to get rid of in the master list?
e.g. if Indexers is currently {NonUser, Indexer Anna, Indexer B} and Users is {Developer, User Anna, User B} the master list becomes {NonUser, Indexer Anna, indexer B, Developer, User Anna, User B} and "account list" remains {Developer, User Anna, User B}, so User Anna and User B still need to be taken out of the master list and linked to their entries in the account list instead. Is that right?
Yes, that is right. We will need to merge the two entries for people who appear in both lists.
Another solution, now that I have put more thoughts into it. seems easier. That is, to make dummy accounts for those who are in "indexers" list but not in "users" list. This way we won't need two lists, we just put everyone into the "users" list. All of them will have their respective login, but some of them (i.e., those with dummy accounts) will never actually use it to log in.
@jwang44 I was also thinking this! This will mean there will be a lot of "extra" inactive accounts, but as long as that isn't a problem this seems like a pretty clean solution. (For comparison, it seems like CantusIndex assigned all pre-migration user contributions to the user "CantusDatabase", which is sort of like what you are proposing except with only one dummy account.)
This is done in PR #388. We keep only the User model and removed the Indexer model. Those who appeared in the indexer list but did not have an account are assigned dummy accounts with randomly generated fake emails, thus becoming User objects.
To associate a User object with its deprecated Indexer object, an old_indexer_id field is added to the User model. If the User object had a corresponding Indexer object or was converted from an Indexer object, the Indexer object ID is stored.