6.0.0-git
2019-05-23

[#11359] Problem with Calendar Sharing
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 2012-08-17 (2470 days ago)
Due
Updated 2012-10-15 (2411 days ago)
Assigned 2012-09-30 (2426 days ago)
Resolved 2012-09-30 (2426 days ago)
Milestone
Patch No

History
2012-10-15 20:41:28 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
2012-09-30 21:41:30 Michael Rubinsky Comment #9
Taken from Jan Schneider
State ⇒ Resolved
Reply to this comment
Fixed for 3.0.18.
2012-09-30 21:36:00 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
2012-09-30 21:34:16 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
2012-09-30 20:54:38 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.
2012-09-11 11:00:03 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.
2012-08-30 19:26:35 Jan Schneider Comment #4 Reply to this comment

[Show Quoted Text - 9 lines]
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.
2012-08-30 16:36:53 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.


2012-08-30 16:29:45 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.
2012-08-17 10:39:43 Klaus (dot) Steinberger (at) physik (dot) uni-muenchen (dot) de Comment #1
Type ⇒ Bug
State ⇒ Unconfirmed
Priority ⇒ 1. Low
Summary ⇒ Problem with Calendar Sharing
Queue ⇒ Kronolith
Milestone ⇒
Patch ⇒ No
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.

Saved Queries