#252 edit_entry.php misshandling "faulty" repeats (and end dates)

Minor
open
nobody
None
1
2012-11-06
2012-11-06
Anonymous
No

Version: trunk
Go to week view and click on Monday 7.00
Set start/end date: 06.11./07.11.
Set start/end time: 7.00/9.00 (1 day 2 hours)
Select repeat: Daily
Set Repeat end date: 11.11. (just a couple of days later)
Save

Configuration above makes for the overlapping bookings. Observe the mess in the week view.
The same menace can also be caused with weekly/monthly/yearly repeat types.

A simple solution could be to limit the repeats to a single day bookings only.
After changing the repeat type from None to anything else, we could check if the start and end day differ. If they do not, grey out the end date and we're done. If they do, pop-up a message/alert informing user that this is not allowed and then gray out the end date (and set it to the start day).

Discussion

  • Campbell Morrison

    Thanks for spotting this.

    Alternatively another solution would be to allow the form to have such a booking, but reject it in edit_entry_handler.php if the duration is greate than the repeat interval? Then (a) the green tick would show a red cross and (b) if the user did press Save the booking would be rejected.

    This would have the advantages that it would work if JavaScript were disabled and also it would mean it would be easy to allow, for example, a booking lasting a week once a month.

    One could maybe enhance it with some JavaScript in due course to stop users selecting impossible bookings, but the edit_entry_handler solution above is certainly necessary and probably simpler.

    What do you think?

    Campbell

     
  • Comment has been marked as spam. 
    Undo

    You can see all pending comments posted by this user  here

    Anonymous - 2012-11-06

    I agree, the edit_entry_handler is both a better and a necessary solution.

    My quick thinking was based on a premise to stop the user in his doomed efforts as soon as possible. This leads us to a more general question (and probably a feature request): why is the save button not disabled if we have a red cross?

    We take the ignorant or unwary user one step too further before his booking is rejected. He then needs to go back and enter all the data again, instead of just changing the offending field.

    Because of the option to skip conflicting repeats? Is there anything else?

    We could, for instance, leave the button enabled in case a conflict is found in a series, but disable it in case of impossible bookings (as in this case) or conflicting no-repeat entries.

    What about the alert we get when we try to save a booking with start day > end day? Why not shove it also into the red cross? And disable the save button.

    So, to summarize, in case of any "going nowhere" bookings, disable the save button and display all messages "in" the red cross. In case of "resolvable" conflicts, such as skipping some booking in a series, leave the button enabled and, possibly, show an amber '!' instead of an 'X'.

    This seems more consistent than the current solution.

     
  • Campbell Morrison

    Thanks - good ideas. I'm tied up for the next few weeks but will make the changes when I get a chance.

    Campbell

     


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks