members: only use base attrs in user relationship

[egabancho]

• Limits the user fields send for indexing to avoid issues when extending the user profile. (closes Invenio indexer task process_bulk_queue fails with extended user profile invenio-app-rdm#2198)

❤️ Thank you for your contribution!

Description

Please describe briefly your pull request.

Checklist

Ticks in all boxes and 🟢 on all GitHub actions status checks are required to merge:

• I'm aware of the code of conduct.
• I've created logical separate commits and followed the commit message format.
• I've added relevant test cases.
• I've added relevant documentation.
• I've marked translation strings (for relevant code).
• I've followed the CSS/JS and React guidelines (for relevant code).
• I've followed the web accessibility guidelines (for relevant code).
• I've followed the user interface guidelines (for relevant code).
• I've identified the copyright holder(s) and updated copyright headers for touched files (>15 lines contributions).
• I've NOT included third-party code (copy/pasted source code or new dependencies).

Third-party code

If you've added third-party code (copy/pasted or new dependencies), please reach out to an architect.

Reminder

By using GitHub, you have already agreed to the GitHub’s Terms of Service including that:

1. You license your contribution under the same terms as the current repository’s license.
2. You agree that you have the right to license your contribution under the current repository’s license.

[egabancho]

Sorry @max-moser, you seemed to be the one who made that change on the user schema, inveniosoftware/invenio-users-resources@492f14b ☺️

[egabancho]

I'm not sure how to write a test to verify it, I can duplicate the one on https://github.com/inveniosoftware/invenio-accounts/blob/master/tests/test_models.py#L120, but I'm not sure how useful it will be.

[lnielsen]

I would not go with dynamic here. I just had a large mishap with a custom field that wasn't created in the mapping, then a user filling some data into and voila, had to reindex 70GB of data because you cannot change the type once added to the mapping :-(

These models are also supposed to only contain basic info, not everything, so perhaps it's just a matter to make sure we don't get the full profile when we index in members? In principle it should only index the stuff in https://github.com/inveniosoftware/invenio-communities/blob/master/invenio_communities/members/records/api.py#L70-L76

[egabancho]

What you say makes a lot of sense. Now I just need to figure out how to do actually do it 😂
Thanks for the feedback!

[egabancho]

Hey @lnielsen, I changed the approach as you suggested. I explicitly list the fields we want from the two customizable parts: profile and preferences.
The only drawback I see is that if the overlay's custom code removes those fields from their custom schemas. However, I think other parts might depend on these fields too ...
Let me know what you think.

[egabancho]

Since this one was opened, a different merge request has been integrated, which adds dynamic to the mappings.

The question now is whether or not we want to integrate this one and revert the changes introduced to prevent the scenario described previously.

cc-ing @slint and @max-moser

[max-moser]

If I understand correctly, this only relates to how users get indexed as community members?
I.e., worst case, some custom user preference/profile fields aren't available for searching community members?
So far, we haven't had any nonstandard use cases for searching community members, and I doubt we will have any in the future.

As a bit of context:
It's been a hot minute since the referenced PR, but IIRC, the issue it solved was that our user profile/preferences customizations broke indexing of users and/or communities at the time.
The changes followed the same approach as was already used in the user mappings.

Since the dynamic mappings are always interpreted as keyword, I think the biggest pitfall (of random and potentially unwanted types for the mapping being chosen on first encounter) is avoided.

That being said, I don't have a real preference on how custom user fields are handled in the context of communities, as long as extended user properties don't break stuff again.

For searching for users directly (invenio-users-resources), I think it can be useful to query the customized extra fields, though.