* feat: persistent table query
* project overview sort query
* refactor: api methods as hook callbacks
* persitent columns in project overview
* enable new project overview
* fix: refactor feature state change in overview
* add type to sort
* update e2e tests
now takes 10% less time with use of cypress session
* prevent sort reset on features list
* fix feature toggle list loading
* fix: update column state saving
* update local storage hook test
The `pull_request` hook runs in the context of the proposed changes. That means that for forks, this action won't have access to the required secrets for it to complete. As such, PRs from outside contributors won't work correctly.
The `pull_request_target` hook, however, runs in the context of the target branch, and thus has all the permissions it needs. The [github docs for this hook](https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target) also indicate that this is the way to go:
> This event allows your workflow to do things like label or comment on pull requests from forks. Avoid using this event if you need to build or run code from the pull request.
## Interesting note for PRs
It seems that when this change is proposed as a PR, the expected action (_add new item to project board_) does not run. However, this does not affect other new PRs. After merging, the pipeline works and triggers as expected, for both external and internal contributors.
## Isn't this potentially dangerous?
Good question! As far as I understand: no, it's not. The long answer is in [Keeping your GitHub Actions and workflows secure Part 1: Preventing pwn requests](https://securitylab.github.com/research/github-actions-preventing-pwn-requests/), but I'll try and summarize it here.
Some choice cuts from the article:
> TL;DR: Combining pull_request_target workflow trigger with an **explicit checkout of an untrusted PR** is a dangerous practice that may lead to repository compromise.
However, we do not check the PR out!
> Due to the dangers inherent to automatic processing of PRs, GitHub’s standard pull_request workflow trigger by default prevents write permissions and secrets access to the target repository. However, in some scenarios such access is needed to properly process the PR. To this end the pull_request_target workflow trigger was introduced.
> pull_request_target runs in the context of the target repository of the PR, rather than in the merge commit. This means the standard checkout action uses the target repository to prevent accidental usage of the user supplied code.
> These safeguards enable granting the pull_request_target additional permissions. The reason to introduce the pull_request_target trigger was to enable workflows to label PRs (e.g. needs review) or to comment on the PR. The intent is to use the trigger for PRs that do not require dangerous processing, say building or running the content of the PR.
That is: when using `pull_request_target`, the action will not check out the PR branch and thus, the PR cannot inject any code changes into the action. On the other hand `pull_request` uses the code that's in the PR to run actions, which is why it requires explicit authorization before being run.
`pull_request_target` runs in the context of the target branch (most commonly `main`) and only runs code that already exists in the target branch. No code from the PR gets used.
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
* refactor: show save button before using the dropdown
* refactor: simplify FeatureSettingsProject toast message
* refactor: fix FeatureProjectSelect filter prop type
* refactor: hide change project page for non-enterprise
* refactor: derive move targets from projects list instead of from permissions
* refactor: align frontend project compat check with backend
* refactor: fix useProject object stability
* refactor: disable the save button for the current project
* refactor: require equal environments when moving toggles
* refactor: improve arraysHaveSameItems name
* fix: Block user from turning on default env in project view
* fix: Allow changing environment state for default in a project if using non OSS
Co-authored-by: Fredrik Strand Oseberg <fredrik.no@gmail.com>
