Use primary_dcc_contact.dcc_abbreviation for DCC moniker

[jonathancrabtree]

The dashboard-api uses a "DCC moniker" (also referred to as "dccName") to identify DCCs. This moniker appears in DCC-specific API endpoints as well as the responses from some of those same endpoints. It is intended to be a short, unique, human-readable identifier for the DCC. In Epic 1 and Epic 2 project.abbreviation (in the DERIVA Project table) was used as the DCC moniker (for those top-level Projects that correspond to DCCs and not to projects of a DCC.) However, project.abbreviation is nullable and the import tool therefore does not require that it be provided.

Going forward primary_dcc_contact.dcc_abbreviation will be used as the DCC moniker as it is not nullable and there should be a 1-1 relationship between primary_dcc_contact and DCC Project. See https://github.com/nih-cfde/cfde-deriva/issues/173 for details.

[jonathancrabtree]

One outstanding question here is how to handle the case where we're querying an older catalog in which primary_dcc_contact.dcc_abbreviation is allowed to be nullable (e.g., the current catalog 1 on app-dev). @abradyIGS requested that this case not be handled by falling back to an alternate primary ID (e.g., the RID from the Project table). One option would be to simply exclude the DCCs with no abbreviation from the query results. Another would be to throw a server error, probably one with status code 500. The current implementation does neither of these things and returns a null/empty value for DCCs that have no abbreviation set in the agreed-upon spot. This means that the dashboard will work (at least in the multi-DCC catalog case), but that you'll see things like this (the label for "4DN" is missing because it's the only DCC in dev catalog 1 with no primary_dcc_contact.dcc_abbreviation):

[abradyIGS]

existing submissions are being examined in detail now; as far as i've heard so far, all we'll need to do is remove 4DN data entirely (which was already on deck to do, at least as an option; they didn't submit anything for this release) and update any stale JSON schema files that had been bundled with the older submissions to reflect the tighter constraints (to avoid fouling up the loader).

that latter process might involve going back to them for reapproval, hence a question for @ACharbonneau :: please correct or update anything i got wrong above.

i think @karlcz is still poking around for ramifications, but i get the sense we're close to an actual action plan and that it looks something like the above?

[i'm unsure of issue-reopening protocols, here, or whether this discussion should be shunted somewhere else to an active issue; someone who cares, please direct me accordingly as needed.]

[ACharbonneau]

All of the data currently available as the 'public catalog' is going away. Karl is replacing it in dev/staging with current data.