SQL: Schema Changes for Administration System

[the-good-boy]

This PR deals with the schema changes for the Administration System.

Changes:

• A new column called privs added to bookbrainz.editor.
• A new type called admin_action_type has been added to support potential action types which can be added in the future
• A new table called bookbrainz.admin_log has been created to track admin logs

[kellnerd]

Suggested change

	user1_id INT NOT NULL,
	user2_id INT NOT NULL,
	admin_user_id INT NOT NULL,
	affected_user_id INT NOT NULL,

Numbering the involved users makes these tables harder to understand, I would suggest naming the columns after the users' roles. Since this has also to be changed in other places, it would probably make sense to await all reviews before doing the changes.

[the-good-boy]

The reason I am hesitating to use such naming convention is because admin_user sounds like a higher-ranked user in hierarchy compared to the second user. This will be true in the current use-case. But in the future, when more actions such as Reporting a user are added, the first user might not necessarily be higher ranked than the second one.
It is possible that I might be reading too much into this.
For what its worth, my initial proposed schema contained similar naming. I am fine with it.

[kellnerd]

Good point, the affected user could be an "admin" too (whatever that means in the future). Maybe acting_user would be a better name?

[the-good-boy]

I think we can go with a simple admin_id and user_id columns. Since an 'Admin' is not an explicit user type in bookbrainz, we can say that an admin refers to anyone who is performing the administrative action, and the user is the user to which the action is directed at.
The moderation log schema of CritiqueBrainz is also somewhat in the same vein, so I think this will be good enough. What do you think?

[MonkeyDo]

I think admin_id and target_user_id would remove any doubt as to who is doing what, and might be a bit clearer than "actor"/"acting" or other alternatives I could think of (executor, initiator).

[meziyum]

How about using user_id for the user initiating the action and target_id for the user getting affected?

[MonkeyDo]

I think that is more confusing at a quick glance, user_id could be either of the two.
Obviously target_id or target_user_id is quite clear, so perhaps source_user_id could also work in that case (but I still prefer admin_id myself.

[the-good-boy]

I am also inclined towards using admin_id and target_user_id. I think they are succinct and serve our purpose well.

[MonkeyDo]

Also relevant, for what it's worth: I don't think the admin logs will show any action that hasn't been taken by an "admin".
For example, the use-case cited above (user1 reports user2) likely won't be shown in the admin logs, but the resulting action (admin blocked user2) would be.

[MonkeyDo]

Apart from the comments below, looks all good !

Excited to see the start of the project ! 🚀

[MonkeyDo]

I think admin_id and target_user_id would remove any doubt as to who is doing what, and might be a bit clearer than "actor"/"acting" or other alternatives I could think of (executor, initiator).

[MonkeyDo]

I changed the merge target to the newly created administration-system feature branch.

[MonkeyDo]

Good to go! 🚀

And so it begins !

I ran both migration files against the test.bb.org database, for reference, so that it is ready for the next steps.