Looking at CAPWATCH data .. every DoB value is the 1st of the month. WTF?
Quote from: a2capt on January 21, 2014, 03:03:47 AM
Looking at CAPWATCH data .. every DoB value is the 1st of the month. WTF?
Do you have rights to see the exact DOB? Some people just get the "Over 18" and "over 21" views, while others get an exact DOB. For example, in the Personnel Information app, I can see exact DOB.
Wow. Confirmed I see it too - I checked my own. The month and year are correct, but date shows "1".
Is that something a member can even change themselves?
The pull down scrolls in eservices have been wonky lately, too.
My DOB is correct.
Maybe the overload of comments for the draft 39-1 finally drove eServices over the edge.
If you look at your own record, it is correct. If you export a dump they're all the first of the month. This came up because I'm putting together an MSA, and I thought rather than harvest it all from 70 Form 31's, I'd get it all from the download.
Bzzzzzzt.
Yet another change to the data product used in the field?
I noticed this quite some time ago. For CAPWATCH downloads, you're apparently only authorized to see month and year of birth. So the date is always 1 (plot twist: some people were born on the first of the month).
Quote from: dwb on January 21, 2014, 12:22:47 PM
I noticed this quite some time ago. For CAPWATCH downloads, you're apparently only authorized to see month and year of birth. So the date is always 1 (plot twist: some people were born on the first of the month).
I see what you did there. The old CAPTalk switcheroo
The last time I actually used the data at that level for something useful, it was correct. So for purposes of age determination, if you're not in the same calendar month it's fine, if you are .. seek official data at the event for sure.
Quote from: a2capt on January 21, 2014, 04:26:49 PM
The last time I actually used the data at that level for something useful, it was correct. So for purposes of age determination, if you're not in the same calendar month it's fine, if you are .. seek official data at the event for sure.
So much for using birthday as a "validation" question for password resets.
NHQ is still storing the whole birthday. It's just that they're not giving you access to the day in the download (for whatever reason). So password resets still work.
Quote from: dwb on January 21, 2014, 07:13:27 PM
NHQ is still storing the whole birthday. It's just that they're not giving you access to the day in the download (for whatever reason). So password resets still work.
Well, NHQ also won't do OAuth or any other kind of authentication, so my wing website has to have a whole different username/password for everyone in the wing for it.
So, yes, I have to remove birthdate from the password reset verification process.
Hmmm.. I wonder if it's available in an IMU DB.. which I do have a way to break down to CSV as well. Plenty of reasons you'd want to know the exact day in an ES environment. Including that it uses that to login.
I should have titled the thread "DoB incomplete?" .. or obfuscated.
Quote from: a2capt on January 21, 2014, 07:40:12 PM
Hmmm.. I wonder if it's available in an IMU DB.. which I do have a way to break down to CSV as well. Plenty of reasons you'd want to know the exact day in an ES environment. Including that it uses that to login.
I should have titled the thread "DoB incomplete?" .. or obfuscated.
I'll have to look when I get home tonight...still doesn't help much, whole process for the website is very automated...although, maybe I could get Pete to let me access the IMU SQL tables that I helped him migrate to a while back, I could do an SSIS package to get the data I need.
What bugs me is that this is yet another change that NHQ has made recently without notification to people who use it, like the ID card barcodes.
This has actually been the case for at least a year (I want to say quite a bit longer than that actually but I know at least a year).
Seems like just before this time last year, when I was putting together an MSA I didn't have this problem. I didn't even notice it at first this time around, and honestly, got about 1/4 of the way in of picking out lines from the members table that I realized.. WTF!? everyone I have on staff is born in January! .. because the import I did also did a trip up and folded the 1st as the month and the month 1-12 as the day. So I didn't notice at first. That was it's own "what the.. " revelation. Then I saw that everything was the 1st.
So I went back into archives and found real data but not from any current download.
Quote from: JeffDG on January 21, 2014, 07:44:07 PM
What bugs me is that this is yet another change that NHQ has made recently without notification to people who use it, like the ID card barcodes.
Won't be a big deal until someone winds up having changed an age bracket (think of how we talk about over/under 18 for federal coverage) and nobody noticed because their it looks like they're over 18, supposedly as of the 1st of the month, and they're really not, and they get injured or killed and we find out they're not covered for federal insurance
Whoops.
Then its going to be the field's fault for relying on that data.
(the day-to-day corallary might be getting flagged a little early that a cadet is due for his "adult CPPT briefing," but because he's not actually 18 yet, you can't put the completion in until after his actual birthday. Thats a minor issue, but it could become a paperwork chase when the PDO does the training, can't put the completion into eServices the day after he does it, and then forgets to do it after poor Timmy's actual 18th birthday...)
Cppt completions can be entered at 17 1/2, IRRC. That changed when 17 yo cadets were allowed to take CPPT.
Quote from: SarDragon on January 23, 2014, 08:41:14 AM
Cppt completions can be entered at 17 1/2, IRRC. That changed when 17 yo cadets were allowed to take CPPT.
Oooh, missed that change (must have happened when I was on sabbatical..)
The larger problem is CPFT. It will create errors for cadets who are in their birth month, as all ages <18 change required passing scores with each change in age, so you'll end up asking cadets to meet requirements for an age which they haven't reached yet. >:(
The actual birth day of month is in the restricted personnel info (and is on the CAPF15 that should be on hand at the squadron), but it's a pretty big inconvenience to have to check for it once they get into CAPWATCH and imported into SIMS so the CPFT report will be correct. I haven't checked to see if the CPFT report in eServices is correct....
It is purely conjecture, but the change quite possibly made to protect Personally Identifiable Information (PII), which is a big deal right now in the DoD.
A recent change to AR 25-50 (the Army's rendistion of CAPR 10-1) decrees that any document containing a full social security number be marked as FOUO.
Quote from: FlyTiger77 on January 25, 2014, 05:39:24 PM
It is purely conjecture, but the change quite possibly made to protect Personally Identifiable Information (PII), which is a big deal right now in the DoD.
A recent change to AR 25-50 (the Army's rendistion of CAPR 10-1) decrees that any document containing a full social security number be marked as FOUO.
Oh, I'm totally sure thats why that was done. Obfuscation of PII.
Quote from: NIN on January 25, 2014, 06:11:06 PM
Quote from: FlyTiger77 on January 25, 2014, 05:39:24 PM
It is purely conjecture, but the change quite possibly made to protect Personally Identifiable Information (PII), which is a big deal right now in the DoD.
A recent change to AR 25-50 (the Army's rendistion of CAPR 10-1) decrees that any document containing a full social security number be marked as FOUO.
Oh, I'm totally sure thats why that was done. Obfuscation of PII.
Yep. I'd get my company to talk to NHQ about encrypting all their PII data, but that might cause my dues to go up... :)
I noticed this change quite a while ago (CAPDB.us ingests CAPWATCH data), but figured that it was obfuscation and let it be.