Record verified email, if present, of the publisher in the version record #1621
Conversation
field to the versions table. Also updates the schema.rb to reflect this table change. published by is a foreign key referencing the users table.
in the new field.
match the Version Struct correctly. Fixes test in the same file broken by this change
creation of the new versions in the krate publish controller and in the update-downloads bin
by adding in user_id arguments to pass it through. Unsure if this is the best way to solve this issue in the tests.
published by is a nullable field now.
be part of their own builders.rs file and this PR accidentally merged them back into the all.rs file when trying to resolve the merge conflict. This commit removes them from all.rs so that it reflects master, and then makes the minimal changes needed to the models in builders.rs to reflect the new database updates.
Always pass None for the moment
And use it in places where there's only one version
When we need published_by
carols10cents
force-pushed
the
record-verified-email
branch
from
c40068e to
623cfe7
Compare
|
Since we virtually never want this column outside of storing it for auditing purposes, does it make sense to store it in another table instead of as a column on versions? |
|
Great idea! That would certainly get rid of the complexity from working around diesel-rs/diesel#1979. Do the changes from #1561 look ok? Would you rather merge that one and then this one, or only merge this one? |
…isher The publisher's email address is deliberatel copied into this table rather than referencing the users table. If people delete their account, remove their email, etc we still have a way to attempt to contact the publisher of a particular version in the event of a DMCA complaint.
If there is one, because we're still in the optional stage, but we can start recording them now if possible.
carols10cents
force-pushed
the
record-verified-email
branch
from
623cfe7 to
8935dcd
Compare
|
#1561 looks fine overall. I'd probably opt to do a second query to load the publishers, but we can always make those changes later. I have no strong feelings on which we merge first, but I'd probably like to deploy at least once before merging either since we have a lot of code already in master for the next deploy. |
|
This looks good to me. I've also tested in staging and confirmed that the publishing information is provided in the API and that the verified email address is recorded in the database (but not exposed publicly). Thanks @Andy-Bell and @carols10cents for your work on this. @bors r+ |
|
📌 Commit 8935dcd has been approved by |
|
☀️ Test successful - checks-travis |
Connects to #1620. We can start recording emails if we have them, even though we're not requiring verified emails yet.
This builds on top of #1561.