Tickets :: [#11359] Problem with Calendar Sharing

6.0.0-beta1

7/6/25

Summary	Problem with Calendar Sharing
Queue	Kronolith
Queue Version	3.0.17
Type	Bug
State	Resolved
Priority	1. Low
Owners	mrubinsk (at) horde (dot) org
Requester	Klaus.Steinberger (at) physik (dot) uni-muenchen (dot) de
Created	08/17/2012 (4706 days ago)
Due
Updated	10/15/2012 (4647 days ago)
Assigned	09/30/2012 (4662 days ago)
Resolved	09/30/2012 (4662 days ago)
Github Issue Link
Github Pull Request
Milestone
Patch	No

10/15/2012 08:41:28 PM	Git Commit	Comment #10	Reply to this comment
Changes have been made in Git (develop): commit 2ffcf0c524c76a47d7615c12fd54a0959e34d872 Author: Michael J Rubinsky <mrubinsk@horde.org> Date: Sun Sep 30 17:28:49 2012 -0400 Fix setting permissions in dynamic mode while conf[share][world] == false ~~Bug: 11359~~ kronolith/js/kronolith.js \| 20 +++++++++++++++----- 1 files changed, 15 insertions(+), 5 deletions(-) http://git.horde.org/horde-git/-/commit/2ffcf0c524c76a47d7615c12fd54a0959e34d872

09/30/2012 09:41:30 PM	Michael Rubinsky	Comment #9 Taken from Jan Schneider State ⇒ Resolved	Reply to this comment
Fixed for 3.0.18.

09/30/2012 09:36:00 PM	Git Commit	Comment #8	Reply to this comment
Changes have been made in Git (FRAMEWORK_4): commit 293e8ce0e6f8b0b8a35d6d48029188424ff6bf97 Author: Michael J Rubinsky <mrubinsk@horde.org> Date: Sun Sep 30 17:28:49 2012 -0400 Fix setting permissions in dynamic mode while conf[share][world] == false ~~Bug: 11359~~ kronolith/js/kronolith.js \| 20 +++++++++++++++----- 1 files changed, 15 insertions(+), 5 deletions(-) http://git.horde.org/horde-git/-/commit/293e8ce0e6f8b0b8a35d6d48029188424ff6bf97

09/30/2012 09:34:16 PM	Git Commit	Comment #7	Reply to this comment
Changes have been made in Git (master): commit 2ffcf0c524c76a47d7615c12fd54a0959e34d872 Author: Michael J Rubinsky <mrubinsk@horde.org> Date: Sun Sep 30 17:28:49 2012 -0400 Fix setting permissions in dynamic mode while conf[share][world] == false ~~Bug: 11359~~ kronolith/js/kronolith.js \| 20 +++++++++++++++----- 1 files changed, 15 insertions(+), 5 deletions(-) http://git.horde.org/horde-git/-/commit/2ffcf0c524c76a47d7615c12fd54a0959e34d872

09/30/2012 08:54:38 PM	Michael Rubinsky	Comment #6 Assigned to Jan Schneider Assigned to Michael Rubinsky State ⇒ Assigned	Reply to this comment
I can verify this also happens in master.

09/11/2012 11:00:03 AM	Klaus (dot) Steinberger (at) physik (dot) uni-muenchen (dot) de	Comment #5	Reply to this comment
I'm still not certain. Do you mean that the calendar permissions that you set in the calendar dialog are not saved? Are the permissions empty, if you open the dialog again? Yes, at least in the simple permission sight it is empty. A third open even does not work, the dialog doesn't pop up, If yes, is this limited to a one view mode? Do you get any PHP warnings or notices in the logs? No warnings or notices. I verified it again, it is definitly related to $conf[share][world] also the user must be normal user without admin rights (as the admin user always has the right to share with world). I verified it also on a different horde installation which has only a few accounts and groups and no LDAP, so it is not related to the authentications system.

08/30/2012 07:26:35 PM	Jan Schneider	Comment #4	Reply to this comment
[Show Quoted Text - 9 lines][Hide Quoted Text] I'm not sure what you mean with this: sharing set in the dynamic view will not be permanent, after the second try even the window does not open again, until a logout. It means that the sharing will probably never set. The second try to open the calendar settings will never succeed. After a logout and login again, the settings can be opened again, but no sharing could be seen, even if it is set through traditional view. I'm still not certain. Do you mean that the calendar permissions that you set in the calendar dialog are not saved? Are the permissions empty, if you open the dialog again? If yes, is this limited to a one view mode? Do you get any PHP warnings or notices in the logs? If sharing to world is allowed anything works as expected, though we do not want to allow users to share against world.

08/30/2012 04:36:53 PM	Klaus (dot) Steinberger (at) physik (dot) uni-muenchen (dot) de	Comment #3	Reply to this comment
I'm not sure what you mean with this: sharing set in the dynamic view will not be permanent, after the second try even the window does not open again, until a logout. It means that the sharing will probably never set. The second try to open the calendar settings will never succeed. After a logout and login again, the settings can be opened again, but no sharing could be seen, even if it is set through traditional view. If sharing to world is allowed anything works as expected, though we do not want to allow users to share against world.

08/30/2012 04:29:45 PM	Jan Schneider	Comment #2 State ⇒ Feedback	Reply to this comment
I'm not sure what you mean with this: sharing set in the dynamic view will not be permanent, after the second try even the window does not open again, until a logout.

08/17/2012 10:39:43 AM	Klaus (dot) Steinberger (at) physik (dot) uni-muenchen (dot) de	Comment #1 Patch ⇒ No State ⇒ Unconfirmed Milestone ⇒ Queue ⇒ Kronolith Summary ⇒ Problem with Calendar Sharing Type ⇒ Bug Priority ⇒ 1. Low	Reply to this comment
I'm not sure if the problem is in kronolith, or in the underlying framework Sharings of calendars do not work in the dynamic view under the following condition: In the horde config is set: $conf['share']['world'] = false; The symptom is the following: sharing set in the dynamic view will not be permanent, after the second try even the window does not open again, until a logout. Anything works well when we set: $conf['share']['world'] = true; But as we have a real large user base, we want to block users from sharing to anybody.