> > > Adding some notes from external conversation:
> > >
> > > config content should be always available (not just on first use)
> > This PR focus on first config
> >
> >
> > >
> > > config content should show on first use of management portal and be
> > available
> > > from management portal at any later time
> > That has to be in another PR. This one only covers first config. Otherwise
> > this PR can last forever adding new features not required at beginning.
> >
> 
> Are you saying this PR only displays config UI on first use? That's not the
> overall spec'd behavior. In any case, if you are planning to leave out normal
> configuration after first use, please create a trello card for this.

This is the card related with this PR "As KyleN I want to have access to a simple web UI so that a user can configure the SSID and password for the AP" (That's the title. Description is empty)

From a simple web UI, we have moved to a complete configuration portal, including SSID, wifi passphrase, interface, country code (dynamically populated from remote content), channel and  portal password; input verification of not empty fields, length for passwords, password and confirmation be equals, switch to official look&feel framework, replaced js alerts to notification divs, complete config backend support including a large tests suite, red asterisks on password fields, additional message div when saving config, removal of crackable login messages...

and you pretend that also a button to show config in management portal and rendering a different config page (with no red asterisks), behaving different (not requesting changing password or passphrase) should be included in this MP?

If you want to complete project in this MP just be clear and let me know. Is the overall specification applying only to this MP? I don't think so.

If you want to add another card in backlog, do it yourself. I'm not in this project on monday, I should have left it one week ago and, for helping and trying to finish my pending tasks, I've been warned about it today. So, whatever it takes to you.

> 
> >
> > >
> > > config content should physically be part of management.html (not in a
> > separate
> > > html page). Visibility of parts is controlled by css appropriately.
> > I don't see the reason for this. Actually I'm completely against having all
> > the portal in only one html template. However, so it is made.
> 
> Can you please provide your reasoning?

Is it really needed explaining why having a complete web with several pages in only one html file is crazy?
Is this like explaining what's the meaning of a method name?
are you kidding?
> 
> >
> >
> >
> > >
> > > Just to be clear, pre-config.json should NEVER be written to since it
> > > represents the system-integrator's pre config via gadget, if any
> > It is not written in any case
> >
> > >
> > > The only value you need to read from pre-config.json is portal.no-reset-
> > creds.
> > > If this is true, then the user is not required to reset the portal
> password
> > > and the wifi passphrase on first use.
> > It is also reading portal.no-operational, though it's not been used so far
> > anywhere
> 
> Can you drop the no-operational part? (You may have added that when you
> thought we wanted a Checkbox to not display the oper portal, but really that's
> never going to be configured by this UI.

I added that because that's part of the config, no matter when or where is going to be used, but I bet it is going to be used somewhere someday. Why is it in pre-config.json file if it is not going to be used?

> 
> >
> > >
> > > I don't think we need to write any config.json. Any changed values should
> be
> > > set after form validates in wifi-ap (and the portal password if that is
> set)
> > There is no config.json
> >
> >
> > >
> > > All params on the config page except for portal.password should get their
> > > values for display from wifi-ap (no local storage of these values)
> > All remote values are taken from wifi-ap, local ones from pre-config.json,
> > though in config page any local one is populated
> 
> Which local ones are you populating?
> 
> thx

Please look at the code at utils/config.go to see it. Thanks.

> >
> >
> > >
> > > Emtpy fields (except for portal password and wifi passprhase) should cause
> > > form validation error.
> > They do
> >
> > >
> > > After form validates, only changed params should be set. This prevents
> wifi-
> > ap
> > > DOWN>UP if not needed.
> > So it works