e621ng / e621ng

artist_page_rename

When renaming an artist, the new name is shown on both sides, making it look like nothing actually happened.

artist_user_unlinked

The artist_user_unlinked modactions do not display a user like they should.

forum_topic_update

forum_topic_update is in the search dropdown, but it seems completely unused. In my mind this should be shown when the name of a forum topic is changed, since stick and lock have their own actions, but I can't see anything logged when the name is changed. As far as I can tell (aka I looked at the first commit it appeared in and called it a day), it's been unused since it was introduced in ca5b0d5.

report_reason_update

Only the reason is logged in the modactions, which hides changes to the description, making it look like nothing happened.

user_feedback_update

The user_feedback_update does not show if the type of record (positive/negative/neutral) was changed, it only shows the reason, regardless if it was changed. (as can be seen. It does log the new type of record, but doesn't say the previous type or call out the changes)

wiki_page_undelete

Since dc3fa7f, deleting a wiki page fully destroys the wiki page, and none of these entries seem to exist, thus making this action irrelevant.

Turns out I'm just an idiot on thinking extraneous actions are created, I expected to rename to show up visually in the artist versions but it doesn't, there's just a sudden shift in the name shown on the left. The same name being shown on both sides is definitely a thing, though

It seems to be writing it wrong into the database, I renamed an artist to "newname" and the result saved into the database was {"new_name":"newname","old_name":"newname"}.

e621ng/app/models/artist.rb

Lines 35 to 37 in aedea61

    
           if saved_change_to_name? && !previously_new_record? 
        
             ModAction.log(:artist_page_rename, { new_name: name, old_name: name_was }) 
        
           end

Maybe I'm missing something, but name_was doesn't actually seem to be defined anywhere.

The _was methods are rails magic. https://api.rubyonrails.org/classes/ActiveModel/Dirty.html

Based on that this seemed to have worked some time in the past I'm putting blame on this commit:
4dfd8f4

Notice how I changed when the callback gets executed but didn't touch the value being logged. It should probably be name_before_last_save instead.

Not sure I'll ever be able to wrap my head around all this rails magic, but it's interesting to learn about at the least. name_before_last_save does indeed seem to do the correct thing. There's also a linked_user_id_was in there that probably needs changing too.

Things like this are one of the reasons I really hate ruby and subsequently rails. Methods are so obscure and loosely defined that you can't hardly tell if what you're doing is working, or will continue working in the future. I say this coming from several strictly typed languages, which I'm very used to.

Not sure I'll ever be able to wrap my head around all this rails magic, but it's interesting to learn about at the least. name_before_last_save does indeed seem to do the correct thing. There's also a linked_user_id_was in there that probably needs changing too.

I was just looking around the mod actions and noticed something weird around all of the currently existing unlinking actions, they're all missing a user

This sounds like an issue that could stem from the usage of _was

Looks like I'm doing what I always do, taking one simple thing and applying a shit ton of scope creep. It's what I do best.

I fixed the artist ones and removed references to the wiki undeletion, don't feel like doing the rest right now.

	if saved_change_to_name? && !previously_new_record?
	ModAction.log(:artist_page_rename, { new_name: name, old_name: name_was })
	end

[ModActions] Inconsistencies and Issues