You are not logged in. Please login or register.
LuxCal Web Calendar → Posts by Roel
Haha, I'm glad there is google translate 
Please note that only users with Manager rights (or Admin rights) can approve events. Events that are not yet approved are only visible to the event owner and users with Manager or Admin rights.
I hope you will enjoy the calendar.
Roel
Hi Dan,
Thanks for your input!
The current import function is the iCal or CSV input. both are rather limited and do not fully match all LuxCal calendar fields. So when you would export all events in iCal format and thereafter import the iCal file again, certain data would be lost.
I will take some time (probably some months) to think about this.
If you are not using the Extra field 1 and 2 and want to get rid of these fields in the Event window, then you should go to the admin's Settings page and under Views, remove the figures 4 and 5 from all three Event templates (first item).
Kind regards,
Roel
Hi there,
If we would implement more event fields, we would indeed prefer to make the number of fields flexible and add another table to the database, but our main problem is that we must keep the possibility to upgrade from all previous calendar version. The calendar already has three "description" fields in the events table, of which at least two should then move to this new table. The biggest problem would be the upgrade script; it would become much more complicated.
If all LuxCal users would agree to start all over again from scratch . . . 
Roel
Hello W.S.
I see. Because it's a rather unusual host name, the URL parser apparently doesn't like it and flags it as invalid.
Please edit the file "common/toolbox.php" and on line 20 (starting with $rxCalURL) do the following:
Replace "localhost" (somewhere in the middle) by "[\w-]{2,10}host". No typing errors please
Since you are running a local server, you should set the calendar URL on the Settings page to srv-host/?cal=mycal. I don't think http:// is needed, but I'm not sure.
Please let us know if this solved your problem.
Best regards,
Roel
PS. I will also change this in the next LuxCal version, which is planned for 1 September.
Hi Stefan,
Yes, you are right, it's missing. I will add this to the next LuxCal version which is planned for 1 September.
Thanks for reporting this anomaly!
Roel
Hello W.S.
You should go to the admin's Settings page and under General set the Calendar URL to the real URL (http://www. etc.).
Best regards,
Roel
Highlights
This new LuxCal version 4.7.1 is mainly a bug-fix release with a number of cosmetic and other improvements.
Most important new features:
• Repeating events are now allowed when the event overlap check is enabled.
• The recipients field for email and SMS messages in the Event window and recipients lists in the reciplists folder may now also contain user names.
Hereafter you will find a full summary of all changes since LuxCal version 4.6.1 . . .
As usual this new release has been tested with the help of the experienced beta tester John from Denmark!
New features/Improvements
• Repeating events are now allowed when the event overlap check is enabled. If a repeating event has no end date, the overlap check will be performed for the next 24 months.
• The recipients field for email and SMS messages in the Event window and recipients lists in the reciplists folder may now also contain user names. The calendar will automatically convert these user names to an email address or a mobile phone number. File names of recipients lists in the recipients field in the Event window must now be put between square brackets, to avoid confusion with user names.
• Cosmetic change: The forward and backward buttons in the date picker header have been replaced by the same symbols (black triangle) as used in the calendar.
• Cosmetic change: In the calendar views, the left arrows to open the date picker and time picker have been replaced by calendar and clock symbols.
Technical issues
• When upgrading the calendar, existing user groups will get the following thumbnail privileges:
- Admin: Manage all
- Manager: Manage all
- Post all: Manage own / view all
- Post own: Manage own
- Read access: None
- No access: None.
• When two or more individual calendars were installed in separate folders on the same domain, users logged in in one calendar were sometimes automatically logged in in the other calendar(s) as well. The same kind of interference problems could occur with a single calendar installation with multiple calendars. The full session and cookie mechanism has been revised to fix this problem.
• MySQL version only: During the upgrade process, when testing if the database credentials are present the test on password is removed, because installations on a local server may have an empty password.
• In the database table definitions the default thumbnail privileges is set to '00'. The previous value '01' was wrong and caused a PHP notice message.
• The three sidebars, To do, Upcoming and To Approve, could be moved outside the display area. If the left mouse button was released when the top of the sidebar was outside the viewport, the side bar could not be picked up again. Solved by allowing the sidebar to be moved within the viewport only.
• When on the Settings page the start time was set to 0 and the time format was set to AM/PM, the time picker was showing "00:00 00:15 00:30 00:45" on the first line, which is not correct. From midnight to 01:00, the times are "12:00AM 12:15AM 12:30AM 12:45AM". Furthermore the font-family has been changed to mono-space, to better align the columns in the time picker.
• Due to an error in the user name validation template, existing users could change their user name in any name, including characters like '<' and '>'. Template corrected.
• In email reminder messages the links to possible attachments were relative links and therefore attachments could not be opened from email messages. To solve this anomaly, we've changed the relative attachment links to absolute links.
• To simplify the code, at various places the PHP mktime function has been replaced by the strtotime function.
• The installation and upgrade script will check for a .htaccess file which blocks browser access to .cdb, .log and .txt files. If not found, a .htaccess file will be created or an existing .htaccess file will be updated.
• To cope with local installations, the regex for validating the calendar URL now also accepts host name *host, where * can be 2 - 10 alpha-numeric characters or _, or -.
• The function "logError" has been removed from both toolboxd.php files and has been replaced by the general function "logMessage" in the toolbox.php file.
Bug fixes
• Editing or deleting one occurrence of a repeating or multi-day event was not treated as an occurrence and resulted in updating or deleting the main event.
• When checking if dates are due for a notification message, a check for excluded dates produced a PHP notice. Excluded dates however, are already skipped by the retrieve function, so this check in notify.php was redundant and has been removed.
• MySQL version only: In the database's categories table the default time slot field defslot was of type TINYINT. Because of this the default event duration was limited to 127 minutes (2 hours and 7 minutes). We changed the field type to SMALLINT, which can hold 32767 minutes.
• When on the Settings page, under General "Send notification of calendar changes" is enabled, no notification was sent when deleting events. This has been corrected.
Roel
Hi Stefan,
Indeed for recurring events it is not possible to select "every 5th <weekday> of <month>".
This feature was requested before in November 2014 by a calendar user, so I looked back at what we discussed at that time and found the following . . .
Of course the software could be modified to allow for selecting the 5th weekday, but this could be very tricky. Suppose on the 3rd of November 2018 you would enter an event with a repetition "Every 5th Friday of each month". As of the 3rd of November, the first occurrence of a fifths Friday would be 29 March 2019. This could be very confusing; as soon as you would press the "save" button, the event would be kind of "lost". It would not be visible before the 29th of March 2019.
Another example: If in August 2018 you would enter an event with repetition "Every 5th Thursday of September it would even be worse. Once you press the save button, the event would not be visible until September 2021! So if you wanted to edit this event, you would have to go to September 2021.
For this reason we decided November 2014 to drop this request.
Roel
Hello Emilie,
Great, you've been digging in the code details
Yes, you are right in eventform0.php and eventreport.php the nom and nos parameters (nom => number of days before event to send a reminder email and nos => idem for SMS) are not added to the $evt array before calling the function makeE. However, the nom and nos parameters are only used by the makeE function if the template (2nd parameter in makeE function) contains a '6' and - and this is important - if a '6' is present in the last parameter 'show'.
In both cases, eventform0.php and eventreport.php, the last parameter of the makeE call does NOT contain a '6'! So in these cases the makeE function will never use the nom and nos parameters and therefore these parameters need not be present in the $evt array.
So it is intentional that in the eventform0.php and eventreport.php code the nom and nos parameters are not present in the $evt array.
(If makeE would use these parameters while they are not present, a PHP warning would be produced, which is not the case.)
Kind regards,
Roel
Hi Stefan,
It's all done in one JavaScript function. I'm not sure this can be easily changed. I will investigate what's possible.
Roel
Hi there,
Adding additional event fields has an impact on many of the calendar scripts and is quite a big change. We have currently no plans to increase the number of fields, but since more calendar users have asked for this, we should maybe change our plans.
Roel
Hi Bernard,
This is a bug in version 4.7.0. You can download a fix in this forum under "Known Issues and Fixes" (LuxCal 4.7.0 - Problem when editing one occurrence of repeating event).
Roel
Hi there,
Thanks for reporting this problem.
It can indeed be solved by changing the type of the defslot field in the categories table to SMALLINT.
The problem only applies to the MySQL version of the calendar. In the SQLite version the defslot field in the categories tables is INT.
This problem will be fixed in the next LuxCal calendar version 4.7.1.
Roel
Good guess, but not quite right
Thanks for reporting this problem.
I've posted a fix in this forum under Known Issues and Fixes.
Roel
In email reminder messages the links to possible attachments were relative links and therefore the attachments could not be opened from the emails.
To make the attachment links in email reminder messages absolute, so that attachments can be opened from the email messages, apply the following change.
Edit file common/toolbox.php and on line 228 replace . . .
href='./attachments/by . . .
href='".calRootUrl()."attachments/You can also download the changed toolbox.php file here.
Roel
Good point.
And since you've already given me the file and line number, it should be a piece of cake However, to make the attachment accessible from an email reminder, the change should be made somewhere else. I will see what should be done.
Where did you get this $calUrl? This is not an existing global variable, it's only used locally in the file messaging.php. We should use $set['calendarUrl'] and strip off the possible suffix "?cal=<calID>".
I will add this change to the next calendar version 4.7.1 and tomorrow, Belgium time, I will post a fix, for those who can't wait
Roel
Hi Stefan,
You are right. Neither bug nor feature
In LuxCal version 4.6 we introduced a user number, which could be specified when creating/editing a user account.
This user number however, was used nowhere and our plans to use it changed.
So in LuxCal version 4.7 we removed it again, because just entering a number which is never used does not make much sense.
I commented out the code to enter the number and left it, just in case we would need it later for the future "participation feature.
Roel
Hi Stefan,
In the calendar's index.php file the function "isMobile" is called and the return value is stored in the variable $isMob. The return values can be: 0: not mobile, 1: mobile tablet, or 2: mobile small display.
So if you do a global search with "$isMob" through all calendar files you will find the places where measures are taken to make the calendar more responsive.
(Just in case: To do global text searches, you could use the free application TextCrawler)
Roel
During his holidays Gérard has update and completed the French language files for LuxCal version 4.7.0.
The updated language pack can be downloaded on the Downloads page.
Roel
Ha ha, yes great question, why exactly at 3:15am? Actually it does not matter so much when lcalcron.php is started.
Since this file triggers the sending of email reminders for the day, it should start before the early rising calendar users open the calendar.
So why not start lcalcron.php just after midnight, or at 1:00am? Because various countries have Summer and Winter times (DST) and the DST change is not always at the same hour in each country. If you would start the lcalcron.php file for instance at 2:00am and at the end of the Summer at 2:00am the clock is set 1 hour back, during that night it will be 2:00am twice! This would then start the lccron.php script twice resulting in duplicate reminder messages.
So, to make a long story short, we said let's suggest 3:15am; this will not interfere with DST changes in the various countries and it's still early enough to send reminders for the day to come.
I hope this sufficiently explains the 3:15am mystery
Roel
Hi there,
That's a fair request and good suggestion.
So, yes, I will add this possibility.
It should not take too long to implement; if you are interested and send me your email address (via the Contact Us page), I will send you a changed file, with this option added, most probably within one week.
Roel
Hi there,
Currently selecting a calendar, in case of multiple calendars in one install, is only possible for users with administrator rights. This is done because for a certain user the rights for one calendar can be completely different from the rights for an other calendar. For instance if a certain user would have view or post rights in one calendar and would have no access rights in an other calendar, then if the user could switch to the other calendar, he/she would get the log-in dialogue (no Options Panel) and there would be no way back to the first calendar anymore.
As said by John in the other thread, we're planning to review the concept of multiple calendars (in one install and in different folder) for the next calendar version.
If this is not exactly what you meant, please let me know.
Roel
Hi Luigi,
Hmm, I did exactly the same, I created a user group Operators with exactly the same parameters as in your last post.
Then I created a user and assigned the user to the group Operators and thereafter I could create/edit events and I could also edit the events of other users. So it worked fine, as expected.
The error message 'no edit rights (event). Please log in.' should normally never appear. This error message only shows if something unusual happens.
Are you sure that the user Test can successfully log in? Is the user name Test displayed in the right upper corner of the calendar after log in?
Could you send me (via the Contact Us page) a link to your calendar and a temporary user account with admin or manager rights? I will then have a thorough look at what is happening.
Il tuo inglese è molto meglio del mio italiano
Roel
When running the file lcalcron.php via a cronjob, a PHP notice message may occur, saying "PHP Notice: Undefined index: xda in /home/eakpvwdu/public_html/kal.irweb/cronjobs/notify.php on line 39".
This PHP Notice issue was already reported "solved" in the latest calendar version 4.7.0, but for mysterious reasons the solution was not included in the V4.7.0 zip-file.
This PHP Notice has no detrimental effects on the functioning of the email reminder function, but if you want to solve the issue, then you can download the changed file here.
You can also fix this problem by applying the following changes:
Edit the file cronjobs/notify.php and replace lines 37 - 39 . . .
if ($evt['mde'] <= 1 and //first day
($daysDue == $evt['nom'] or $date == $todayD00) and //email due
!($evt['r_t'] and strpos($evt['xda'],$date))) { //date not excluded if repeating eventby . . .
if ($evt['mde'] <= 1 and //single day event or first day of multi-day event
($daysDue == $evt['nom'] or $date == $todayD00)) { //email dueand replace lines 93 - 95 . . .
if ($evt['mde'] <= 1 and //first day
($daysDue == $evt['nos'] or $date == $todayD00) and //SMS due
!($evt['r_t'] and strpos($evt['xDates'],$date))) { //date not excluded if repeating eventby . . .
if ($evt['mde'] <= 1 and //single day event or first day of multi-day event
($daysDue == $evt['nos'] or $date == $todayD00)) { //SMS dueUse cut and paste!
Roel
Hi Mike,
Thanks for reporting this error.
The PHP Notice issue was already reported "solved" in the latest calendar version 4.7.0, but for mysterious reasons the solution was not included in the V4.7.0 zip-file.
Coincidentally this PHP Notice has no detrimental effects on the functioning of the email reminder function.
Nevertheless I have posted the solution under Known Issues and Fixes.
Roel
LuxCal Web Calendar → Posts by Roel