Turn off extended profile fields for search & facility profiles on Embedded Maps if user hasn't submitted

[hlennett]

Overview

Do not show extended fields if an Embedded Map user has not submitted those fields. Additionally, the helper text that shows up on (i) hover and when additional search filters are displayed should not show up on EMs.

Additional Context -

It would be a confusing experience for an Embedded Map if the Embedded Map owner had not contributed Type of Product, but that still appeared as a searchable field on their map.

"The additional work that would be required would be conditionally checking if someone has not submitted the extended profile fields."

Technical Implementation

• Add a new endpoint or add data to an an existing endpoint to that returns the names of the extended fields for which the contributor has data
  • Adding this data to the embed config endpoint may be a good option instead of creating a new endpoint
  • We can get the list of active extended field names by querying the ExtendedField model filtered by the contributor and getting a distinct, values_list of field names.
• Exclude extended profile fields from the sidebar in embed mode if their field names are not returned from the endpoint.

cc @katieashaw

[katieashaw]

Does this link to #1522 ?

[mariel-oar]

As a related item to this ticket, I want to add that the informational text that displays on (i) hover and when additional filters are displayed should not show up for embedded map users. This is because they are custom selecting the fields they want to display and they have had the ability to add additional custom fields (overlapping with extended field data) for some time now.

[mariel-oar]

This may be more related to #1522 which is closed, but we are still seeing this issue where fields that do not have data (e.g. the contributed list does not include product type) is still showing up on the profile.

See these facilities (both contributed by EM users): KR2020357B89R59 BD202005316M1V9

[hlennett]

I think you'll need the map links to see those examples in action, so I'll add those here:

Look for KR2020357B89R59 in: https://www.columbiasportswearcompany.com/corporate-responsibility-group/responsible-practices/supply-chain/

Look for BD202005316M1V9 in: https://www.levistrauss.com/sustainability-report/community/supplier-map/

[hlennett]

Noting that the second part of this issue (Fields still displaying on facility profiles in Embedded Maps when they are empty), still persists:

Look for KR2020357B89R59 in Columbia's test map: https://open-apparel-registry.github.io/embeded-map-test-fixed-size.html?host=staging.openapparel.org&contributors=2340. This example involves fields beyond EP.

Look for GB2021043HYQMT9 in Ted Baker's test map: https://open-apparel-registry.github.io/embeded-map-test-fixed-size.html?host=staging.openapparel.org&contributors=2025. This has Parent Company blank, which is an EP field.

[hlennett]

Noting that the i hover and search text is still appearing in Embedded Maps on staging.

[jwalgran]

Thank you for the very specific and helpful test details, @hlennett .

I submitted a quick change for review in #1800 that will remove the explanatory text. There will be additional pull requests to address the profile display issues.

For engineers: I traced the Ted Baker example and I believe we are creating showing an empty Parent Company because Ralph Lauren Corporation has submitted a parent company value for the facility but we are filtering it out on Ted Baker's embedded map.

Embed fields and extended fields have separate data sources but we may be able to share "hide the header if there is no values" code between them.

[marsabraw]

Other behavior that may be related to this ticket:

More strange behavior like the Ted Baker example above:

Hylo Athletics has not submitted any additional data points. And, this facility doesn't have any additional data points on production: CN20213075BDSVH. However, on their Embedded Map, there are a bunch of additional data points listed on that facility profile.

Same exact situation with Kathmandu Holdings. BD2021320X5J73E has no additional data points and yet additional data is appearing on that facility profile on their Embedded Map.

[mariel-oar]

Some testing feedback:

• Confirming that Reformation does not show any additional filters
• Levi’s shows parent company and no. of workers (question for OAR: is Levi’s submitting some points, e.g. product type, anonymously through API but others non-anonymously? E.g.: https://openapparel.org/facilities/GT2019083TBFK70?contributors=25
• PST does not show any
• RL shows all 5 additional filters
• Incorrect → Hylo does not show any (but on their facilities they do have product type, number of workers, and facility type listed)

[katieashaw]

Responding to your Q @mariel-oar Levi does not have a connection to our API, so that can't be the source of the anonymous product type contributions. I'd hazard a guess that a brand submitted those product types, then refreshed their list without them, so the named contribution was broken. That would mimic the behaviour of name / address contributions, but we'd need Azavea to confirm that behaviour for additional data points.

[jwalgran]

I see Hylo Athletics as contributor ID 1879 on staging

https://staging.openapparel.org/?contributors=1879

This is there embed test link on staging

https://open-apparel-registry.github.io/embeded-map-test-full-width.html?host=staging.openapparel.org&protocol=https&contributors=1879

When I look at the details of the three facilities I do not see any additional data points

https://staging.openapparel.org/facilities/CN20213075BDSVH?contributors=1879 https://staging.openapparel.org/facilities/CN2021307FP5FE7?contributors=1879 https://staging.openapparel.org/facilities/CN2021307W1C26H?contributors=1879

I also don't see any extended field data in the staging database for that contributor

select * from api_extendedfield where contributor_id = 1879;

 id | is_verified | field_name | value | created_at | updated_at | contributor_id | facility_id | facility_claim_id | facility_list_item_id
----+-------------+------------+-------+------------+------------+----------------+-------------+-------------------+-----------------------
(0 rows)

[jwalgran]

In our checkin call we determined that the Hylo data was updated before extended profile and so these are contributor fields, not extended fields. The OAR team will let Hylo know that they will need to reupload with the new extended field names.

At this point I do not thing we need additional code changes for this issue.