We had considered this when we made the change and thought it was good that it triggers the reset, since we don't want installations to the default.

Closing, unless I'm missing a better argument to not have it work this way.

@pameyer any more thoughts on this? I observed this as well but I wasn't sure if it's a problem or not. It's a little annoying that I can't just tell people, "I installed Dataverse on this test server and the dataverseAdmin password is the default" anymore. I have to coordinate with people on what the password was changed to. It's slightly annoying and new behavior as of 4.8.

Re-opening so I remember to discuss with @scolapasta .

My thinking was that the default installation options were targeted at development/staging (aka - non-production); which was the logic used for restricting robots.txt. With that logic, developers will hit a password rest every time they do a fresh installation.

Any thoughts on what a good development approach for this would be? Super-user API? Documentation of PSQL commands? Something else?

Isn't it the installer that sets it? I don't know why we didn't make the change there originally. That was my argument at least. Intentionally triggering errors, despite being well intended, is really just annoying and bad UX.

@mheppler the installer does set it. Possibly one alternative approach would be to allow the installer to take an optional argument/parameter for what the dataverseAdmin password should be.

@mheppler yes, it's set at https://github.com/IQSS/dataverse/blob/v4.9.2/scripts/api/setup-all.sh#L60 (?password=admin) and we should absolutely change it (and the guides) to "admin1". It drives me nuts and I think it drives @pameyer nuts too. Anyone who installs Dataverse a lot is affected.

A few comments:

1. I get that it drives people nuts. That is purposeful. The point is to not allow anyone to run dataverse with the default password. Changing it to admin1 would not force a change of password, which is what we're going for. (prior to requiring a number in the password, it didn't do this and I was sometimes able to get into some installations just by using the default).
2. The UX is not ideal - ideally it would know this was a first time login and have a message saying, since this is your first time logging in, you must change the password. The logic to support this is more than a change of text and didn't seem to be a super high priority.
3. @pameyer's suggestion of changing the installer to prompt for a password would work as it accomplishes the goal fo forcing installations to change the default user password.

I forgot to update this issue a while back after @scolapasta and I discussed it; but people using the default password in production is not good, and probably something that should be discouraged. I don't think we came to any agreement about if the default installation should result in a production installation, demo/evaluation installation, developer installation - it seems like it's a mix of all three, and probably not something to sort out here.

My suggestion (and @mheppler should get credit for the inspiration) was to use a password if one is provided, otherwise leaving it as the current default (and so keeping the current change prompt); not to prompt for yet another thing during installation. Sound reasonable?

@pameyer thanks for creating pull request #5182. I took a look and came up with a different approach in pull request #5201. I'll grab you so we can discuss. Thanks!

@pameyer and I discussed and we closed pull request #5182 in favor of pull request #5201 and are moving this to QA.

To test, follow the updated conf/docker-aio/readme.md which shows the new password and boils down to running ./conf/docker-aio/prep_it.bash and logging in to http://localhost:8083

Also from discussion w\ @pdurbin ; #5201 doesn't solve the entire problem. Whether that means leaving this issue open, or closing it and letting me (or another developer) open another one is another question - I don't have an opinion on that.

I discussed this issue with @mheppler and @TaniaSchlatter today while helping them (successfully!) spin up new instances of Dataverse on EC2 using the script at http://guides.dataverse.org/en/4.9.4/developers/deployment.html

They seemed to be in favor of not needing to change the password for the dataverseAdmin user every time they spin up an instance.

@pameyer because pull request #5174 has been merged I believe I have the hooks in need in this repo to make it so the design team and others using the ec2 script don't have to go through the "pick a stronger password" steps but I'll still need to coordinate yet more variables on the dataverse-ansible side with @donsizemore to ultimately pass here: https://github.com/IQSS/dataverse-ansible/blob/b6daf04645148275a429284e0ff457bf7d4f7072/tasks/dataverse-postinstall.yml#L22

This is assuming that pull request #5201 gets merged, of course. 😄