-
Notifications
You must be signed in to change notification settings - Fork 241
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Undo event deletion #149
Undo event deletion #149
Conversation
@georgehrke, thanks for your PR! By analyzing the history of the files in this pull request, we identified @tcitworld, @MathieuSchopfer and @raghunayyar to be potential reviewers. |
4 similar comments
Will have a look asap. |
} | ||
}, 7500); | ||
|
||
const elm = OC.Notification.showTemporary(t('calendar', 'Undo deletion')); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll prefer "The event has been deleted. Undo ?"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, for sure. The pattern is:
eventname has been deleted. Undo?
if (context.isDeleted) { | ||
resolve(); | ||
} | ||
}, 7500); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
7.5 seconds is too high IMHO. The user has got plenty of time to switch to another app, resulting in the deletion action not executing (correct ?).
I don't know if there's a way to execute queue actions when we're leaving the app. Leaving the browser could be handled though, right ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems good. So undo actions should be in a queue that gets emptied on timeout or on the beforeunload
event.
(@georgehrke just btw: is it possible to reduce the Coveralls comments or not have them at all? We have the summary on the bottom with all the other checks, so the comments are just noise.) |
Coverall is only supposed to send one comment per commit pushed. :/ |
(Yeah, as said disabling is better than commenting because we have the summary here on the bottom anyway. Thanks!) |
angular.forEach(eventsToRender, function (event) { | ||
fc.elm.fullCalendar('renderEvent', event); | ||
}); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rerendering undeleted events like this causes them to double render when another event is created. I know that is a confusing way to word it so I took a short video.
Fortunately, this is simply a rendering artifact and resolves itself on reload.
If you rerender the events like this:
fc.elm.fullCalendar('refetchEventSources', vevent.calendar.fcEventSource);
it does not appear to cause this problem.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good catch!
I tried using refetchEventSources, but I think it's a bit problematic. The event takes at least one second to reappear, because the browser has to send a CalDAV request to the server.
It would be way better, if the event would reappear immediately.
66b9143
to
24683d1
Compare
24683d1
to
10a0eb8
Compare
I rebased, changed the string and fixed the issue mentioned by @wrexroad |
The mysql and postgres builds failed, because it couldn't reach the database. |
Two thoughts:
|
Yes, I want to solve that at another point. We can't send requests in onbefureonload, because the requests are async. The browser won't wait for them to finish but just cancel them. |
I think ensuring events actually get deleted is really important. Think of the situation where someone knows that the just need to quickly load up the page, delete an event, and close the browser. If they don't know that they have to wait 7 seconds before closing the browser it will create confusion. I feel like the worst part of it is the event instantly disappears, giving a visual cue that the event is, in fact, gone. How would you feel about changing the notification to be a countdown. Something like "event name will be deleted in 3,2,1s. Click to cancel." Only when the timer runs out will you remove the event from the calendar and delete it from the server. This also solves the double rendering issue. Another idea is as soon as the delete button is clicked dump the event properties to temporary location then immediately delete the event from the server and clear the event from the calendar. Then if the undo button is clicked you can create a new event using the properties that were saved. If the button is not clicked you dump the temporary storage. |
The only thing we can do with onbeforeunload is to ask the user if he really wants to leave the page.
AFAIK all invitations will be send out again in this case. |
Yikes that's no good at all. I hadn't even considered invitations... |
@jancborchardt What's your opinion about the leaving the page thing? I checked what files does, but the undo is completely gone even if files_trashbin is disabled. |
It would be awesome if you could cue jobs on the server, like "delete event x in 7 seconds, if you don't here a cancel message" Just a thought... |
Hm, what if you are traveling in a train? I wouldn't exactly trust the cancel request to make it's way to the server (in time) ;) Regarding the server: I'm also working on a retention feature: nextcloud/server#1662 |
This approach is at a dead end thats only gonna end up in a huge chain of ugly hacks. |
fix #13
please review @nextcloud/calendar