Uploaded image for project: 'Confluence Cloud'
  1. Confluence Cloud
  2. CONFCLOUD-51174

Ability to restrict which groups and/or users have access to Team Calendars

    • 1
    • 11
    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      NOTE: This suggestion is for Confluence Cloud. Using Confluence Server? See the corresponding suggestion.

      Our primary Confluence instance is used by our employees and some of our business partners. Partners have varying levels of access within Confluence, depending on the nature of the business relationship.

      Currently, Team Calendars is available to any logged in user and by default any new calendar is available to all users. It's great that it's possible to set view and edit restrictions on individual calendars, but it's difficult to ensure that users across the company will put the proper security on calendars they create.

      We would like to be able to restrict Team Calendars access (in its entirety) to specific groups and/or users, similar to Global Permissions in Confluence. This would allow us to specify that only employees and select partners have access to Team Calendars and reduce concerns around accidentally sharing information too broadly.

            [CONFCLOUD-51174] Ability to restrict which groups and/or users have access to Team Calendars

            MichaelO added a comment -

            @sluthra@atlassian.com  LOL......

            MichaelO added a comment - @ sluthra@atlassian.com   LOL......

            Hi everyone,

            Thanks for participating in this issue, either by voting, commenting or just watching. We highly value your feedback in all forms, and through suggestions in jira.atlassian.com is not different. We use this channel to learn the best we can with how customers use JIRA and how we can continue to improve the experience for as many users as possible.

            We understand that resolving this problem is important for you. At the moment we don't have any plans to implement it. We will update this ticket when we make any progress in this direction.

             

            Thanks,

            Shrey Luthra

            Product Manager, Confluence Cloud

            Shreshth Luthra (Inactive) added a comment - - edited Hi everyone, Thanks for participating in this issue, either by voting, commenting or just watching. We highly value your feedback in all forms, and through suggestions in  jira.atlassian.com  is not different. We use this channel to learn the best we can with how customers use JIRA and how we can continue to improve the experience for as many users as possible. We understand that resolving this problem is important for you. At the moment we don't have any plans to implement it. We will update this ticket when we make any progress in this direction.   Thanks, Shrey Luthra Product Manager, Confluence Cloud

            JIRA admin added a comment -

            +1 Needed feature!

            JIRA admin added a comment - +1 Needed feature!

            Hi all

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

            Thanks.

            Gonzalo Benítez added a comment - Hi all We have the same legal problem that Ankur Mehrotra. I would appreciate you could prioritize this issue Thanks.

            Craig added a comment -

            This is of great importance to us as well.

            Craig added a comment - 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

            Ankur Mehrotra added a comment - 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

            Patrice Foerster added a comment - 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

            ctdditdivision added a comment - Hi Martin, Thank you for sharing that. I hadn't thought of that approach. Have a great day, Scott

            Martin Moser added a comment - - edited

            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 Moser added a comment - - edited 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

            ctdditdivision added a comment - 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

              Unassigned Unassigned
              a11b0168bce9 Paul Boyum
              Votes:
              131 Vote for this issue
              Watchers:
              96 Start watching this issue

                Created:
                Updated: