End date before Start date when using periods?

[jberanek]

We are using MRBS for some years now, but after updating to 1.6.1 there is some strange behaviour. We are using periods, by the way. When a user wants to enter a booking the end date is one day before the start date, disabling the Slot selectors and also effectively prevents the use of $multipleday_allow=FALSE. After correcting the end date the end slot selector defaults to the last period of the day, which is undesirable: I would rather have the end slot be the same as the start slot by default.

In the old version (1.2.3+) the use of periods worked flawlessly ... Is this a bug or am I miconfiguring somewhere??

Reported by: *anonymous

Original Ticket: mrbs/bugs/386

[jberanek]

I think this is a bug. There have been a number of fixes in this area since 1.6.1. Can you try updating to the latest version of the code in the default branch and see if you still see the problem. You can get the code here. Treat it like an upgrade.

Original comment by: campbell-m

[jberanek]

Tried the upgrade, database got updated, but after that got a 500 error returning to the main page, so had to roll back... Frustrating!

Original comment by: *anonymous

[jberanek]

OK, I will take a look (at both problems). Do you know what the 500 error was? Anything in the error log?

Original comment by: campbell-m

[jberanek]

Sorry, my fault ... forgot to import my homemade AD auth module ... Now it is working, and the bug is gone! Thanks for your input, and keep up the good work: MRBS is a great piece of software!

Original comment by: *anonymous

[jberanek]

Good, glad it is working. By the way, one new feature you get with the latest software that you may be interested in is the ability to define different periods for each area.

Original comment by: campbell-m

[jberanek]

One more question: where can one set $multiday_allowed ? I tried setting it in config.inc.php, but that doesn't work ... I can only get it to work by hacking it into the create_field_entry_end_date function, but that is not the way it supposed to work, I assume?!

Original comment by: *anonymous

[jberanek]

The config setting is

$auth['only_admin_can_book_multiday'] = false;

Original comment by: campbell-m

[jberanek]

Thanks, that did it. Found another minor bug: when logged in, the text above the logout-button reads "You are 1" , no matter who is logged in. Otherwise everything is working fine now!

Feature request: is it possible to incorporate the settings max_booking_date and min_booking_date somewhere in the GUI (area settings?), so that an admin can set these without server access? In our situation the people responsible for the school timetable would be the ones to set these dates and they are not to be trusted on the server cli ... :-)

Original comment by: *anonymous

[jberanek]

I can't reproduce the "You are 1" problem. It may be to do with your AD auth module?

I'll have a think about those two config settings. I think they are probably going to be global settings rather than area settings (if they are area settings you'll have to keep on changing them for every area). In which case they'd need a config GUI, which we don't have at the moment.

Original comment by: campbell-m

[jberanek]

Unless something changed in the handling of user names between the auth modules and the rest of the system it should not be the modified AD module; it worked just fine untill the last update to the 1.6.1+ version... I also noticed now that the user is not recognized anymore: a user can't change his/her bookings anymore and an admin is also not recognized as such ... Can it be a change in session handling???

Original comment by: *anonymous

[jberanek]

Yes, the session code has changed in the 1.6.1+ version. It sounds like the function getUserName() is not returning what it should be. What have you got $auth['session'] set to?

Original comment by: campbell-m

[jberanek]

$auth['session'] is set to php

Original comment by: *anonymous

[jberanek]

Ah, OK, I see the problem. Yes, you are right, the interface to the auth modules has changed. authValidateUser() should now return as follows:

/* authValidateUser($user, $pass)
 * 
 * Checks if the specified username/password pair are valid
 * 
 * $user  - The user name
 * $pass  - The password
 * 
 * Returns:
 *   false    - The pair are invalid or do not exist
 *   string   - The validated username
 */

Original comment by: campbell-m

[jberanek]

I solved my problem by using ldap authentication, so I don't need the custom mod anymore! Better so, this way there will be less things to remember when upgrading in future! Thanks for your input anyway!

Still hope there will be a GUI for setting max and min booking dates in future...:-)

Original comment by: *anonymous