Pages -> skipping configuration

Description

When using this cli to deploy, it ignores pages configuration even though we have "enabled": false on the json file. Giving this warning: warn: Skipping pages file modules/tenant/tenant-name/pages/login.json as missing corresponding '.html' file

This happens, as the warning says, if we don’t have the corresponding .html file and are missing the html property on the json file.

The current solution is to add the .html property and point it to a newly created .html empty file.

It would be nice if we didn’t had to add the html property to login.json (or other pages) and create an .html file if we had "enabled": false on the json file.

Reproduction

On the pages folder have one of your .json files with “enabled” set to false and make sure you don’t have the html property like so:

{
  "name": "login",
  "enabled": false
}

Optional step: you can go to your auth0 dashboard, to the tenant you are about to redeploy, go to “Universal Login” -> tab “Login” and enable the “Customize Login Page” switch.

Now deploy your new configuration. You will notice a warning like the one mentioned above: warn: Skipping pages file modules/tenant/tenant-name/pages/login.json as missing corresponding '.html' file

If you did the optional step, you will notice that the “Customize Login Page” switch is still enabled even though you clearly set it to false on the json file.

Environment

Using auth0-deploy-cli v7.3.7

Thank you for your hard work. Best regards, Jorge Alves

[willvedd]

This has been addressed with v7.14.3. I’d like to reiterate that I’m not sure that this type of flexibility is wise for the longterm of this project. We’re starting to think about the positioning of this project and how it augments the Terraform Provider; better ideate the core principles. But for now, I’m hoping this alleviates some trouble for folks.

[willvedd]

Hi Jorge, thanks for opening this ticket. I agree that this is an issue and seemingly annoying too. At first glance it’s very similar to #293 which has a similar root cause IIRC. That error you’re receiving stems from the library and not the Auth0 API like most errors that are encountered, but that’s a good thing because it suggests that the fix is a bit smaller in scope. We can certainly make that mechanism a bit smarter, including an enabled check, but we would need to investigate a generalized solution for all resource types.

In the meantime, I think creating an empty HTML template is a sensible workaround, albeit unideal.