Adding service component calls to methods in RecordCommunitiesService

[monotasker]

❤️ Thank you for your contribution!

Description

The unique methods in RecordCommunitiesService lack the call to service component methods that are usual in record service operations. This PR

• adds those calls in the add, remove, set_default, and bulk_add methods
• and adds a components property in the service config that reads components from the RDM_RECORD_COMMUNITIES_SERVICE_COMPONENTS variable if present (defaults to [])

The placement of the component calls in each method is intended to allow maximum customization of the service call's input data before the data is actually applied to change the records.

Note that in bulk_add I've wrapped the set_default argument value in a dictionary (making it mutable) so that it can be updated inside the components.

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.
• 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).
  • If you have added third-party code (copy/pasted or new dependencies), please reach out to an architect on Discord.

Frontend

• I've followed the CSS/JS and React guidelines.
• I've followed the web accessibility guidelines.
• I've followed the user interface guidelines.

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.

[github-actions]

This PR was automatically marked as stale.

[zzacharo]

I would align it with the permission so that is more readable in the instance's custom component you implement

Suggested change

	if hasattr(component, "add"):
	if hasattr(component, "add_community"):

What do you think?

[zzacharo]

discussion: Also, should we add this hook before the community.add(...) call or after @slint ?

[monotasker]

@zzacharo I'm happy to commit that suggested term change. My main concern with the placement is just making sure that the component method has access to the incoming data and the record object before that record has been changed. That way the data can be modified if desired before being applied.

[zzacharo]

I would move this to _remove after the permission checks and rename to remove_community. Also, the question on where to add the component hook is valid here too.

[monotasker]

If there's agreement on moving this to _remove, I'm happy to make that change.

Here again, my interest when it comes to placement is just making sure that we can modify the data (and see the record state) before the data has been applied.

[monotasker]

I'm just working on moving the component call locations and updating the tests. I'll squash the commits together and should have it ready for another review later today

[monotasker]

Alright, I've updated the PR and squashed the commits together (with a proper commit message). Sorry for the messy commits earlier, and thanks for your patience.

I renamed the methods as suggested and moved the component calls for remove into _remove. I have kept each of the component calls before the data in each case is actually applied to the record. (E.g., before record.parent.communities.add is called in the add method.) This is to allow modification of the data before it is applied to the record. I don't see any disadvantages of this placement, and it has the added benefit of providing the component method with the initial state of the record.