Looks like you are looking for the "proxy user" feature in some services (second bullet)?
Koji has a feature called "proxy user". With this feature one user (the proxy, eg. Packit) can act on behalf of another user, eg. create a build for a packager.
Likewise, waiverdb has the same feature - a proxy user can create waivers on behalf of someone else.
Other services may have it too, I don't remember off the top of my head.
Which services exactly you would expect to have this "proxy user" feature?

I think option 3 is the easiest. A Fedora Message as two properties that can be of interest here:

• agent_name: the FAS username of the person who caused the action
• usernames: a list of FAS usernames of people affected by the action

FMN will, by default, notify everybody in usernames except the person in agent_name (unless they selected "Notify me of my own actions").

Reference: https://fedora-messaging.readthedocs.io/en/stable/user-guide/messages.html#useful-accessors

So I would suggest using the usernames property in Packit's message schemas to send out notifications to people interested in the Packit action that just occurred, such as package maintainers.
If the action was caused by a specific user (e.g when a new release is published), then I think it makes sense to put their FAS username in agent_name, so they won't be notified of their own actions unless requested. If the action was caused by Packit itself (e.g when a build has completed), then I would put packit (or None if packit doesn't have a FAS account) in agent_name.

Looks like you are looking for the "proxy user" feature in some services (second bullet)?
Koji has a feature called "proxy user". With this feature one user (the proxy, eg. Packit) can act on behalf of another user, eg. create a build for a packager.
Likewise, waiverdb has the same feature - a proxy user can create waivers on behalf of someone else.
Other services may have it too, I don't remember off the top of my head.

Thanks @mizdebsk for your response. Yes, "proxy user" is a good term for this.

And it's good to know that such a thing already exists in some services. I'll take a look. Thanks for the suggestion.

Which services exactly you would expect to have this "proxy user" feature?

Currently, we mainly communicate with dist-git, Koji and Bodhi. (With dist-git, it's not necessary. )

@mizdebsk , can you please point me to the code/docs to check how this works? I am struggling to find it..;(

Otherwise, how does authentication work, can anyone freely impersonate anyone else? Or, is there any approval process?

I think option 3 is the easiest. A Fedora Message as two properties that can be of interest here:

• agent_name: the FAS username of the person who caused the action
• usernames: a list of FAS usernames of people affected by the action

FMN will, by default, notify everybody in usernames except the person in agent_name (unless they selected "Notify me of my own actions").

Reference: https://fedora-messaging.readthedocs.io/en/stable/user-guide/messages.html#useful-accessors

So I would suggest using the usernames property in Packit's message schemas to send out notifications to people interested in the Packit action that just occurred, such as package maintainers.
If the action was caused by a specific user (e.g when a new release is published), then I think it makes sense to put their FAS username in agent_name, so they won't be notified of their own actions unless requested. If the action was caused by Packit itself (e.g when a build has completed), then I would put packit (or None if packit doesn't have a FAS account) in agent_name.

Hello @abompard and thanks for another good pointer!

How can the message-bus message be transformed into a user notification?

Currently, Packit does not send any messages to the bus (we just listen).
So, we should either create our own messages (mostly a duplicate of existing ones from Koji/Bodhi/..), or help with somehow adding the "missing info" to the existing messages from Koji/Bodhi.

@mizdebsk , can you please point me to the code/docs to check how this works? I am struggling to find it..;(

In case of Koji, see koji list-api:

sslLogin(*args, **opts)
  description: Login via SSL certificate

    :param str proxyuser: proxy username
    :returns dict: session info

The proxy authenticates to Koji HUB with its own credentials, but during login passes "proxyuser" parameter indicating that the proxy is acting on behalf of someone else.

(The sslLogin method name may be misleading, but it is actually used in Krb auth too.)

Code example: https://pagure.io/fm-orchestrator/c/df594da8a5b28bc5eba5ba89c7661a1381904b10

(It was removed because back then MBS was using SSL auth, but packagers were switched to Krb auth. Nowdays everything should work with Krb.)

Otherwise, how does authentication work, can anyone freely impersonate anyone else? Or, is there any approval process?

Koji hub has configuration option that limits who can be a proxy. Once configured, given proxy user can act on behalf of all other users.

Examples of existing use cases of proxy user that are implemented:

• packager requests module build in MBS, MBS acting as a proxy submits RPM builds to Koji
• packager uses CI dashboard to create waivers, CI dashboard acts as proxy and submits waiver in waiverdb on packagers behalf

Thanks @mizdebsk for the examples, these are quite similar to our use case. We would just use the main maintainer (or let the user choose).

If Packit can get this permission, I think that's another reason to have a separate instance and/or FAS account to handle Fedora automation.

So, where are we here? Whats next actions and done by whom?

Thanks @kevin for the reminder.

I hope we've improved the situation for Packit users to suggest and document how to configure notifications: https://packit.dev/docs/fedora-releases-guide/fedora-notifications

This works quite well and I like that this is not a Packit-specific feature so everyone can do the same. (I.e. people being notified about activities of co-maintainers)

But I still worry this is not ideal since it's not done by default.
So, I can see these options:

1. Let Packit act as a proxy user (Packit triggers action but the user is visualised and notified)
   * Similarly how Bodhi uses the Koji submitter for automatic Rawhide updates.
   * Could better show a real and responsible person instead of a bot.
   * What would be needed: looks like Koji can do this, I am not sure about Bodhi. We would also need to rethink Packit identity/authentication.

2. Add the possibility to specify people to notify when triggering actions
   * When submitting a build or creating an update, one can specify people to be notified.
   * What would be needed: This would probably need to be implemented in the services (we are interested in Koji and Bodhi).

3. Create a new message relay
   * Packit can listen to the messages and forward them to the relevant packager.
   * I don't like that this basically reinvents FMN.
   * What would be needed: New Packit-specific service.

4. Simplify/automate FMN rule creation
   * Find a way how to increase the chance that a user configures the notification -- e.g.:

   • provide URL with prefilled details of the rule (login and confirm is the only action needed)
   • create this rule for the user automatically
   • Set up the rule for the user automatically as a reaction to an explicit action by the user, e.g. :thumbs-up: to the Packit comment)
   • What would be needed: depends on the solution

I would rather avoid version 3 and am worried version 1 could take too much work.

Does anyone have any other ideas? Am I missing something more straightforward? I hope if we agree on the way forward we can move on to the specific tasks...