Uploaded image for project: 'Commerce'
  1. Commerce
  2. COMMERCE-20

Reduce cache time for REST API license metrics.

XMLWordPrintable

    • Icon: Suggestion Suggestion
    • Resolution: Unresolved
    • Billing - Preview
    • None

    • 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.

      License Metrics is cached with a 7-day lifecycle and could be stale at the time of the call. This data cache time should be reduced to a few hours at best.

      Key points for change

      • Currently, only third-level support (Site admins) has access to license usage figures, creating inefficiencies and resource waste when non-admins need this information.
      • License usage data retrieved via the REST API is not fully accurate, which limits timely adjustments. In larger organizations, where immediate access to this information is crucial for non-admins involved in user management and usage documentation, this presents a significant challenge.

            [COMMERCE-20] Reduce cache time for REST API license metrics.

            pqz made changes -
            Affected Products Original: Jira Software [ 18436 ]
            Component/s Original: Commerce - Billing - Preview [ 71890 ]
            Component/s New: Billing - Preview [ 79602 ]
            Key Original: CLOUD-12179 New: COMMERCE-20
            Support reference count Original: 1
            Project Original: Atlassian Cloud [ 14613 ] New: Commerce [ 24011 ]
            SET Analytics Bot made changes -
            Support reference count New: 1

            Carsten Schäfer added a comment -

            As initiator, I'd like to add: 

            • the information, how old the cache is would already provide us hints when to expect the next cache-refresh
            • if performance is a key argument, consider allowing only limited refresh instructions via API for the API cache per day, e.g. 5, so that an action to clean up and to see the effect can be coordinated/planned
            • This is also to efficiently use the tiers as upgrading a tier (when it was not possible to prevent limits reached) seems to involve upgrade costs to be avoided, especially on fixed budgets for 1y+
            • It is not possible to provide expiry dates for users or external users specifically, which makes it more important to regularly clean up and get exact features when becoming active

            thanks

             

            Carsten Schäfer added a comment - As initiator, I'd like to add:  the information, how old the cache is would already provide us hints when to expect the next cache-refresh if performance is a key argument, consider allowing only limited refresh instructions via API for the API cache per day, e.g. 5, so that an action to clean up and to see the effect can be coordinated/planned This is also to efficiently use the tiers as upgrading a tier (when it was not possible to prevent limits reached) seems to involve upgrade costs to be avoided, especially on fixed budgets for 1y+ It is not possible to provide expiry dates for users or external users specifically, which makes it more important to regularly clean up and get exact features when becoming active thanks  
            Zee Choudhry created issue -

              Unassigned Unassigned
              790ca575addc Zee Choudhry
              Votes:
              2 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated: