LuxCal Forum

The place for questions, suggestions and news about the LuxCal Event Calendar

User:   Password:   Remember Me?   
LuxCal Forum / LuxCal / Comments and Suggestions / Event repeat with exceptions
Posted:  26 Mar 2010 17:52
Just a "small" suggestion ;) I think it would be nice, if I could delete a single occurrence in a repeated event. E.g. our local choir will meet every Monday evening for practising. So I have entered this event to repeat every Monday evening. But on Easter Monday they will have a day off. So I have to end the event on the last Monday before Easter and start a new identical event on the first Monday after Easter.

In such a case it would be nice, if i could delete a single occurrence of an event without affecting the event before and after.
Posted:  26 Mar 2010 19:37   Last Edited By: Roel B.
Hello Lars,
As you may have seen in the What's New section of this forum, in version 1.9 I will try to improve the "repeat" capability. However your suggestion (which is a known problem) is rather difficult to implement. Currently a repetitive event is just one event in the database with an indication "repeat daily" or "weekly" or etc.
To make it possible to delete a single occurrence, this "exception" has to be remembered. If it would be only one exception, no problem. But if someone defines a weekly repeating event lasting for the full year and deletes 12 occurrences (holidays etc.) the calendar should remember 12 exceptions for this single event.
Soon I will start thinking in detail about this; hopefully I will get some bright ideas ;)
Posted:  29 Mar 2010 16:53
For what its worth, it appears that MS Outlook creates, i.e. copies, repeat events at time of creation (and manages accordingly during change) into single events that can be maintained individually. Maybe, it allows for individual event maintenance and copies only then the event to a new record, ignoring linked individual records from the series.
Anyway, I think, too, that this would be an important improvement to the app.
Posted:  29 Mar 2010 20:21
You need to think of extreme situations.  Suppose someone created an event that repeated every day, with no end date.  How many copies do you put into the database?  A years worth?  10 years worth?  That's 3650+ records to manage one event.  It seems like a better way to handle it would be to store exceptions.  Whichever way, I think it would be pretty complicated to manage (programatically).  I do agree that it would be a nice feature, though.
Posted:  29 Mar 2010 22:47   Last Edited By: Roel B.
Yes, this could be a bit tricky.
Expanding repeating events into multiple events should absolutely be limited to a maximum, otherwise someone could indeed enter an event that repeats every day for the coming 10 years or worse.
Posted:  14 Apr 2010 02:15
Another scenario as a practical application my wife came up with:
The calendar event when in the future is a planned event. When the event is due it becomes either obsolete or history, i.e. the event is actually happening. However it might not happen exactly as planned, e.g. it ends earlier or later, has moved to a different venue etc.
In our scenario it is an irregular job. Normally (planned) it is Monday and Thursday from 9am to 5pm in the main location. However, it usually does not end exactly as 'promised' i.e. usually overtime. Sometimes it is work at a different location (though that is not very important to us to track). And, yes, sometimes there is no work at all, e.g. on holiday mondays.
My idea is to have the opportunity to change an event and saving it as a single event, detaching it from the repeat event, like copying the event to a new item and shortening the original event to only future occurances. This however could cause issues if a past event has not been updated as a historical event, i.e. maintenance did not occur. In this case the latest update should be denied with the message pointing to past events prior to the recent event.

I hope this makes sense. And, I think this is so 'special' as a scenario (however useful to many) that it would be an example of turning this feature on and off (as I suggested elsewhere). I suspect, it would be a different type of repeat event, probably worth while selecting it specifically, either by prior selection of a certain flag (to create) or by a different mouse event, e.g. <control>-click.
Posted:  09 Apr 2011 15:53   Last Edited By: Gork
Another vote here...  Been searching for this ability over many different PHP based calendar applications and have only found it on one I've looked at.  But that one has issues I'm having a hard time dealing with, let alone paying for.

My specific issue, as an above poster, is that my job changes like crazy.  I may have a base schedule of, say, 11pm to 7am Sat through Wed, but may have specific days completely switched around.

I don't know about the back end part of the other calendar I looked at, but from my point of view it simply allowed me to detete one occurrence out of a repeated event.  I suppose a work around could to be allow the user to create multiple concurrent single entries at once.  It's far too much work for me to enter my schedule one entry at a time on the calendar, but if i could put a week's worth of concurrent entries in at once it makes it feasible.
Posted:  09 Apr 2011 17:41   Last Edited By: Roel B.
Hi Gork,
I know there is demand for this feature. Maybe I will give it another try, but it is not so easy.
Expanding repeating events into multiple single events is a possibility, but also has its down side:
- A weekly event for the whole year will result in 52 events. If you made a mistake and want to change or delete the weekly event, the software must know which events belong together and edit/delete 52 events.
- Should a birthday event (recurring annually) also expand in multiple single events? How many?
- Etc.
The charm of the LuxCal method is that multi-day and repeating events are just one single event in the database; easy to edit or delete. But, yes I know, it has its down side.
As said earlier, I will further analyze the problem and see if I can find a solution.
Posted:  09 Apr 2011 19:11   Last Edited By: Gork
Thanks for your attention.  I understand where you're coming from regarding the downside.  One thing I haven't seen implemented before, though, is to have the choice to create multiple separate events without having to enter each one separately.  It seems this would be relatively simple.

Instead of inputting an event on day 1, another on day 2 and another on day 3 with all the same description info I could tell the calendar to create the event three times over three days and choose to have it create separate events each time.  It would be nice to be given the choice which way to create an event.

In your example, if I needed 52 separate events created which were made up of the same descriptions I'd have to create 52 separate events manually so I'd be able to later edit each one separately.  But if i could check a box in the repeating event dialogue to tell the calendar to make each event a separate one, I could enter the event once and create 52 separate events.

I guess at that point if I made a mistake and created 52 separate events when I really wanted to create a single repeating event I'd just have to go back and delete, one at a time, 52 events...  I guess one could warn the user when clicking the checkbox to make the events separate, or the code might only allow such events to be created if they were one day after another - no "days off" between the separate entries.  Or perhaps this feature could be limited to allow only 20, or maybe even 10 separate entries to be created automatically in this fashion.  That way a "booboo" could not cause a huge headache or a problem with too long a loop in the code.
Posted:  10 Apr 2011 14:11
You probably hate it when someone chimes in like this, but perhaps you could make it optional.

Not as a global option, but a button or switch when a recurring event is created that says: "Create multiple events". This may warrant a warning that says "This will create 2,459 separate events. Continue/Cancel."

Perhaps it's only available when you edit an event, as a way to ensure that the initial recurring event is entered correctly.

Or the ability to select a specific incident of a recurring event, and "Convert to Single Event". This gets into exception rules, of course. There would have to be an "exception event" that somehow covers up the recurring event. That way the recurring rule is still valid, but the exception "hides" that instance of a recurring event. Like putting a Post-It (tm) note over top of one of the events.

Ooh! An "exception event" could split the recurring event. Say you have an event that repeats the first of every month. You enter it to start on May 1 and end on April 1 the following year. Then go to Jan 1 and enter an exception because it's a holiday. This creates three events:
1. Recurring from May 1 to Dec 1
2. Single Event on Jan 1.
3. Recurring from Feb 1 to April 1

Of course, less lazy users could manually do this by entering their recurring events in blocks around their exceptions. :D

Anyway, just trying to generate some ideas on how it could work. While I can see how some might find this useful, I can also see the programming headache that it creates.
Posted:  02 May 2011 05:59   Last Edited By: Gork
I've been thinking about this and want to share an idea I've come up with.  A few caveats:  1) I've only dabbled in programming (8-bit basic, old school Turbo Pascal etc), and the closest I've come to scripting is some VBA and batch file type stuffs; 2) The only database I've done anything at all with is MS Access; 3) I know nothing of the limitations of MySQL; 4) I have not yet installed LuxCal so I don't know how the database/tables are already set up; and 5) I know the tables I'm about to describe would need to be more complicated that what I describe, but I'm trying to keep it simple just to get my idea across.  So, please go easy on me - I'm certainly not trying to come across as in the same league as the developer(s) of LuxCal, let alone on the same planet.

What if events and occurences were separated into different tables?  The EVENT table would consist of a "KEY" column (I'm not familiar with the nomenclature, but I mean a "serial number" of sorts for each table entry which is not repeated) and an EVENT_COL column consisting of the event descriptions.  (For the sake of simplicity of describing my idea I'm leaving out any other entries which might need to be in this table.)

A separate OCCURENCES table would contain its own "KEY column," naturally, along with an EVENT_NUM column and a DATE column.  The EVENT_NUM column would coincide with the KEY column in the EVENT table.

For each row in the EVENT table, the number in the "KEY column" would be entered into the EVENT_NUM column of the OCCURENCES table with the corresponding DATE of the event.  For repeating events, the EVENT_NUM would be repeated in a separate row, along with its corresponding date in the DATE column.

So basically, this would create separate events for each entry of a recurring event, but link them all together.  That way you could easily update all entries of a recurring event, while having complete control to delete one entry of a recurring event without having to keep track of exceptions.

In addition, in order to edit a single occurence of a repeating event, the edit would cause that occurence to be deleted from the OCCURENCES table and created as a separate event in the EVENT table, with its own new KEY to be used in the EVENT_NUM column of the OCCURENCES table.

I hope this makes sense; I'm not the best writer ever.  I would LOVE to clarify if I need to and you're interested in this idea.  I can only assume this would be doable as I've described, based on my limited experience as previously noted.

I just realized this does not address your "birthday event" example.  I know this is a shallow thought; I haven't put the thought into this issue as I have the other.  But if a repeating event were created without a year in the date perhaps it could be handled differently. ??
Posted:  11 Jul 2011 06:48
Looks like you went with your initial idea to keep track of exceptions when a specific occurence of a repeating event is deleted or changed?  If, of course, you don't mind me asking...  What made you decide this wouldn't be as difficult/lengthy as you originally thought?  Just curious.

I love the way the new version, 2.5.0, works...  I just finished moving all my data from a Wordpress addon to a first install of LuxCal.  I'm with the others who have posted a willingness to provide a little financial support - for servers, electricity, whatever...
Posted:  11 Jul 2011 18:02   Last Edited By: Roel B.
Hi Gork,

I don't mind you asking, on the contrary; it's actually nice if users show interest ;)

When I started thinking about what had to be done to implement the current solution (delete the occurrence: store the exception / edit the occurrence: store the exception and create a new event), I came to the conclusion that almost all required ingredients were already present. There was already a possibility to save an event as a new event, so the only two things to add was 1) storing the "exception date" and 2) when retrieving repeating events from the database skipping the "exception dates'.
The charm of this solution is that the concept is easy to understand and that a repeating/multi-day event with exceptions still takes only one record in the database.
A positive side-effect was that there was no reason anymore to have a separate 'events' and 'dates' table, which simplified the calendar.
Posted:  12 Jul 2011 08:12
Thanks for explaining your thought process.  After coming up with the idea I posted above I took a look at the database tables of other PHP based calendars which offer the same ability.  The few I looked at actually utilized tables the way I came up with, totally letting the air out of my tires.  I was so proud of the idea I had come up with! lol

I guess the only problem I see with your implementation is, if as you've noted before, there are a LOT of exceptions in one repeating event.  I don't know enough about the database system to know how much that would slow things down, but I'm sure there is a limit to the number of exceptions which can be stored in a single cell like that.

However, it won't ever be a problem for the way I use the software, so it works PERFECTLY for me!  My only issue is...  Now that I'm not using the Wordpress addon for my calendar anymore I'll probably totally slack off on my blog posts...  ;)
Posted:  12 Jul 2011 13:01   Last Edited By: Roel B.
Just to take your worries away ;)

Slowing down
Reading one additional row (the exception dates) from the same db table costs much less time than reading a second db table. So I claim my method is faster.

A limit to the number of exceptions
The exception dates are stored in a MySQL "text" field, which is variable length. So there is no limitation (ok, if one has 100 000 exceptions maybe).

Posted:  12 Jul 2011 17:47
Thank you so much for not having a problem with this discourse, I find it very interesting.  I now think I completely understand why you went the direction you did!  I wish I would get off my rear and learn some of this stuff - I find it fascinating.
Posted:  15 Jan 2012 13:11
If you have downloaded the latest (out of date) version from sourceforge, this is implemented in the latest version! (since 2.5)