Resume button

[Revadike]

What problem does this feature address?

There is a pause offer button, but no resume button

Describe a solution

Add a resume button when the offer is paused

Examples of similar features

No

[bartervg]

The current process to resume is edit and propose. A resume button would eliminate the edit step.

[bartervg]

Also needed, resume all offers. The auto pause is too aggressive pausing offers.

[bartervg]

[bartervg]

If the receiver of the offer leaves the page opens, and the sender pauses it, the receiver can accept and there's no indication that the accept failed. Clicking the accept button reports that the offer was accepted regardless of whether the status changes or not.

This occurs despite the offer being paused and ignoring any attempts to accept.

[bartervg]

A resume bad design problem: the expiration date doesn't update. Therefore someone could pause for 3 days, then resume a few seconds before expiration.

Resume should extend expiration such that the expiration time is at least as long as the receiver's minimum expiration preference. If the pausers want more control over expiration time, they can edit rather than resume.

[bartervg]

Clicking the accept button reports that the offer was accepted regardless of whether the status changes or not.

[ the sender pauses the offer while the receiver is about to accept offer ]

The offer would not switch to accepted before this change. However, there was UI that would claim offer accepted whenever the button was pressed, regardless of what happened with the database.

[bartervg]

Resume should extend expiration such that the expiration time is at least as long as the receiver's minimum expiration preference.

Upon resume, the expiration is checked to ensure it confirms with the receiver's preference. If now, the expiration is set to equal the minimum number of days that the receiver prefers. If the user doesn't have a preference set, the default is 3 days.

[Revadike]

Resume should extend expiration such that the expiration time is at least as long as the receiver's minimum expiration preference.

Upon resume, the expiration is checked to ensure it confirms with the receiver's preference. If now, the expiration is set to equal the minimum number of days that the receiver prefers. If the user doesn't have a preference set, the default is 3 days.

Wouldn't it make more sense to add the amount of time the offer has been paused to the expiration time? So essentially, the expiration "countdown" gets paused too?

[bartervg]

the amount of time the offer has been paused

This value isn't readily available. All that the offer saves is the unix timestamp of expiration.

[Revadike]

expire_unix = expire_unix + (resume_unix - pause_unix)

you should have this data from the offer timeline:

[bartervg]

(resume_unix - pause_unix)

These values are not saved in the offer. Yes, they're in the feed, but the offer doesn't have access to those values. I do have a slight preference towards your approach, but not enough to implement it.