Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-1893 Improvements in automatic suspension and deletion of tenants
  3. THREESCALE-2132

[Refactor & Bugfix] Improvements in automatic suspension and deletion of tenants

XMLWordPrintable

    • Icon: Sub-task Sub-task
    • Resolution: Done
    • Icon: Critical Critical
    • None
    • None
    • System
    • 3scale 2019-03-11, 3scale 2019-03-25, 3scale 2019-04-08

      Bugfix

      • We used to make among the conditions for the automatic suspension and deletion of tenants, that we shouldn't touch those tenants that provide 'enterprise' plans to their customers, but that is wrong, and what this bug fix does is removing that condition, and add the condition that we shouldn't touch those tenants that have an application from a plan with the system name containing enterprise (no matter if there are capital letters).
      • Rake task to suspend the tenants that are already scheduled for deletion and shouldn't be deleted (for the conditions mentioned above). Execute it with bundle exec rake multitenant:tenants:suspend_forbidden_plans_scheduled_for_deletion. You can see how I tested this part in preview from this comment in the PR.

      Refactor

      • Move the complex conditions to auto-suspend and auto-schedule_for_deletion away from the workers. The way to test it is just test that the 2 workers (StaleAccountWorker & SuspendInactiveAccountsWorker) keep working
      • For the plans whose tenants shouldn't be automatically suspended or destroyed, we used to have the term enterprise hardcoded in the code. We changed this to make it configurable. Now we accept a list of system_names instead, and they can contain SQL Wildcards. Example of the config file in config/features.yml:
      account_deletion:   enabled: true
        account_inactivity: 365
        account_suspension: 90
        contract_unpaid_time: 183
        disabled_for_app_plans:   - '%enterprise%'
      

      Important note for QA: Test that the list inside disabled_for_app_plans doesn't allow SQL injection Because it is done which a sql condition such as LIKE firstElementOfTheList OR LIKE secondElementOfTheList ...

              Unassigned Unassigned
              mnoyabon Marta Noya (Inactive)
              Jakub Smolár Jakub Smolár
              Marta Noya Marta Noya (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

                Created:
                Updated:
                Resolved: