Uploaded image for project: 'Red Hat 3scale API Management'
  1. Red Hat 3scale API Management
  2. THREESCALE-4588

Warning sign is displayed next to the Integration menu when the configuration is correctly saved

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • Major
    • 2.8 CR1
    • SaaS
    • System
    • 3
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Not Started
    • Hide

      1. Go to the Integration page
      2. Create a new mapping rule
      3. Click Update & Test the Staging Environment

      Show
      1. Go to the Integration page 2. Create a new mapping rule 3. Click Update & Test the Staging Environment

    Description

      Current behaviour
      A warning sign is displayed next to the Integration menu after saving the Staging configuration. The configuration history is correctly saved and the frames of the Configuration page are green.

      UPDATE: when updating a second time the Staging configuration the warning sign disappears.

      Desired behaviour
      The warning sign shouldn't be displayed if the configuration is correctly saved.

      Dev note

      This is because the exclamation mark feature was introduced after the date of creation of their most recent proxy config.
      There’s a record in the db that tracks changes in proxy configs. We compare the updated_at of that object with the created_at of the latest proxy config. If the object is newer than the config, then we show the exclamation mark.

      A way to prevent the exclamation mark from showing up, without touching code, without adding conditions that only make sense for Saas, is by running a migration that, for all services in the database, if the proxy config tracking object does not exist, create it; thereafter, for all tracking objects in the database that tracking_object.created_at == tracking_object.updated_at, change the value of the updated_at column to, say, 1900-01-01 00:00:00. This can be run in a couple of simple, pure, SQL commands, which would be quicker and easy, though it can lock the database; or we can define a rake task reset_proxy_config_change_history, for example, that takes the account ID as parameter (or run to all accounts when missing), and can slowly run the “fix” only for the accounts that we believe/known will not be happy with the exclamation mark.

      Attachments

        Activity

          People

            Unassigned Unassigned
            rhn-support-avilatus Anna Vila Tusell
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: