Calendar Admin Settings

Calendar Admin Settings

by Mike Churchward -
Number of replies: 2
Picture of Core developers Picture of Plugin developers Picture of Testers

I propose that we add administrative setting features to the calendar feature as follows:

  1. Site-wide preference setting for first day of week, upcoming events maximum and look-ahead.
  2. Setting for whether user can change any of these.
  3. Event-type settings for each event type (site, course, group, user) as follows:
  • event type enabled/disabled - whether that event type is allowed for site,
  • event type can be filtered - whether or not that event type can be filtered by a user (this may not be useful)
  • user level to set event type (admin, creator, teacher, student, guest)

We could add this to the admin features for the site under the configuration settings.

Thoughts?

mike

Average of ratings: -
In reply to Mike Churchward

Re: Calendar Admin Settings

by John Papaioannou -

Thoughts (thinking as I write):

  1. That is easily configurable if you just edit lib.php and change the define()s. Isn't it overkill to add another level of settings? If there's a user setting use it, or else if there's an admin setting use it, or else use the default value from the file (which is editable?)
  2. Why? After all, it's a personal setting. For interface simplification?
  3.  
  • First of all, what did you have in mind that would benefit from this functionality? Second, before allowing disabling of event types, we need to think about the activity modules that are going to be automatically setting events (course and group, maybe user too). What should they do if that event type is "forbidden"?
  • First question still stands. I can understand the proposal to just "lose" a filter if we have disabled an event type entirely, but otherwise why?
  • OK for that one, I can imagine it might be useful.

We 'll have to see what Martin about this being added in the global config settings, though.

Jon

In reply to John Papaioannou

Re: Calendar Admin Settings

by Mike Churchward -
Picture of Core developers Picture of Plugin developers Picture of Testers

Jon -

  1. For this, where it really comes into effect is if you use the calendar on a page that doesn't require a login. For example, the home page. Editing a php file isn't something everyone is comfortable doing, so I figured a setting somewhere would be more natural.
  2. I don't have a good argument for this one, so if no one else thinks its useful, I'd drop it.
  3. - Disabling the event types is a selfish request. If we add the settings, I don't have to maintain my code changes. I need to do it for my site (which I did by hacking the code), but I figured if I needed it, others might too. If we use this setting, activity modules would have to respect it too.
    - Not sure about the second. I would forget it.
    - Agreed.

mike