Why foreign accounts can add/remove issue dependencies and why I am not notified #1513

buhtz commented 2024年03月22日 14:04:25 +01:00

Comment

Please see this Issue as an example: buhtz/hyperorg#124

I was not notified via email about the modification of the "dependency" in this Issue. I am the owner of the repo and I am the opener of that Issue, so I am subscribed.

The person (@l-x) set this dependency don't have any permissons on my repo or my team. Why is she/he able to do something like this? Of course if my Issue is a dependency on some of his/her own repos Issues I have no problem. But this connection shouldn't be bidirectional. Persons other then repo owners should be able to modify dependencies.

No one was harmed. I just try to understand.

### Comment Please see this Issue as an example: https://codeberg.org/buhtz/hyperorg/issues/124 1. I was not notified via email about the modification of the "dependency" in this Issue. I am the owner of the repo and I am the opener of that Issue, so I am subscribed. 2. The person (@l-x) set this dependency don't have any permissons on my repo or my team. Why is she/he able to do something like this? Of course if my Issue is a dependency on some of his/her own repos Issues I have no problem. But this connection shouldn't be bidirectional. Persons other then repo owners should be able to modify dependencies. No one was harmed. I just try to understand.

Gusted commented 2024年03月25日 23:34:48 +01:00

I was not notified via email about the modification of the "dependency" in this Issue. I am the owner of the repo and I am the opener of that Issue, so I am subscribed.

As it's a 'minor' event, it's being treated the same as when milestone, labels or assignees are changed which don't cause notification as well.

Why is she/he able to do something like this? Of course if my Issue is a dependency on some of his/her own repos Issues I have no problem.

Because it doesn't affect the issue in anything, other than the event being added which is the same as when the issue is referenced by another issue, pull request or commit.

But this connection shouldn't be bidirectional. Persons other then repo owners should be able to modify dependencies.

Now we go a bit into a perfect world use case. For example lets say you want to use feature X, but it's not yet implemented or enabled by default in a library or software you're using and that project is hosted on the same instance. You can add a dependency to the related issue or pull request to "keep track" of that progress. Of course it also could be used accidental and causes unnecessary events to be added to the referenced issue or could be simply used to mark related issues.

There's a setting that can disable this behavior, but it's an instance-wide setting and the intended use case could be utilized quite well, even though I don't know of anyone actually using it that way.

> I was not notified via email about the modification of the "dependency" in this Issue. I am the owner of the repo and I am the opener of that Issue, so I am subscribed. As it's a 'minor' event, it's being treated the same as when milestone, labels or assignees are changed which don't cause notification as well. > Why is she/he able to do something like this? Of course if my Issue is a dependency on some of his/her own repos Issues I have no problem. Because it doesn't affect the issue in anything, other than the event being added which is the same as when the issue is referenced by another issue, pull request or commit. > But this connection shouldn't be bidirectional. Persons other then repo owners should be able to modify dependencies. Now we go a bit into a perfect world use case. For example lets say you want to use feature X, but it's not yet implemented or enabled by default in a library or software you're using and that project is hosted on the same instance. You can add a dependency to the related issue or pull request to "keep track" of that progress. Of course it also could be used accidental and causes unnecessary events to be added to the referenced issue or could be simply used to mark related issues. There's a setting that can disable this behavior, but it's an instance-wide setting and the intended use case could be utilized quite well, even though I don't know of anyone actually using it that way.