6.0.0-git
2021-01-18

[#4054] Allow site admin to control whether shares can be shared
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 2006-06-19 (5327 days ago)
Due
Updated 2007-06-28 (4953 days ago)
Assigned 2007-06-28 (4953 days ago)
Resolved 2007-06-28 (4953 days ago)
Milestone Horde 3.2
Patch No

History
2007-06-28 18:00:16 Chuck Hagenbuch Comment #9
State ⇒ Resolved
Reply to this comment
Implemented.
2007-06-28 17:24:19 Chuck Hagenbuch State ⇒ Assigned
 
2007-06-24 23:58:08 Jan Schneider Comment #8 Reply to this comment
Sounds good.
2007-06-24 03:51:42 Chuck Hagenbuch Comment #7
Assigned to Horde DevelopersHorde Developers
State ⇒ Feedback
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?
2006-09-20 17:43:12 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.
2006-09-20 17:41:52 Chuck Hagenbuch Deleted Original Message
 
2006-09-20 17:41:45 Chuck Hagenbuch Comment #5
Version ⇒ HEAD
Queue ⇒ Horde Base
Reply to this comment
Moving to a general ticket
2006-06-21 07:14:16 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).
2006-06-21 07:06:16 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.
2006-06-21 03:30:05 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.
2006-06-19 11:01:27 okuhl (at) netcologne (dot) de Comment #1
Type ⇒ Enhancement
State ⇒ New
Priority ⇒ 2. Medium
Summary ⇒ Disabling shared calendars
Queue ⇒ Kronolith
New Attachment: disable_shared_calendars.patch
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.

Saved Queries