[kronolith] Changing event start date/time

[Michael J Rubinsky]

Quoting Jens Wahnes <wahnes at uni-koeln.de>:

> Michael J Rubinsky wrote:
>
>>>>>>>>> The results is an event that starts probably at day 0 in year 0. I
>>>>>>>>> didn't scroll back that far, but the database entry for that event
>>>>>>>>> says event_start = "0000-00-00 00:00:00".
>>>>>>>>> The problem now is, as user your don't have a possibility to
>>>>>>>>> resolve
>>>>>>>>> your mistake, because you're unable to edit or remove this event.
>
>
>> This should be fixed now in Git for the next bug fix release. I was able
>> to reproduce it on Windows. The commit to fix it is here:
>>
>> https://github.com/horde/horde/commit/2ca61864fa1cfd3462baeec7de77c02fa2b66edd
>
> I suppose this fix was included with the Kronolith 4.2.17 release?  
> Because that same thing (event with empty aka 0000-00-00 start and  
> end date in the database) is still happening here with the latest  
> Kronolith release. One of our users really likes to create such  
> events with empty start and end date, so we see that error on a  
> regular basis.
>
> With version 4.2.17, I was able to reproduce this with every browser  
> I tried, not just Firefox on Windows. It happened with Firefox (47  
> and 45 ESR), Internet Explorer 11, Vivaldi, and Chrome on a variety  
> of OSes I tried (Windows, Linux, MacOS).
>
> Steps to reproduce:
>
> 1) Create a new event in Kronolith, e.g. by clicking on tomorrow's  
> date in the month view, and enter some details (e.g. tomorrow at 2  
> in the afternoon, with some title and description). Click the "Save"  
> button.
>
> 2) Edit that new event by clicking on it, e.g. from the month view.  
> Edit it to contain no start and end date, e.g. by doing <Tab> <Del>  
> <Tab> <Tab> <Del> <Tab> <Tab> (I did this many times so I know the  
> keyboard shortcuts by heart). Click on "Save".
>
> No warning is issued, but the event is saved to the database with  
> the new empty date.

This is now more completely fixed in Git for the next release. There  
were a few things going on, one of which was a bad merge when the fix  
was merged from the master branch. There were also some other  
javascript errors being triggered that were preventing the check for  
*this* issue from running.


> While this is annoying but still somewhat harmless, things get  
> really awry when you turn the event into a recurring event. Or more  
> explicitly:
>
> 1) Create new event as before and save it.
>
> 2) While editing the new event, delete the start and end date as  
> before. In the "Repeat" tab of the event, choose e.g. "repeat,  
> weekly, every week on Thursday." Click on "Save".
>
> This time, there is a warning in the lower right-hand corner that  
> says "Failed to parse time string (-001W49)" and the form is still  
> displayed. However, the changes _are_ saved to the database and  
> create havoc.
>
> For instance, if you now click "Cancel" on that overlay and then  
> click on the event again, all you get is an endless spinner.
>
> If you reload the page, no events from this calendar are displayed,  
> just the "Failed to parse time string" error message still appears.  
> There is no way around this, i.e. if you log out and log in again,  
> the problem persists. You have to manually delete that event from  
> the database. That's the really bad part here.
>
>
> However, I am a bit surprised that - as per the previous fix - this  
> is checked only on the client side. Shouldn't there be a server side  
> check to make sure that events with invalid characteristics (such as  
> missing date) will not be stored?

There is now, though it should never be triggered.




-- 
mike
The Horde Project
http://www.horde.org
https://www.facebook.com/hordeproject
https://www.twitter.com/hordeproject
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5751 bytes
Desc: S/MIME Signature
URL: <https://lists.horde.org/archives/kronolith/attachments/20160722/9cfe34ef/attachment.bin>