RSS

LuxCal Forum

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

User:   Password:   Remember Me?   
LuxCal Forum / General / Problems / Multiple calendars switching users
Posted:  20 Jul 2012 17:40   Last Edited By: michael
Greetings!

On an internal site we have multiple calendars, each with their own directory and database, each with different prefixes.  The issue that we've noticed is that when you go from CalendarA to CalendarB, the logged in user is being switched to a different account.

Looking through the database, it seems as though the user_id is what is being tracked after login.  For example, on CalendarA I will login as an administrator with user_id 5.  On CalendarB, user_id 5 is a regular account with a different name and I get switched into it when I change pages.  Works both ways, if CalendarB logs in with the regular account and switches to CalendarA, they'll switch into the administrator account.

In addition, upon switching calendars, the calendar title will change to that of the one you logged in.


Any thoughts?

-Michael
Posted:  24 Jul 2012 16:29
Hi Michael,
Yes, that's true. You've explained the problem correctly in your post above.  It is caused by the fact that the user id is kept in a PHP session variable, which remains active during a certain time (max 1 hour normally). So if - on the same computer - you switch from LuxCal calendar A to LuxCal calendar B within one hour, the user id used in calendar A will be used to login in calendar B.

I can maybe solve this by keeping the combination of user id and calendar id (name) in a PHP session variable, so that the user id can be reset when the calendar id changes.
I will have to investigate how this can be done, in combination with the "remember me" option (cookie). It's too late to include this in the next LuxCal release (2.7.0). I will see if I can solve this in a next sub-release of 2.7.0.
Roel
Posted:  27 Jul 2012 20:01
Thanks for the information.  We've worked around it by assigning blocks of user ids to each calendar so none will overlap.
Posted:  07 Aug 2012 23:21
Along the same lines, going from Calendar A to Calendar B, Calendar B uses the view that you were on as well as keeping Calendar A's title.

Is this another issue with session variables and multiple calendars?
Posted:  08 Aug 2012 10:30
Yes, that's correct.
And there are more variables kept via the PHP session mechanism, like selected language, selected date, calendar settings.

I will investigate if I can solve this "interference" when using multiple calendars on the same computer.
Posted:  20 Sep 2012 11:27
Hi there,

me too experiencing the same...

The strange thing is that also the calendar view interfere from one calendar to the other and the settings also...

For example I set calendar A with a starting time of 8.
If I go to calendar B its settings are reverted to a starting time of 6. Ok, I set again my calendar B with a starting time of 9.

Now it's the calendar A settings that are reverted to the default starting time of 6... and so on...


Thanks,
Dzeta.
Posted:  22 Sep 2012 19:28
Hi Dzeta,

I assume you are referring here to the time defined on the admin's Settings page in the field "Start hour in Day/Week view"?

Interference for this setting between two calendars seems almost impossible. The values are stored in the settings table of the database and each calendar has its own database.

Are you sure you saved the settings after changing the start hour?
Roel
Posted:  08 Oct 2012 13:39
Hi Roel... Yes I am sure I had saved the settings.

A further check between a v2.6.1c install and a v2.7.0 and a v2.7.1 show this behaviour:

- 2.7.0 and 2.7.1 settings really interfere in a way such that both behave as per the latest settings saved
(i.e. when i save settings for 2.7.0 both 2.7.0 and 2.7.1 use this settings... )

- 2.6.1c and 2.7.0 (or 2.7.1) settings interfere with each other but also there is something not compatible between 2.6.0 and the other two so that after saving settings for 2.6.1c in 2.7.0 (or 2.7.1) the view is messed and obviously also the opposite way
(I suppose this is related to the fact that in 2.7.0 you introduced the end hour setting).

Thanks,
Giorgio.