desuperheater_temperature_save (yzhou601) - x86_64-Linux-Ubuntu-18.04-custom_check: OK (9 of 9 tests passed, 0 test warnings)

![Build Badge](http://img.shields.io/badge/build%20status-passing-green.png)


desuperheater_temperature_save (yzhou601) - x86_64-Linux-Ubuntu-18.04-cppcheck: OK (0 of 0 tests passed, 0 test warnings)

![Build Badge](http://img.shields.io/badge/build%20status-passing-green.png)


I'm unsure why this is needed, it looks like there's a bug further down the line. The DirectoryManager ensures that only image files are loaded, see:
https://github.com/cyverse-gis/suas-metadata/blob/3fcc6e51037223bc8691ad8659ebf1a85864ecd1/Calliope/src/main/java/model/dataSources/DirectoryManager.java#L145
https://github.com/cyverse-gis/suas-metadata/blob/3fcc6e51037223bc8691ad8659ebf1a85864ecd1/Calliope/src/main/java/model/util/AnalysisUtils.java#L25


	              'pva', 'qt', 'rm', 'rmvb', 'sdp', 'svq3', 'strm', 'ts', 'ty', 'vdr', 'viv', 'vob', 'vp3', 'wmv', 'wpl', 'wtv', 'xsp', 'xvid', 'webm']
	              'm2t', 'm2ts', 'm2v', 'm4v', 'mkv', 'mov', 'mp4', 'mpeg', 'mpg', 'mts', 'mxf', 'nsv', 'nuv', 'ogm', 'ogv', 'tp',
	              'pva', 'qt', 'rm', 'rmvb', 'sdp', 'svq3', 'strm', 'ts', 'ty', 'vdr', 'viv', 'vob', 'vp3', 'wmv', 'wpl', 'wtv',
	              'xsp', 'xvid', 'webm']


@thmour @jdurgin @neha-ojha This needs to be called when initializing a PG, probably near at the end of OSD::load_pgs().


Looks good! Not sure why I can’t approve here but I will try and figure it out next week.


yep. reconfiguring my servers with a full docker stack (docker-compose and a custom cli), ipv6 ...
work in progress.
I hope I will have time to feed it, got a ton of ideas for it, but time is missing ...


This solved the problem with usernames that include a period. This doesn't appear to allow email addresses with fewer than 3 characters before the @ sign. I have tested several ways and cannot get it to work with the email address jm@marinelayer.com, or any other variation with fewer than 3 characters.

I searched around for a regular expression that is superior, and I discovered one that has been generally expected to work in nearly all cases. I haven't been able to find any examples of instances where it does not work. I recommend updating it using this regular expression:
`/^(?!(?:(?:\x22?\x5C[\x00-\x7E]\x22?)|(?:\x22?[^\x5C\x22]\x22?)){255,})(?!(?:(?:\x22?\x5C[\x00-\x7E]\x22?)|(?:\x22?[^\x5C\x22]\x22?)){65,}@)(?:(?:[\x21\x23-\x27\x2A\x2B\x2D\x2F-\x39\x3D\x3F\x5E-\x7E]+)|(?:\x22(?:[\x01-\x08\x0B\x0C\x0E-\x1F\x21\x23-\x5B\x5D-\x7F]|(?:\x5C[\x00-\x7F]))*\x22))(?:\.(?:(?:[\x21\x23-\x27\x2A\x2B\x2D\x2F-\x39\x3D\x3F\x5E-\x7E]+)|(?:\x22(?:[\x01-\x08\x0B\x0C\x0E-\x1F\x21\x23-\x5B\x5D-\x7F]|(?:\x5C[\x00-\x7F]))*\x22)))*@(?:(?:(?!.*[^.]{64,})(?:(?:(?:xn--)?[a-z0-9]+(?:-[a-z0-9]+)*\.){1,126}){1,}(?:(?:[a-z][a-z0-9]*)|(?:(?:xn--)[a-z0-9]+))(?:-[a-z0-9]+)*)|(?:\[(?:(?:IPv6:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){7})|(?:(?!(?:.*[a-f0-9][:\]]){7,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,5})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,5})?)))|(?:(?:IPv6:(?:(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){5}:)|(?:(?!(?:.*[a-f0-9]:){5,})(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,3})?::(?:[a-f0-9]{1,4}(?::[a-f0-9]{1,4}){0,3}:)?)))?(?:(?:25[0-5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))(?:\.(?:(?:25[0-5])|(?:2[0-4][0-9])|(?:1[0-9]{2})|(?:[1-9]?[0-9]))){3}))\]))$/iD`

I'm happy to make a commit and pull request or you can. This is designed way differently, and requires single-quotes to enclose it instead of the double quotes you currently use. Because of how different it is than what you have used, I'll let you make the call on whether or not to implement it. For now, I'm going to make that change myself on my local install to get this order pushed through. Hopefully the validation on your end doesn't reject it once it arrives.