Refactor CreatorService for creating members
What does this MR do and why?
- Naming changes to better reflect we are adding members instead of users as
user
is overloaded and is easy to confuse with the modeluser
when we are in reality creating amember
record. Also, members can be byuser
or byemail
for people not registered in the product- change
add_user
toadd_member
- change
add_users
toadd_members
- change
user
toinvitee
in theCreatorService
- change
users
toinvitees
inadd_members
class method
- change
- General refactoring
-
CreatorService
for readability and long term management.
-
- Added query count on Invitations API for adding members by id
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #354016 (closed)
Edited by Doug Stull