Uploaded image for project: 'Confluence Data Center'
  1. Confluence Data Center
  2. CONFSERVER-81477

Team Calendar does not return expected records from DB

XMLWordPrintable

      Issue Summary

      This is reproducible on Data Center: yes

      Team Calendar 7.3.21, which is bundled in Confluence 7.18

      While Confluence displays an expected list of calendars via the "Add Existing Calendar" option (accessible from the ... > Add Calendar), it's unable to add a selected calendar as a subscription.

      Team Calendar cannot return the correct calendars for certain UUIDs even though they exist in the DB. This issue is related to certain UUID values containing multiple digit-only segments. An example UUID may look like: 3d1cf4df-0816-4429-8409-123asdfasdf. This causes certain calendars to be inaccessible to certain users or groups of users. It can also cause affected calendars to be uneditable. This bug only relates to calendars in some way associated with an affected UUID, either themselves having an affected UUID, or being in a parent-child relationship with an affected UUID.

      Affected UUIDs are evaluated as an arithmetic operation during the query, transforming the UUID in the process. Because the new UUID does not exist, the query fails.

      Steps to Reproduce

      1. Go to team-calendars/src/main/java/com/atlassian/confluence/extra/calendar3/calendarstore/AbstractCalendarDataStore#filterSubCalendarIds. Hard code the above ID into the QueryDSL block where the Query is built.
      2. Build and install the plugin
      3. Turn on logging for com.mysema.query.sql
      4. Go to "MyCalendar" page from the top bar.
      5. Check the "where" part of the SQL query generated. 

      Expected Results

      Querying ID of 3d1cf4df-0816-4429-8409-123asdfasdf

      Actual Results

      3d1cf4df-13654-123asdfasdf 

      Workaround

      There's no definitive workaround for this bug. However, it's possible to forcefully recreate the affected user's subscriptions in an attempt to get an unaffected ID (an ID without multiple consecutive digit-only segments).

      Remember to generate a backup from your database before performing any changes in case the workaround is not successful and you need to roll back.

      1. First, we should generate an up-to-date backup of the user's Calendar data by saving the current calendar subscription information for this user on a .csv file:

      SELECT * FROM user_mapping WHERE lower_username = '<username>';
      
      SELECT * FROM OS_PROPERTYENTRY WHERE entity_name = 'USERPROPS-<user_key_from_query1>' AND entity_key = 'calendar';
      
      SELECT * FROM "AO_950DC3_TC_SUBCALS" WHERE "CREATOR" = '<user_key>' AND "SUBSCRIPTION_ID" IS NOT NULL;
      

      2. Shutdown Confluence

      3. Next, we will delete all data regarding their Calendar subscriptions:

      DELETE FROM OS_PROPERTYENTRY WHERE entity_name = 'USERPROPS-<user_key_from_query1>' AND entity_key = 'calendar';
      
      DELETE FROM "AO_950DC3_TC_SUBCALS" WHERE "CREATOR" = '<user_key>' AND "SUBSCRIPTION_ID" IS NOT NULL;
      

      4. Start Confluence

      5. Last, we should ask for the user to manually resubscribe to the calendars through the UI.

      • If the user encounters an error when attempting to subscribe to calendars, it might be necessary for them to create a calendar first, and then attempt to subscribe to existing calendars again.

      As mentioned before, there is a possibility that the new IDs generated contain multiple consecutive digit-only segments and will still be affected by the bug, rendering this workaround uneffective. 

        1. 1.png
          1.png
          38 kB
        2. 2 - view calendars.png
          2 - view calendars.png
          17 kB
        3. 3 - query preview.png
          3 - query preview.png
          23 kB

              5e496a614b63 Diclehan Erdal
              8b5c2ab424ac Jing Zheng
              Votes:
              2 Vote for this issue
              Watchers:
              14 Start watching this issue

                Created:
                Updated:
                Resolved: