So the reason the date selector was not being seen was because I am grabbing the minimal date.
Some entries, for this field, might have ‘0000-00-00 00:00:00’ as the date time stamp, which is invalid.
So the original way it worked, if the date was invalid (start time will always be earlier than end time) it would present “invalid”.
The updated method should work for this for all of you having this problem. I’m correcting this behaviour by adjusting the start date to 2 years before the current date.
Hopefully this is sufficient. The reason I don’t want to go back further is the amount of time it would take to generate the selector. (I’m not guessing the selector based on max end date any more. I’m just giving a date range based on the earliest time found and forward (as it’s not really a selector otherwise right?))
I’m also changing the way things are displayed a little bit.
Instead of showing logs of tasks that have either an invalid start OR end date, both start AND end must be invalid to no longer show. It may make some strange readings for things, but shouldn’t hurt anything otherwise.
If you expand each option on the Fog Settings page individually, the missing bits are not visible. Only Expand ALL shows the missing bits and only at the top of the list, not where you’d expect them to be.
No more recursive calls in sanitize_items function.
This was pushed up for RC-5, while it doesn’t refer to the blank page for host creation, this is what the issue was referring to. The reason it didn’t implicitly call out the create new host is because it actually impacting many other elements.
Updating to RC-5 or higher will bring this “issue” to rest for you.
A very simple question, I suppose, but do the hosts that are registering have the new or legacy client?
Can you provide the client log of one of the “adding” systems? (If you are using legacy client please post one for each of the clients – one legacy client fog.log and one new client)