Improve workflow conditions based on repo meta infos

[NiklasBuchfink]

Context

Users have trouble with pushing because Fink isn't aware of
Therefore the lix API was extend by:

• LIX-82
• https://github.com/opral/monorepo/pull/2897

Proposal

by Jan https://github.com/opral/monorepo/pull/2897#issuecomment-2152810158:

• [ ] check if forking is allowed, if not hide the fork feature
• [ ] user has admin rights permissions.admin, if not and app not installed, disable push and tell user to have admin install app
• [ ] if pull permission is false and allow forking is true only show the forking workflow

---

• [X] update "Cannot access the repository**"** card to include the installation of the inlang GitHub app by the repository owner

[NiklasBuchfink]

@jan.johannes I created some cases with a second test user:

1. "hiding the fork feature if forking is not allowed" is not needed as this feature only exists on private repos in organizations:
   a) User is not a collaborator and can't load the repo
   b) User is a collaborator and collaborators are allowed to push directly (or create PRs via branches which is not implemented yet)
2. admins can't install apps. Even admins can only request an installation or update of the permissions from the owners of the repo/organization. To know if a user can update the app's permissions, we need to know the owner status instead.
3. I don't know if "not having pull permissions" is a case because there is no role for that.
   a) If a user has no permissions to the repo, he can't open it
   b) With read-only access to a repo, he has rights to clone or pull and he is prompted to update the app permissions as the returning code is 403. We should distinguish this from the missing app permission and the user not having sufficient permissions from the organization.

In any case, the user can click on add permissions and select the organization to request permissions from the owner (if he is not the owner).

The important thing here is that we should detect, if the user and app have sufficient permissions to push or if user is able to update the permissions of the app in the organization. This way we can prompt the user before making changes that might be lost.

[NiklasBuchfink]

Scenario: User (Collaborator with push permissions) wants to contribute to a public repo. Here I see two common issues:

1. User installs the app not for the organization, but for the own account. It might be possible to skip the selection, by fetching the target-id of the GitHub repo and direct to https://github.com/apps/inlang-dev2/installations/new/permissions?target_id={target_id} instead of "https://github.com/apps/inlang-dev2/installations/select_target"
2. If the repo is public and the user is a collaborator, the user can make the changes and might be prompted to update the permissions. If the user is not a owner, an updated needs to be requested from the owner and the changes are lost.

[fabiopk]

I am also struggling with this issue.

I am trying on a private repo inside an organization. I am the owner of the organization. I have verified that inlang has access to the repo that I am trying to push to. I also tried to manually include myself on that specific repo. There are no special rules on any branched preventing commits or PRs. (I've tried selecting a branch which is not main as well).

I can open the repo and edit just fine. When I click push, I get the success toast on the bottom of the screen. But there aren't any new PRs on the repo

[janfjohannes]

@fabiopk why do you expect to get a pr when you press "push"? this will directly push your changes to the branch.