Requested feature overview description.
I suggest a functionality should be added that would allow admins to undo the changes made when an implication or alias is approved, with a single click.

Basically, every time an alias or implication is approved, a record should be made that contains all the changes that occured as a result of a new alias or implication. This record can then be used to single-click undo the changes made.

Why would it be useful?
It would be useful for admins to undo an alias or implication if it's been found to have been done in error.

What part(s) of the site page(s) are affected?
Tags => Aliases / Implications

I like the idea but because I'm not a dev, I have no clue how difficult it would be to add this feature.

@Siral_Exan
Please read more carefully what I wrote. It's not about removing alias or an implication, but undoing the changes that occured. An alias causes all the posts that contain this tag, to have this tag renamed. Undoing the changes in this case would mean, reverting all the posts that had this tag renamed, back to the old tag name.

Knotty_Curls said:
They actually are permanent. Changes currently need to be reverted manually.

Not even admins can undo changes right now, barring a site rollback or something similar.

I like the idea but because I'm not a dev, I have no clue how difficult it would be to add this feature.

Actually, I do now remember seeing how Parasprite does it... it has been a while since I bothered checking her mod actions.

Delian said:
Please read more carefully what I wrote. It's not about removing alias or an implication, but undoing the changes that occured. An alias causes all the posts that contain this tag, to have this tag renamed. Undoing the changes in this case would mean, reverting all the posts that had this tag renamed, back to the old tag name.

Are you sure that it isn't simpler than what you are saying? If you are willing to argue about aliasing and implications on the other thread, how far do you know with all this?

Siral_Exan said:
Are you sure that it isn't simpler than what you are saying?

It is very simple to delete an alias or an implication. But undoing the changes is currently impossible. That's because, currently, creating an alias or implication causes changes, but these changes don't leave any traces anywhere on the site.

Siral_Exan said:
how far do you know with all this?

Sorry, I don't understand that question.

Knotty_Curls said:
I like the idea but because I'm not a dev, I have no clue how difficult it would be to add this feature.

I can imagine a couple of ways to implement this feature, but it wouldn't be too simple.

• You would need to create an "Undo" button somewhere in the A/I admin system. Dunno where coz I'm not an admin.
• You would need to implement the functionality when this button is clicked.
• When the button is clicked, A/I first needs to be deleted. And then the changes need to be undone.
• To undo the changes, there's several possibilities:
• Read from datatables which store changes made when A/I was introduced. This means that whenever A/I is introduced, you would need to store the changes in these new data tables.
• Execute an "undo script". This means that whenever A/I is introduced, you would need to create a database script file and then store it on the server.
• Undo tag changes that a user made. I think this would be the most elegant solution as it doesn't require any script or datatable creation. Basically, you create a user, let's say Tag_Subsystem. Whenever A/I is introduced, this user would (virtually) go through the posts that need to be changed, and add/delete tags (plus leave a reference in the Reason field eg. Alias Tag1 Tag2). Since a user is doing this, it would leave records in post tag history that we can find. Undoing the A/I changes would be the same as undoing tag changes that this user made (filtered with the Reason field)

Tag scripts can, but I can't say have, undo such changes. Some of our users use them, I personally don't, but the admins do know of them.

To clarify, I'm the one who told Delian that it's sometimes difficult to undo the changes of an alias or implication

Aliases aren't much a problem most time because the old term is usually small and not very populated. Still, once the edits are made, it's not always easy to reverse it and often requires going back through search results and sifting manually.

This would be a nice feature, but at this time I'm not sure if it's something we can implement

Instead of a completely new feature, maybe the existing ones could be adapted for this?

It's already simple to import posts by post number into sets (https://e621.net/set/post_list/), and maybe that could be used to automatically generate private sets of posts that got aliased away. Then those could be easily restored with tag scripting..

