Columns filter state preservation

[veyselsahin]

trafficstars

Is your feature request related to a problem? Please describe the impact that the lack of the feature requested is creating.

I need column filters to preserve the last state forever.

Describe the solution you'd like

There might be either a setting or an app can decide to show filters based on the last desired state.

What users will benefit from this feature?

Users will save significant time and contextual focus if the filters are shown as they desire.

Are you able to implement this feature?

[Yes (I will propose a PR) / No.]

Do you want to help implement this feature? Please see our [contribution docs] Yes, It's been discussed in the slack channel.

Additional context

[github-actions[bot]]

Community Note

Voting for Prioritization

• Please vote on this issue by adding a 👍 reaction to the original post to help the community and maintainers prioritize this request.
• Please see our prioritization guide for information on how we prioritize.
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request.

Volunteering to Work on This Issue

• If you are interested in working on this issue, please leave a comment.
• If this would be your first contribution, please review the contribution guide.

[will-schneble]

AWS data sources have placeholder data when using terraform test. This makes sense for a lot of data sources such as data.aws_vpc, data.aws_security_groups, etc. For example, data.aws_vpc.this.cidr_block by default will be a random string like "uklbdtcf". However for data.aws_iam_policy_document it would be much more convenient if it was computed because currently:

1. Users have to define valid JSON overrides, which is tedious, or other resources will fail on validation such as aws_iam_role trust policies
2. We cannot test the computed policy document

[ankitjhingan]

even am getting same error while running the tests on a submodule.

I am using terraform v1.8.3

│ Error: "assume_role_policy" contains an invalid JSON policy: not a JSON object
│
│   with module.eks_managed_node_group["global-ondemand-ng"].aws_iam_role.this[0],
│   on .terraform/modules/eks_managed_node_group/modules/eks-managed-node-group/main.tf line 510, in resource "aws_iam_role" "this":
│  510:   assume_role_policy    = data.aws_iam_policy_document.assume_role_policy[0].json

[radeksimko]

👋🏻 As far as I can tell, this is not a bug but rather a way that mocking currently works, which is also documented at https://developer.hashicorp.com/terraform/language/tests/mocking#generated-data

If you do not provide a value for an optional computed attribute, Terraform will automatically generate one. The values that Terraform generates depends on the data type:

• Numbers will be 0.
• Booleans will be false.
• Strings will be a random 8 character alphanumeric string.

As @will-schneble mentioned above the random alphanumeric character will never be valid JSON string, which is the reason behind the test failure.

This can also be surfaced with the following assertion added to the run block

assert {
   condition = can(jsondecode(data.aws_iam_policy_document.policy.json))
   error_message = "expected JSON, got ${data.aws_iam_policy_document.policy.json}"
}

which will produce the following

tests/unit.tftest.hcl... in progress
  run "default"... fail
╷
│ Error: Test assertion failed
│
│   on tests/unit.tftest.hcl line 17, in run "default":
│   17:    condition = can(jsondecode(data.aws_iam_policy_document.policy.json))
│     ├────────────────
│     │ data.aws_iam_policy_document.policy.json is "eypeo4xi"
│
│ expected JSON, got eypeo4xi
╵
tests/unit.tftest.hcl... tearing down
tests/unit.tftest.hcl... fail

Failure! 0 passed, 1 failed.

Now for something more constructive 😄

---

As mentioned above, one workaround is an override for the data source, e.g.:

mock_provider "aws" {
    override_data {
        target = data.aws_iam_policy_document.policy
        values = {
          json = "{}"
        }
    }
}

---

Historically there was no better way for providers to generate data structures like these IAM policies. I believe that the AWS provider could explore the use of provider-defined functions for IAM policies. For example, if implemented, it could work like this:

locals {
  policy = provider::aws::iam_policy_build({
    statement = {
      actions = ["sts:AssumeRole"]
    }
    principals = {
      type        = "Service"
      identifiers = ["elasticmapreduce.amazonaws.com"]
    }
  })
}

resource "aws_iam_role" "role" {
  name               = "test_role"
  assume_role_policy = local.policy
}

The differences from the equivalent aws_iam_policy_document data source is that it wouldn't get persisted in state (as it does not need to) and it would not get mocked, just like any other function calls. The function implementation could still provide the validation that data source does today.

---

If function-based approach turns out to be problematic for any reason, we could explore other solutions. I would not anticipate this to be trivial if we expect Terraform to do this automatically (i.e. without user explicitly declaring override). Any automated mocking that happens today is based on schema by Terraform (Core) and the schema does not convey anything about the value other than its type (i.e. string).

A few ideas:

• We could introduce some additional metadata to the schema, so that the AWS provider can say that json field is expected to be valid JSON.
• We could let providers supply its own mock data
• We could let providers mark a data source as "do not mock"

Any of the above would need to be implemented in the plugin protocol and so we reach conclusion this is needed/wanted, we can bring this discussion over to https://github.com/hashicorp/terraform