Never Undo User's Actions

[0x4007]

We have a list of handlers that invoke the bot from user input. Perhaps there is a neat way to:

1. map every type of user input (assign, label etc)
2. understand their intent (i set a price label of 500 USD so the bot should not undo this as a response to my action)

Lets figure a design in the comments here and I'll add it to the spec.

• Will need to refactor #128

We should have a generalized solution instead which retains understanding of the original event that invoked the bot.

For example if we chain together all the handlers and pass in the original event that invoked the chain, the handlers will understand that the human input performed X action (like assign or set price label) and to make sure to not undo that.

Unfortunately it isn't clear if we need to manually associate together what the opposite actions would be.

Example:

[
  [ assign, unassign ],
  [ setPriceLabel, removePriceLabel ]
]

But outside of manually defining opposites, I like this approach because as we add more features this problem would inevitably get more complicated to handle every edge case for.

Originally posted by @pavlovcik in https://github.com/ubiquity/ubiquibot/issues/685#issuecomment-1716908473

[wannacfuture]

/stop

[ubiquibot[bot]]

You have been unassigned from the bounty @wannacfuture

[wannacfuture]

/wallet 0x9e4EF4353C928cD3eb473E8f12aeCF58C2089999

[ubiquibot[bot]]

Updated the wallet address for @wannacfuture successfully! Your new address: 0x9e4EF4353C928cD3eb473E8f12aeCF58C2089999

[wannacfuture]

/start

[ubiquibot[bot]]

Skipping /start since no time labels are set to calculate the timeline

[wannacfuture]

/wallet 0x9e4EF4353C928cD3eb473E8f12aeCF58C208ef40

[ubiquibot[bot]]

Updated the wallet address for @wannacfuture successfully! Your new address: 0x9e4EF4353C928cD3eb473E8f12aeCF58C208ef40

[wannacfuture]

/query @wannacfuture

[ubiquibot[bot]]

@wannacfuture's wallet address is 0x9e4EF4353C928cD3eb473E8f12aeCF58C208ef40, multiplier is 1 and access levels are

access type	access level
multiplier	false
priority	false
time	false
price	false

[0x4007]

@rndquu @0xcodercrane can you help me figure out the architecture for this?

[rndquu]

I understand neither the original issue nor the proposed solution.

understand their intent (i set a price label of 500 USD so the bot should not undo this as a response to my action)

If a user doesn't have the "edit price label" permission or assistive pricing is enabled then why we should not undo the action? Those features were added to prevent malicious intents.

[0x4007]

This was originally inspired by two issues we are working on solving:

1. Assigning a user and the bot automatically unassigning them immediately because they haven't commented on the issue in over one week

2. Setting the price label and the bot immediately removing it because the priority and time labels suggest another price.

The purpose of the current task is to create a generalized solution becuase I anticipate more issues like this down the road as we add new features.

[wannacfuture]

This was originally inspired by two issues we are working on solving:

1. Assigning a user and the bot automatically unassigning them immediately because they haven't commented on the issue in over one week
2. Setting the price label and the bot immediately removing it because the priority and time labels suggest another price.

The purpose of the current task is to create a generalized solution becuase I anticipate more issues like this down the road as we add new features.

Hmm... the solution might look like this: maybe the bot will be needed to check the user's actions history when he wants to do something and if he realize he is going to do something which is opposite to the user's action he might be needed to give up.

But what I'm thinking is : adding this check feature to all the bot's actions(there will be tons of them) vs making hotfixes about the cases(like above) every time we meet during the progress.

Tbh, I'm not too sure about the first method cuz we don't exactly know what to expect.

Rfc, @pavlovcik , @rndquu

[0x4007]

The thing is that I believe we need to teach the bot what is the opposite action. How does it know the api call to remove an assignee is the opposite of setting it to @pavlovcik?

Perhaps there is some type of regex we can do and ensure that it doesn't try and hit the same restful endpoint twice in a response?

[wannacfuture]

The thing is that I believe we need to teach the bot what is the opposite action. How does it know the api call to remove an assignee is the opposite of setting it to @pavlovcik?

Maybe we can add that info to config. (manually)

Perhaps there is some type of regex we can do and ensure that it doesn't try and hit the same restful endpoint twice in a response?

👀👀👀

[0x4007]

From an architecture perspective we need to handle everything in a single bot runtime instead of chaining together like three separate cold starts to complete a user interaction. After that, we have the ability to implement ideas like what I proposed.

I'm not 100% this is the case currently but thats what I am under the impression of based on how it undoes things.

[rndquu]

Assigning a user and the bot automatically unassigning them immediately because they haven't commented on the issue in over one week

If some user wants to assign a bounty hunter to an issue then perhaps we should check an "assign user permission" (not implemented). Then if user has that permission then bounty hunter will be assigned to an issue without undoing anything (i.e. permission takes precedence over whatever the bot thinks the right way to do).

Setting the price label and the bot immediately removing it because the priority and time labels suggest another price

Again, if user has a "price label permission" then the bot should allow setting the price label.

I want to say that if user has enough permissions to do an action then it should take precedence over the bot's logic.