(I've done something similar with greasemonkey: wrote a script that compiled post numbers from a search, so they could be easily imported into a set.)

Disclaimer: I have a developer background. I can assume pretty accurately what's going on under the hood of the site, even without being an admin myself, simply by observing the existing features. So I already knew what was going on before I suggested this feature or talked with anyone.

Genjar said:
generate private sets

I can already tell you, that this would work. But it would not be elegant for the following reasons:

• The sets would not be accessible to everyone (and if they were, it would be huge set spam)
• When a change occurs due to an A/I, it still leaves no record in any posts's tagging history, and users may be left to wonder, "How did this tag appear here? There's nothing in the history about it.."
• You would need multiple sets for every A/I.

On the last point, as you know, an alias creates two types of changes. It either renames a tag (if the destination tag doesn't exist), or removes it (if the destination tag already exists). So to correctly undo the changes, you would need two sets. One set to tell which posts need to have the old tag added again, and one set to tell which posts need to have the new tag renamed back to old one. In case of implications, it's a similar thing.

But anyway, for the above reasons I think the solution with a system user is a better one. Frankly, the system user doesn't even need to exist. It could simply be a null user.

In addition I really think the suggestion system should also take you to the existing thread for the alias instead of spitting out a meaningless error

That's an unrelated bug which you should report separately.

Bumping this because I think this feature has become very important.

Basically, for the past 2-3 years, hardly any new aliases/implications have been approved. An average unapproved alias suggestion (of the 1.8k waiting) is over a year old and the situation isn't getting any better.

One of the main problems that I see with approving aliases/implications is that admins have to be super sure that no mistakes are made when approving them. Because if someone fucks up, there's no way to undo it. And even for admins it's sometimes practically impossible to be sure if the alias or implication is correct, which is why this is such a slow and painful process.

On the other hand, if this feature was to be implemented, approving A/I suggestions would become much easier, and may even be opened to mods / privileged users because, if someone fucks up, the changes may always be undone.

Delian said:
Bumping this because I think this feature has become very important.

Basically, for the past 2-3 years, hardly any new aliases/implications have been approved. An average unapproved alias suggestion (of the 1.8k waiting) is over a year old and the situation isn't getting any better.

One of the main problems that I see with approving aliases/implications is that admins have to be super sure that no mistakes are made when approving them. Because if someone fucks up, there's no way to undo it. And even for admins it's sometimes practically impossible to be sure if the alias or implication is correct, which is why this is such a slow and painful process.

On the other hand, if this feature was to be implemented, approving A/I suggestions would become much easier, and may even be opened to mods / privileged users because, if someone fucks up, the changes may always be undone.

I don't think that the admins would be willing to open up alias and implication abilities to anyone below Janitor ranking (and mind you that Janitors don't have those abilities either). (Edit after seeing SnowWolf's post: Wait, Janitors actually do have this ability?) There have been Privileged users in the past who ended up having their account levels downgraded because they ended up breaking site policy, including those related to tagging.

That said, I will admit I've been frustrated by the lack of alias and implication approvals myself. Sure, a bunch of aliases and implication suggestions have been approved as of late, but they've been only for species, and some of those have been for suggestions made within the past week or so. Meanwhile, I've been supporting someone else's suggestions relating to some copyright-based aliases they suggested last month (forum #264393) and there still hasn't even been any further discussion on that outside of a couple bumps I made. Either way, there needs to be something done about the long waits for alias and implication suggestions.

Delian said:
Bumping this because I think this feature has become very important.

Basically, for the past 2-3 years, hardly any new aliases/implications have been approved. An average unapproved alias suggestion (of the 1.8k waiting) is over a year old and the situation isn't getting any better.

Ignoring the fact that over the last week we've had at least 100 approved....

One of the main problems that I see with approving aliases/implications is that admins have to be super sure that no mistakes are made when approving them.

That is, yes, ONE of the problems. It is not the only problem, however.

Because if someone fucks up, there's no way to undo it. And even for admins it's sometimes practically impossible to be sure if the alias or implication is correct, which is why this is such a slow and painful process.

This is easier said than done. Okay, we alias tagA to tagB... then a week later, we realize that that is an error. WHat do we do about the posts that have been tagged tagB in the interim?

Okay, if you have TagB which implies tags C, D and E... if you 'undo" tagA ->tagb... what about htose implied tags?

It's not as simple as a magic "undo" button.

On the other hand, if this feature was to be implemented, approving A/I suggestions would become much easier, and may even be opened to mods / privileged users because, if someone fucks up, the changes may always be undone.

Not even just 'no'... a lot no. SO much no.

That stuff still takes server time, you know? I, personally, have killed the website because I approved an alias at the wrong time of day. :P

now what happens with trollface mc pants decides to alias female to troll? and male to penis? WHOOPS! Come back in a week.

SnowWolf said:
Ignoring the fact that over the last week we've had at least 100 approved....

Not ignoring. But even if that was the norm (which it's not) this feature would still be very important.

That is, yes, ONE of the problems. It is not the only problem, however.

It's not the only problem, but it's the main problem that I see. I would say that, in the first place, it was a huge mistake to release the A/I features without an ability to undo them.

we alias tagA to tagB. What do we do about the posts that have been tagged tagB in the interim?

There's four options.
1. We don't do anything.
2. We unconditionally add tagA to those posts so that they now have both tagA and tagB.
3. We keep only one tag - the larger of the two tags.
4. We manually check those posts to determine which of the two tags applies.
Any of these options are better than what's currently available because, in that case we would only need to worry about the posts that have had tagB added in the interim, whereas currently if we want to undo an alias, we have to manually check all the posts, which isn't practical.

what about those implied tags

I have thought about this before. Actually, this applies to both aliases and implications because, no matter how the post got tagB, it's possible that it would pull in the whole implication chain.

https://e621.net/post_tag_history/index?post_id=232535
Viewing a post's tag edit history, you have a list of change records. On the bottom left you have an Undo button. Undoing an alias/implication would be the same as selecting the correct record and clicking that Undo button. Try it. The functionality is already there.
In other words, if the newly introduced A/I adds more than one tag to a post, all the tags that were added with the implication chain would be included in that record. And undoing that record would also remove all such tags.

That stuff still takes server time, you know? I, personally, have killed the website because I approved an alias at the wrong time of day. :P

But you're a... Janitor. I didn't know Janitors could do that. Anyway, if adding/undoing an A/I kills the server, then perhaps the process should be optimized to allow better concurrency. That is, instead of processing all the posts in a single transaction, it should be done in batches of 100 posts. However this problem has nothing to do with this feature.

trollface mc pants decides to alias female to troll

Then trollface mc pants would get in trouble. The point is, it's up to to admins to decide who they would trust with such a responsibility and it would be easier to trust more people with an undo feature there. It doesn't need to be Privileged+. It could be Janitors+, or Mod+. Also, the feature could be restricted for tags with higher post counts. In any case, this was just a suggestion which isn't important right now.

Sorry, misplaced this post for a few days...

Delian said:
Not ignoring. But even if that was the norm (which it's not) this feature would still be very important.

It's not the only problem, but it's the main problem that I see.

The problem you see is not the only problem that exists. It's an aspect of things, but there's a lot of reasons why complicated aliases and implications are not done quickly or casually. Among other issues, there's the question of how do these tags fit into the eco system. If we usually tag things like grabbing_hand and grabbing_thigh, then thigh_grab doesn't fit in. but if we alias or imply things from that, it makes thigh_grab look legitimate when it really doesn't fit in to the ecosystem.

Further, aliases or implications can make it harder to find content. For example... let's say we want to alias werewolf to 'were'. (it's a bit silly, but go with it, okay? this is an example...) ... if you alias that, all of the werewolf pictures are now in the were tag. you can't search 'werewolf -wolf' to see if there are any missing wolf tags. you can't browse through 'werewolf' anymore to see if some of those werewolves should actually be wolf anthros rather than shape shifters. werewolf to were is still a good idea (in our fantasy land), but it needs a lot of work before it's ready to get there. and there are a LOT of people who are willing to say "we should do this" but won't actually retag any pictures... so, hypothetically, our alias maker has to do all the work by themselves in order to make this alias.

There's a LOT that goes into making a good alias or implication. Some of them are really simple: shoes imply footwear, for example, but other htings are more complicated.... like.. .pantyhose cover the feet... are they footwear?

it's tiring and mentally exhausting. and tedius. and all of these are things that lead to mistakes being made.

I would say that, in the first place, it was a huge mistake to release the A/I features without an ability to undo them.

I'm actually not sure that there isn't a way to undo things, but it's been a few years since I've had access to those systems :p

but sure, let's say that there isn't a way to undo them.

I agree. but this site is over a decade old, and has gone through several different coders and programmers. It's not always easy to just "program in an undo function" after the fact. Actually I imagine that if it was possible, it would already be done. Or it would take a lot of time that could be used to do other things to improve the website. Programming takes man hours of work, man hours of testing to make sure that we won't accidentally break the whole website.

woulda been nice if there was an easy undo programmed in a decade ago, but that ship sailed a long time ago and no one involved with the site right now had anything to do with those people.

There's four options.
1. We don't do anything.
2. We unconditionally add tagA to those posts so that they now have both tagA and tagB.
3. We keep only one tag - the larger of the two tags.
4. We manually check those posts to determine which of the two tags applies.

That is very neat and tidy laid out like this, but it's not so simple.

I have thought about this before. Actually, this applies to both aliases and implications because, no matter how the post got tagB, it's possible that it would pull in the whole implication chain.

https://e621.net/post_tag_history/index?post_id=232535
Viewing a post's tag edit history, you have a list of change records. On the bottom left you have an Undo button. Undoing an alias/implication would be the same as selecting the correct record and clicking that Undo button. Try it. The functionality is already there.

I don't know much about coding, but I'm pretty sure you're doing the equivalency of saying "look, we already have doors, it's not that hard to turn them into elevators!"

Yes, we can undo actions done to a single post, but that is dramatically different than doing it to thousands of posts at a time. Especially as, to my recollection, some aliases and implications are applied to posts in kind of a qweird way. it used to be that someoen would have to actually edit the tags or view the post in order for the tag changes to show up in tag history, but perhaps that's changed over the years.

in other words.. the systems look a like, but they're probably very different.

Delian said:
But you're a... Janitor. I didn't know Janitors could do that.

BooruHitomi said:
(Edit after seeing SnowWolf's post: Wait, Janitors actually do have this ability?)

Nope, we don't. I was an admin for about 2 years around 7 years ago. I mostly dealt with aliases and implications and eventually took an.... .extended break after burning out from spending about 6 to 8 hours on the website every day trying to a) debate tags, b) organize tagging projects, c) retag a lot of things in preparation for aliasing or implicating, d) apply aliases and implications without fucking things up too badly. 6 to 8 hours a day. If not more.

Anyway, if adding/undoing an A/I kills the server, then perhaps the process should be optimized to allow better concurrency. That is, instead of processing all the posts in a single transaction, it should be done in batches of 100 posts. However this problem has nothing to do with this feature.

This is, again, one of those things where you're talking about barn doors and elevators. It's been a decade and we have great programmers working on things. I am pretty sure that *IF* that problem still exists, if the solution was as simple as splitting things up into batches, it would have been done a long time ago.

Then trollface mc pants would get in trouble. The point is, it's up to to admins to decide who they would trust with such a responsibility and it would be easier to trust more people with an undo feature there. It doesn't need to be Privileged+. It could be Janitors+, or Mod+. Also, the feature could be restricted for tags with higher post counts. In any case, this was just a suggestion which isn't important right now.

Again, that is talking about things in a way taht suggests that this would be a simple change when it *isn't*. No, it really isn't.

it isn't as simple as user_allow_alias:Y ... if it was, we'd have a lot of things different around here. It really really isn't that simple.

I'm for pretty much anything that will speed up the aliasing/implication approval process cause it is slow af. I requested some extremely simple artist aliases that are just sitting there for over a year. I do a fair bit of work to research these...provide evidence for their name change...give sources and links...and some are just never approved. If you want people to participate in your system you have to reward them for doing so by giving them some sort of reasonable timetable...a year+ is not reasonable. In fact I haven't had any of my alias suggestions approved in the last 6 months. I'm starting to think I'm getting discriminated against...do I need to start a new account or something?

SnowWolf said:
This is easier said than done. Okay, we alias tagA to tagB... then a week later, we realize that that is an error. WHat do we do about the posts that have been tagged tagB in the interim?

Obviously just make the revert effect only posts that where present for initial aliasing...anything tagged after that would not be affected and ofc would have to be evaluated by hand.

SnowWolf said:
Okay, if you have TagB which implies tags C, D and E... if you 'undo" tagA ->tagb... what about htose implied tags?

It's not as simple as a magic "undo" button.

I'm not a coder...and I'm guessing neither are you. I have no idea how difficult that would be. Could be hard af, could be easy. Even if it's hard doesn't mean it's not a good idea.

SnowWolf said:
now what happens with trollface mc pants decides to alias female to troll? and male to penis? WHOOPS! Come back in a week.

They could simply not be allowed to preform reverts on very very old aliases and aliases that deal with very large tags. Basically anything with site-crashing potential they wouldn't be able to touch.

I definitely think this site needs more people with the power to approve aliases/implications.

Dyrone said:
I'm not a coder...and I'm guessing neither are you. I have no idea how difficult that would be. Could be hard af, could be easy. Even if it's hard doesn't mean it's not a good idea.

This isn't a coding problem at all, it's a design problem: What is a ruleset that is consistent and understandable to the user?

This is not the same thing at all as 'what technical measures must be taken to make undo work'. You actually need a coder for that, it's not a problem that can be solved entirely by a design committee. SnowWolf wasn't raising coding difficulty as a problem, AFAICS.

Here's an example of the extent to which a design can be logically nailed down without entering the domain of coding.

Dyrone said:
I'm for pretty much anything that will speed up the aliasing/implication approval process cause it is slow af. I requested some extremely simple artist aliases that are just sitting there for over a year. I do a fair bit of work to research these...provide evidence for their name change...give sources and links...and some are just never approved. If you want people to participate in your system you have to reward them for doing so by giving them some sort of reasonable timetable...a year+ is not reasonable. In fact I haven't had any of my alias suggestions approved in the last 6 months. I'm starting to think I'm getting discriminated against...do I need to start a new account or something?

I don't think anyone here would disagree that there should be more aliases and implications being made. The problem is, as I suggested, it's a lot of work and it's very easy to burn out. But I'm pretty sure everyone here agrees that it would be nice if it could be done faster.

We appreciate your efforts and you're not being discriminated against, I promise. I'm not sure any of the suggestions I've made in the last year or whatever have been approved, and they like me enough to make me a janitor again :P

Just, I'm not sure that this idea will necessarily have the effect people want it to have.

I'm not a coder...and I'm guessing neither are you.

Eh, not recently, anyway. Not in the way we're talking about, anyway.

I have no idea how difficult that would be.

What I do have is knowledge gained from the people who ARE coders and HAVE worked on the website. I've been around here for a long time in various shapes, and I've heard a LOT about how the website is coded... and I know that a lot of things that should be easy changes are not, due to how the code was initially made.

coding is one of those things were... something can sound conceptually easy, but it turns out that there are some huge problems with it. Like, for random example... in World of Warcraft, You have a backpack, and several other bags you carry with you. you start out with the backpack and find other bags as you level. For a long time, they said that while they would like to make the basic backpack bigger, they couldn't because it was literally hard coded into the game that it was a certain size: no more, no less.

To players, it seemed like a simple problem: just change the 16 slots to something bigger! or let them replace the bag with a bigger one, but it wasn't that simple because the code didn't have "bags"... the code basically had a list of inventory slots. Slot 1 was your hat, slot 2 was your gloves and so forth. then after those slots, you had an inventory. 16 lines for the backpack, then bag one started...and so forth. Still, seems eacy to fix... except there were a lot of things that relied on the backpack being that certain size. (Like, to make up an example, the bank inventory spaces would start on line (18+16+bag1+bag2+bag3+bag4+1)... which, again, sounds pretty easy to fix, except this stuff wasn't clearly labeled as being connected to the inventory system. So it was coming over the code line by line to try and find all of the references to this idea, and even then, you'd miss some. and with something like this, missing some might mean items disappearing. and with a game that big, with millions of players, chances are that despite all teh testing, someone will still find a way to accidentally delete everything they own. It would take a LOT of time and manpower to change this. Ooorrrr... they could just give you bigger bags in the end game and make sure that new characters get several opportunities to get additional bags.

So... the fact that this hasn't already been done, and that kira hasn't said OMG GREAT idea, suggests to me that this idea is way harder than it seems on the package.

Could be hard af, could be easy. Even if it's hard doesn't mean it's not a good idea.

It is a good idea! Never denied that! :)

SnowWolf said:
There's a LOT that goes into making a good alias or implication

I understand that and I agree. A bit unrelated, but I have proposed (forum #211150) a way to improve the suggestion process in the past. Of course, nothing happened. So how would you make the process easier then?

all of these are things that lead to mistakes being made

Mistakes will always be there. But as long as A/I are being approved, the system should, in theory, gravitate towards an optimal state. The important thing to note is that, if mistakes could be undone, this gravitation would be a lot faster. Because, in various ways, less effort would be required.

I imagine that if it was possible, it would already be done.

It's kinda funny how most ideas seem obvious in retrospect. Well, the A/I system wasn't built by e621. It's a default (badly coded) Danbooru feature which Ouroboros and in term e621 avoided making any significant changes to. IMO not because it wouldn't be possible, but for a mix of other reasons. No dedicated developers, no one bringing it up, and no one in power pushing for it.

It really really isn't that simple.

Why do you keep... I never mentioned that it was simple. Oh, I get it now. Are you afraid that I'm blabbering about things without knowing left from right? Sorry, I forgot to mention a tiny detail.
I am a coder. I know what's simple and what's not and if KiraNoot came over and went let's do this I'd be glad to go deeper into technical details of the undo feature's implementation (of course, I can only assume so much without seeing the code). If I'm making it sound like things are simple, it's because I'm trying to make it simple to understand, not because it would actually be simple to implement.
Heh, let me state it clearly. This feature would definitely not be simple to implement. But it would also not be super hard.