I believe this will break the provider for anyone using Graylog 4.0 or lower.
See https://docs.graylog.org/docs/changelog#graylog-410 and Graylog2/graylog2-server#10074

Would implementing a provider config flag like "graylog_min_version" and checking this respource.go solve that issue?

I believe this will break the provider for anyone using Graylog 4.0 or lower. See https://docs.graylog.org/docs/changelog#graylog-410 and Graylog2/graylog2-server#10074

Would implementing a provider config flag like "graylog_min_version" and checking this respource.go solve that issue?

Could be yeah, but I assume the majority of users is already on 4 (which has been released more than a year ago) and higher. Plus, if that's true, then it means that currently there are more people affected by the current situation than by the new situation (because the current situation impacts anyone Graylog 4.x, I believe.)

From what I can read in the links above, this change came with 4.1.0.
Both graylog 4.0 and 3.3 has had updates in the last few months. 4.0.13 was released on 2021-09-13 and 3.3.14 was released on 2021-07-28.

And, 4.1.0 is just a few months old itself, being released on 2021-06-23. So the issue probably affects fewer people than one might think.

Yeah you have a point there, but 4.1.0 has been released in June 2021, and you should consider all users from the version where people are impacted (so if I understood you correctly: 4.1.0) till the versions that have been published after 4.1.0. Assuming you meant only 4.1.0 itself; not the users that run versions later than that one.

@suzuki-shunsuke Any chance you have time to look at this? This currently prevents me from fully deploying Graylog in my setup.

I think it needs some more work on tests, which could probably be pulled from https://github.com/sollie/terraform-provider-graylog/tree/support-first_name-and-last_name

I suspect the easiest way to prevent breaking other peoples setup is to release this as v1.1.0, hoping people don't randomly accept new minor versions.

IMHO we got two options to handle this breaking change:

1. Allow both fields, being it full_name and first/last name
2. Drop full_name and add a note to the readme for version compatibality

Currently it is really a bad situation because we are not able to provision users for the recent version of Graylog.

Tagging @suzuki-shunsuke again in the hopes he will notice this.

Has this project been halted? At least a small announcement would be nice, so that we don't have to expect any new releases soon, or perhaps he's working on a rewrite (doubt it though).

@AnonymousWP @sollie

Sorry for late reply.

Unfortunately, it is difficult for me to maintain this project, because I no longer use Graylog.
I hope someone forks this repository and maintains it.

I'll update README and archive this repository. #97

@suzuki-shunsuke Thanks for the update.
Could you consider pushing an update to the documentation on registry.terraform.io and/or the README.md about supporting user management on versions prior to 4.1 only? That would probably be beneficial for users coming here for help when it does not work on 4.1 or later.

Hi @suzuki-shunsuke,
Are you going to merge the PR?
I am getting the following error on the Graylog version 4.2.3.

│ Error: status code: 400, {"type":"ApiError","message":"Cannot construct instance of org.graylog2.rest.models.users.requests.CreateUserRequest, problem: Null firstName\n at [Source: (org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$UnCloseableInputStream); line: 1, column: 223]"}: status code >= 300 │ │ with module.user["test"].graylog_user.default, │ on ../../../../modules/graylog/user/main.tf line 5, in resource "graylog_user" "default": │ 5: resource "graylog_user" "default" {