Return display names from the backend

[nllong]

The conversion of database fields to user displays exists in several places in the code base. Need to standardize on one solution and implement in the backend.

This will most likely result in adding a display name field to the columns table in the database.

[RDmitchell]

Yes, it seems like adding a display name to the columns table makes sense.

How does this interact with what the user sees in the Mapping pulldown list? Can the display name and the pulldown list name be the same? I guess this gives the option of not having them same when needed, but the default would be that they would be the same.

[nllong]

yeah that would be the best approach... users would map to display names, not database field names.

On Jan 5, 2017, at 2:31 PM, RDmitchell notifications@github.com wrote:

Yes, it seems like adding a display name to the columns table makes sense.

How does this interact with what the user sees in the Mapping pulldown list? Can the display name and the pulldown list name be the same? I guess this gives the option of not having them same when needed, but the default would be that they would be the same.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/SEED-platform/seed/issues/1191#issuecomment-270763314, or mute the thread https://github.com/notifications/unsubscribe-auth/AB0amlELccKvXSKR7qLZIGzU3lmbwDCcks5rPWEagaJpZM4LcJKq.

[RDmitchell]

Yup -- mapping and display names are one and the same. That should be what we do ... but what does that mean for 2.0 vs 2.1? We don't want to have to do remapping of data (if we can help it) after 2.0 (although maybe it's unavoidable given our time constraints).

[RDmitchell]

@nllong -- the one field that is really weird in mapping is when you have a Tax Lot ID in a property file, and you want to set it to be a matching field in the Tax Lot table (ie, matching it to Jurisdiction Tax Lot ID), you map the field to "Lot Number", and I think apply it to the Property table (would have to I think).

Seems like this field name (at least the display name / mapping name?) should be "Jurisdiction Tax Lot ID", but the program knows it is in the Property table and thus it will match on it.

We don't have to do this now, I guess, because it would probably mean changing the matching code, and we don't have time to do that. And maybe it doesn't matter from the BE, because the field name would continue to be "Lot number", only the FE mapping name would change to "Jurisdiction Tax Lot ID".

Anyway, something to ponder for the future I guess.

[nllong]

1230

[RDmitchell]

Comment from #1151 which I have closed

---

SHA: 3e9c017 instance: seeddemostaging browser: chrome, incognito file: covered-buildings-sample-small.csv, from #1126 https://drive.google.com/open?id=0B3fTKpZ9Dx7LMHgwYTloc0lGOTQ

Looking at the pm-mapping.json file, seems like the display names are not getting picked up for some reason.

[RDmitchell]

@axelstudios -- not quite sure how to test this.

In terms of mapping the ESPM field called "Energy Score" to "ENERGY STAR Score" as opposed to "Energy Score" (which used to be the only way to get the program to get a final mapping of ENERGY STAR Score), this seems to be fixed.

Testing Steps:

• Import file used in #1588, which is an ESPM file that has the ESPM field "energy_score"
• Map it to "ENERGY STAR Score" (as opposed to mapping it to "Energy Score" which is what I had to do previously in order to get SEED to have that field mapped in the Inventory List to "ENERGY STAR Score" with the correct data in the field)
• Mapping Review -- Field is called ENERGY STAR Score and it has the correct data in it
• Inventory List view -- field is mapped to ENERGY STAR Score and has the correct data in it.

[RDmitchell]

It also picked up the capitalization of Site EUI when I mapped it as all upper case EUI.

[RDmitchell]

testing done on

Instance: dev1 SHA: 90e4a7d Org: LBNL 20 Cycle: Test 1588

Closing