Tickets :: [#4054] Allow site admin to control whether shares can be shared

6.0.0-alpha14

7/3/25

Summary	Allow site admin to control whether shares can be shared
Queue	Horde Base
Queue Version	HEAD
Type	Enhancement
State	Resolved
Priority	1. Low
Owners	Horde Developers (at)
Requester	okuhl (at) netcologne (dot) de
Created	06/19/2006 (6954 days ago)
Due
Updated	06/28/2007 (6580 days ago)
Assigned	06/28/2007 (6580 days ago)
Resolved	06/28/2007 (6580 days ago)
Milestone	Horde 3.2
Patch	No

06/28/2007 06:00:16 PM	Chuck Hagenbuch	Comment #9 State ⇒ Resolved	Reply to this comment
Implemented.

06/28/2007 05:24:19 PM	Chuck Hagenbuch	State ⇒ Assigned

06/24/2007 11:58:08 PM	Jan Schneider	Comment #8	Reply to this comment
Sounds good.

06/24/2007 03:51:42 AM	Chuck Hagenbuch	Comment #7 State ⇒ Feedback Assigned to Horde Developers	Reply to this comment
My proposal for this is to add $conf['shares']['no_sharing'] to Horde's settings now that we have that section. I'm not generally in favor of negative config settings/parameters/etc., but this way we can check it with a !empty() in kronolith/turba/nag/mnemo and be fully backwards compatible. If this setting is turned on, we simply won't let the user edit permissions. We'll add a check to services/shares/edit.php for it as well. Any objections/additions/feedback?

09/20/2006 05:43:12 PM	Chuck Hagenbuch	Comment #6 Summary ⇒ Allow site admin to control whether shares can be shared Priority ⇒ 1. Low	Reply to this comment
(or whether shares are only available to the user that creates them no matter what). might want to also introduce a vhosting concept here to restrict sharing to just the user's vdomain.

09/20/2006 05:41:52 PM	Chuck Hagenbuch	Deleted Original Message

09/20/2006 05:41:45 PM	Chuck Hagenbuch	Comment #5 Version ⇒ HEAD Queue ⇒ Horde Base	Reply to this comment
Moving to a general ticket

06/21/2006 07:14:16 AM	Jan Schneider	Comment #4 State ⇒ Accepted	Reply to this comment
So there is a difference between HEAD and the recently released Kronolith 2.1.2 and you implemented this in the last 5 days? In 2.1.2 default_share removes the ability to create new calendars, but not the permissions button, what the attached patch provides. No, there shouldn't be a difference. I think there should be a difference between multiple calendars and shared calendars. Admins might want to allow multiple calendars, but not to share them - or the other way round. So I think it makes sense to create an option for each. I agree. But should have this consitently for all apps that support shares (Kronolith, Nag, Mnemo, Turba, Genie, Ingo).

06/21/2006 07:06:16 AM	okuhl (at) netcologne (dot) de	Comment #3	Reply to this comment
So there is a difference between HEAD and the recently released Kronolith 2.1.2 and you implemented this in the last 5 days? In 2.1.2 default_share removes the ability to create new calendars, but not the permissions button, what the attached patch provides. I think there should be a difference between multiple calendars and shared calendars. Admins might want to allow multiple calendars, but not to share them - or the other way round. So I think it makes sense to create an option for each.

06/21/2006 03:30:05 AM	Chuck Hagenbuch	Comment #2 State ⇒ Feedback	Reply to this comment
You can achieve what I believe is the same effect in HEAD by locking the default_share preference.

06/19/2006 11:01:27 AM	okuhl (at) netcologne (dot) de	Comment #1 Priority ⇒ 2. Medium Type ⇒ Enhancement Summary ⇒ Disabling shared calendars Queue ⇒ Kronolith New Attachment: disable_shared_calendars.patch State ⇒ New	Reply to this comment
I would like to disable shared calenders so that there is no possibility to edit the permissions for a users calendar. To achieve this, I added another configuration option and changed the UI accordingly. The patch is attached. Would be nice if this could make it into CVS.