It is a bad joke that this was requested 5 years ago and such basic but needed functionality has not yet been implemented.

Hi all, 

you may test this thirparty plugin to restrict URLs and restrict access to the calender: 
URL Restrictions for Jira: https://marketplace.atlassian.com/1217092**

Best Regards
Domenico 

I would be glad, if Restrict by Groups were working. I am only able, to restrict by single users. Do you have any idea how to restrict Calendars by Group?

I hope I'm reading this correctly - that we will be able to configure a global setting such that all new calendars created will be, by default, private.

Hi,

I confirm; it should be a "must have"

Hi all

We have the same legal problem that Ankur Mehrotra. I would appreciate you could prioritize this issue

Thanks.

This is of great importance to us as well.

Hi Team

Please can you prioritize it urgently, as it has a Legal Impact when one Client is able to see the Calendars of other Clients

Hi Atlassian,
what's the status of this issue? Does someone of you look into this?
This permission configuration is a must-have.

You can't expect that everyone has to work around this missing permission like Martin Moser did.
This adds additional complexity, maintenance effort and consquently delays upgrades to newer versions

Hi Martin,

Thank you for sharing that. I hadn't thought of that approach. Have a great day,

Scott

Hi Scott,

here's the short of it (thanks to our tech guys): it works through a new servlet filter that checks the group of the user accessing the URL through which a calendar gets created per POST. If that user isn't in the required group, the POST is cancelled and an error message with further instructions is displayed (you can touch the error message up by adjusting the return format to Team Calendars). Make sure the new servlet filter gets called at the right time in the filter chain and you're done.
It adds the overhead of additional user management and support of course. I think we should be allowed to countercharge that cost against our Team Calendar license fees, actually

HTH
Martin

Martin,

May I inquire as to how you did this -> "FWIW, we changed the calendars so that only a certain group of users is able to create calendars. Others get a message who to contact when they click create. This group then sets the right permissions for the requester to make sure to plug this security hole and educate them about this bug and how to work around it."

Is it a customization you can share?

Thanks,

Scott

FWIW, we changed the calendars so that only a certain group of users is able to create calendars. Others get a message who to contact when they click create. This group then sets the right permissions for the requester to make sure to plug this security hole and educate them about this bug and how to work around it. I guess the situation won't change, the issue is unchanged since 1.5 years+. In the case of calendars I am sorry to say Atlasssian took the money and ran, see the earlier comments.
Another problem is that your vote on this or any other issue always only is one vote, regardless of whether you represent 30000 users (as in our case) or 8. Atlasssian (or the Atlasssian ambassador I talked to did, at least) once talked about changing that (1-2 years ago), but apparently nothing ever came of it.

Having done some testing with Team Calendars being tied to spaces, this new setup does offer some minimal level of security. But, we really need to get more control of calendar permissions. Controlling Add/remove/modify calendars and events on individual calendars within spaces needs to be in place sooner than later

when will this be implemented?

hyalamanchili we're tracking that suggestion here: TEAMCAL-2442

We had a recent security incident where one client was able to view and get notifications for events unrelated to them. It came as a shock to the enterprise that paying as much we do, we can't even restrict Calendars to per space by default.

If putting additional feature in place is a huge development task the least Atlassian can do is enable this feature:
Have calendars be created by default with the permissions of a particular space

This is a serious security Bug and not an improvement/feature request and should be re-classified as such.

it's wasting time to wait for such important things from atlassian....we are looking currently for alternatives.

+1

Any clue as to when this feature will be developed and released. This is an essential feature for us as well and in all honesty it is also a basic feature.

I second that. The lack of global permissions (or something similar) for team calendars render them pretty much useless in a multi tenancy environment.

Agree that there should be more broad/global access to restrictions and or viewers.

We really need to be able to globally restrict calendar access. individual users cannot be trusted to create proper restrictions

Same request. I would give up team calendar by the end of th eyear if there is no possibility to restrict the entire addon for a specific user/group.

yeah, we have exact the same request!
And related to the price of this plugin it is poor to have not a useful user-configuration

Would love an update to have calendars at minimum inherit a default set of permissions similar to how Confluence now has default space permissions. Still would be better to have Calendars linked to space permissions long-term.

Martin has spelt out all the things that I'd like addressed, good job Martin. Key question is when this issue will move from Open to In Progress. Enterprise clients need these points addressed ASAP for it to be taken seriously as a viable, valuable plugin.

I have already voted for this issue, however I thought it was also worth noting that we have the same problem as the other commenters on this issue. We have many disparate groups who use our spaces that do not interact with eachother. The previous free plugin worked well as it inherited the containing space's permission schemes. The fact that new calendars can be 'linked' to a space, yet not inherit any of the permissions is very bizarre.

We purchased an unlimited license for this plugin with the assumption that it would improve upon the old plugin. If we had known about this issue before the purchase we would have not gone ahead with it. We are now stuck with an expensive plugin that we cannot install.
Our userbase is not going to be happy when they lose their calendar funcitonality due to this issue...

I concur with @Martin. We have a variety of user types that access our instance and, for security purposes, need our defaults to be restrictive to just our employees without relying on each user to remember to set restrictions.

Hi Sherif,
thanks for your comment: Our setting is that we have a Confluence instance that is accessible to employees, partners and customers. I do not have any management tools at hand that allow me as an administrator to restrict the usage of calendars to any one (or more) usergroups. In other words if an employee creates a calendar and forgets/neglects to set the proper restrictions this information will not only be visible to every user, they also can manipulate or delete that calendar. In other words leaving security settings solely to the individual user through the concept of restrictions is totally unacceptable in an enterprise setting IMHO.

So, as a confluence administrator I expect the possibility

• to define which user group(s) can create calendars
• to set default restrictions for all calendars globally (e.g. calendars are auto-restricted to group "employee" on creation).
  An alternative (or combined even?) approach would be to make it mandatory to "assign" a calendar to a space so that the calendar then inherits that space's premission scheme.
  Cheers!

martin moser, thanks - can I just confirm your understanding is right, this issue may be poorly named. You can already apply restrictions to calendars so that only specific users can see it. This has been available since 1.3. This specific issue is for the site admin to be able to hide team calendars completely from a group or set of users. So in your scenario, do you want to hide the whole of team calendars completely from some users? Whats the example of this? Sorry just trying to confirm understand and ensure that the wording of the issue is clear.

Because of the latest security patch by Atlassian for Confluence version 3.5 we have to switch to Team Calendars. Now we are gong to pay 6000.- for something that was free before to find that we can't even properly manage access to the calendars (don't give me the "you can do it per calendar" thing!)? How can you bring out a commercial plugin that ignores permissions in a enterprise software!?
This bug (it's a bug in my eyes, not an improvment!) is open for 1.5 years already. I'm a big fan of Confluence but things like that put me very much on the defensive internally. Atlassian needs to recognize what enterprises need if it sells enterprise licenses. When will we see action here?

I'de like to second this

We have the same issue. Voted.

TEAMCAL-536 is a good start, but security administration is too hard. I can see how making it live outside of a page makes calendars more easy to discover and aggregate but this forces users into applying a whole new security setting outside of what Confluence already has.

We have a very similar situation. Our Confluence instance is shared by employees, partners and clients. At all costs we must avoid having information from one client visible to users from another client - and this includes the calendars. Currently any new calendars that get created are visible by default to all wiki users.

While we can educate our users, there's still a risk that someone forgets to set the permissions for a calendar.

A couple of suggestions:

• Restrict the ability to create fully public calendars to administrators
• Have calendars be created by default with the permissions of a particular space