Explicit Author data model in openedx-core

[ormsbee]

Proposal

We create an authoring.authors app that has an Author model, and make all Learning Core authoring models link against that instead of the User model.

Rationale

The Learning Core convention to date has been to represent things like created_by using nullable foreign keys to the User table configured via Django settings (which for edx-platform is always the standard auth_user one). But I think that causes a number of issues:

• It doesn't properly distinguish between when relationships specifically want to address Authors vs. Learners.
• It makes it more difficult to map information into a second instance. If these three problems were created by "Clyde", and we have a publish log and history with that information in it, a full export should be able to preserve that information–even if "Clyde" does not exist in the system being imported into. (This assumes that we have a very rich export format for backup/restore purposes, possibly a SQLite dump of parts of the DB.)

Open Questions

I'm not sure whether this is a single instance-wide Author that's 1:1 with User, or whether we also have a notion of a LearningPackageAuthor relationship.

[bradenmacdonald]

It doesn't properly distinguish between when relationships specifically want to address Authors vs. Learners.

To me, this doesn't justify creating a new table and needing to maintain it 1:1 with learners. Can't this be addressed with a field type that wraps [foreign key to User] but validates/states that the user is an author? That still allows developers to declare when a relationship is to an author, but doesn't introduce any new table in the DB.

e.g. instead of

created_by = models.ForeignKey(settings.AUTH_USER_MODEL, on_delete=models.SET_NULL, null=True, ...)

we'd have

created_by = AuthorRelationship()

It makes it more difficult to map information into a second instance.

I'm unclear on how this is any different whether we reference "Clyde" via the users table or indirectly via authors ? Are you implying that during import we might import an Author along with a course, but we wouldn't import a User? In that case it would break the 1:1 Author:User assumption so all code that deals with Author would have to know that sometimes it may not be connected to a User.

But there's also a problem that if you import something onto the same system, you'd assume that the Author objects should be correctly linked up with Users as before, whereas is you import onto a different system, you can't assume that their User[username=Clyde] is the same person as Author[username=Clyde] from the export tarball - and how can the import code differentiate these cases? Unless you use emails rather than usernames.

[kdmccormick]

@ormsbee Is this something you still think is worth doing? If so, pre-1.0 or post-1.0?

[ormsbee]

@kdmccormick: I dunno if it's worth doing, but it's definitely a discussion that can wait until post 1.0.