fix: order of widgets on page matters

[ilakhtenkov]

Description

Fixing issue: Order of widgets in page of newrelic_one_dashboard matters.
Before change: change of order of widgets in page {} block creating terraform diff and resources recreation.
After change: Reorder of widgets in page {} block detected by terraform and not producing diff.

Important!
This change is WIP, currently it is only implemented for widget_markdown. For other widgets default parameters and hash functions should be adopted. As this work requested large amount of work. I want to hear contributors feedback first if they found this change useful and it could be potentially integrated.

Fixes #1720, #1452

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected). TODO: Need to be tested.
• This change requires a documentation update

Checklist:

Please delete options that are not relevant.

• My commit message follows conventional commits
• My code is formatted to Go standards
• I have performed a self-review of my own code
• I have made corresponding changes to the documentation
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes. Go here for instructions on running tests locally.

How to test this change?

TODO: Run tests for all widgets, Run tests for providers update
Test Terraform code:

locals {
  iteration_map = {
    0 = {
      text = "first element"
    }
    1 = {
      text = "second element"
    }
  }
}

resource "newrelic_one_dashboard" "exampledash" {
  name        = "New Relic Terraform Diff Test"
  permissions = "public_read_only"

  page {
    name = "New Relic Terraform Example"
    dynamic "widget_markdown" {
      for_each = local.iteration_map
      content {
        title  = "1-${widget_markdown.key} Dashboard Note"
          column = 1
          width  = 3
          height = 3
          row    = 1 + widget_markdown.key
          text = "This is awesome text for: ${widget_markdown.value["text"]}"
      }
    }
    dynamic "widget_markdown" {
      for_each = local.iteration_map
      content {
        title  = "2-${widget_markdown.key} Dashboard Note"
          column = 4
          width  = 3
          height = 3
          row    = 1 + widget_markdown.key
          text = "This is another awesome text for: ${widget_markdown.value["text"]}"
      }
    }

  }
}

Steps:

1. Apply terraform code
2. Run terraform plan and ensure that there is no diff
3. Change one element of iteration_map
4. Run terraform plan and ensure that only widgets related to the changed map element are producing diff.
5. Apply changes and make sure that applied without errors.

[CLAassistant]

All committers have signed the CLA.

[pranav-new-relic]

Hi @ilakhtenkov - thank you for contributing code towards this issue! This has been around for quite some time now; while we had briefly explored the path you've tried (converting lists into sets and subsequent changes), we haven't been able to take it up completely owing to subsequent blockers we'd seen and time constraints to get them fixed, as we were (and are currently) juggling a couple of features, maintenance, EOLs and more.

However, this can mostly get it working, so I'd suggest you to continue contributing to this further, after which I can have myself and the team review this PR; I'm certain we can get it integrated, unless this has any unexpected repercussions or causes newer issues. To be sure about this (as one of the ways to test your code changes) I'd recommend you to try making regular changes to your Terraform configuration (not relating to this issue) after the first terraform apply, such as, changing the values of arguments, e.g. row, and then trying a terraform plan to make sure these changes do not lead to any unforeseen drift.

Looking forward to your full-fledged contribution. Thank you!

[FlareLine]

Hey team,

Just wondering if this PR is still in the works? This is directly affecting our use of the provider and there is currently no workaround for our use case.

We generate pages and widget dynamically based on a custom variable model (so that not everything is defined in a single file) and there is currently no way to maintain the order of widgets returned from API calls from the provider.

It also doesn't look like the API is returning widgets in row/column order either, as it'll randomly order rows in the JSON it returns.

@ilakhtenkov if you're not looking to take up this PR anymore I'm happy to take a look and try to implement the changes myself.

[ilakhtenkov]

Hey team,

Just wondering if this PR is still in the works? This is directly affecting our use of the provider and there is currently no workaround for our use case.

We generate pages and widget dynamically based on a custom variable model (so that not everything is defined in a single file) and there is currently no way to maintain the order of widgets returned from API calls from the provider.

It also doesn't look like the API is returning widgets in row/column order either, as it'll randomly order rows in the JSON it returns.

@ilakhtenkov if you're not looking to take up this PR anymore I'm happy to take a look and try to implement the changes myself.

Hi @FlareLine. This issue is still affecting my team. Unfortunately I have not had time to finish this up. Basically was done and working as expected I just need to rebase. The large part is unit tests that I will try to come to during xmass holidays. Manual testing of provider after I would push the final version of the code would be a really great help.

[ilakhtenkov]

Hi @FlareLine I was looking at the issue today and it is not reproducable for me in version 3.53.0. Could you please confirm that this is still issue for you on the latest version.

[FlareLine]

Hey @ilakhtenkov, I'll have a look when I'm back at work - currently on holidays so I'll shoot through some results when I can 😁