Bug 7246

Adding steps to reproduce this problem:

* Start Toaster in managed mode
* Log in to the Django admin interface (http://localhost:8000/admin)
* Click on "Toaster settings" at the bottom of the list
* Delete all options set there except DEFCONF_MACHINE and DEFAULT_RELEASE
* Go back to Toaster in managed mode and create a new project
* In the project configuration page, click on the "Edit configuration variables" link

The page will look like the attached screenshot.

I have questions about the intended implementation.

Since each of the existing predefined variables in this page have explicit custom controls that are tightly coupled with javascript (explicitly including DISTRO and IMAGE_INSTALL_append as per requests from Belen) , they must exist hard coded in the page.

It appears that the ask is this:

1) Put conditionals around the hard coded sections such that if the respective variable is not defined in the project's context it should not appear in the page, and the related javascript will be passive.

2) Pass the current set of pre-defined variables so that they can be marked as not removable.

I observe that currently if a custom variable is added in the Admin page, it will correctly appear in the page but will have the delete icon enabled.

(In reply to comment #2)
> I have questions about the intended implementation.
> 
> Since each of the existing predefined variables in this page have explicit
> custom controls that are tightly coupled with javascript (explicitly
> including DISTRO and IMAGE_INSTALL_append as per requests from Belen) , they
> must exist hard coded in the page.
> 
> It appears that the ask is this:
> 
> 1) Put conditionals around the hard coded sections such that if the
> respective variable is not defined in the project's context it should not
> appear in the page, and the related javascript will be passive.
> 
> 2) Pass the current set of pre-defined variables so that they can be marked
> as not removable.

I would rather keep the flexibility and let Toaster administrators remove those variables if they so wish. I do understand if that's not possible / hard to do, though. I am happy with going live with those variables as not removable and see if anybody complains. 

> 
> I observe that currently if a custom variable is added in the Admin page, it
> will correctly appear in the page but will have the delete icon enabled.

Didn't think of that one. It's probably not a big deal, but it is a different behaviour to the one we have implemented for IMAGE_INSTALL_append. 

Basically, we'll need to add an option to the Django admin interface, so that administrators can specify if the variable can be empty or not (right now it can't: the admin interface forces you to provide a value). If the variable can be empty, it should behave like IMAGE_INSTALL_append (i.e. you can delete the value, but not the variable itself: that can only be done by an administrator). If the variable cannot be empty, then it should behave like the DISTRO does: you can edit the value, but you cannot leave it blank or delete the variable.

I've added a note to bug 6897 so that we don't forget about this.

Here are the fix details:

  * I tested this by going into the admin page (“http://127.0.0.1:8000/admin/orm/toastersetting/”) and putting “_X” (so that I would not lose them) after the five core values that the configuration variable page has special code for, and created a new project.

  * The ‘new’ values appeared as regular custom values with the regular handling. They are deletable even though they came from the admin page, but we decided that this was acceptable for now until the admin page gets redone. 

The hardcoded special handlers are indeed not rendered as per the defect request.

  * An interesting consequence is that if the user manually adds back in one or more of those 5 core values, the hardcoded special handlers do reappear when the page is refreshed, again because the view class cannot tell if these are admin values or not. 

This seems to be an expected and natural consequence, so my patch goes ahead and forces a refresh when one of those variables are added back in, so that the page is consistent. One thing the code does not do here is pre-validate the inputs, but I think this is ok to let go since we are already at the edge of supported workflows, plus the interface will enforce the value ranges when they are re-edited. BTW, once you add back in one of these variables they are no longer deletable.

Blocked by bug 7618.

Verified on master: 5cc614ed68d9f763041e4d67134c5d7ada795978