Investigate naming options for invite_email quickaction
Problem to solve
From #299261 (comment 1880705221):
One thought on the semantics of the quick action
/invite_email
, which partially overlaps with/add_contacts
due to being provided an email address, though in a different path.When adding external participants to a work item with
/invite_email
, they are immediately added as recipients to the next and following comments. This means, the terminvite
in the quick action is a bit misleading, as there will be no voluntary choice to be confirmed for being added as an email participant.With looking at the verbs
invite
andadd
, without assuming a manual opt-in workflow is neither desired nor considered right now, would it appear more conventional to speak about a quick action/add_email
or/add_participant
instead? Also, talking about participants instead had the benefit that the level of abstraction used to describe the object is the same as with/add_contact
.
This way both actions starting with/add_
would appear above each other in the autocomplete box. This in return would render the description texts visible at the same time and allow for a better disambiguation of the two similarly appearing functionalities with diverging side-effects.If
/invite_
is settled as a prefix for the existing action, I would like to propose to add an additionalnew_invite
message sent to invited participants, allowing them to opt-in explicitly.This is proposal is slightly different than the automatic notification
service_desk_new_participant_email
proposed in Adds Service Desk new participant email (!150706 - merged), as it requires explicit consent to opt-in.
Proposal
Explore adding an alias for /invite_email
like /add_email
or /add_participant
(thus also adding /remove_participant
).