NextERP/runbot
5
0
Fork 0
mirror of https://github.com/odoo/runbot.git synced 2025-03-15 23:45:44 +07:00
Code Issues Actions Packages Projects Releases Wiki Activity
18.0
runbot/runbot_merge/security/ir.model.access.csv

37 lines
4.5 KiB
Plaintext
Raw Permalink Normal View History

[FIX] runbot_merge: work with admin[uid=2] * correctly fetch the admin's uid when running remote tests * looks like I had forgotten to add any sort of access rights, so add some
2018-08-27 20:28:22 +07:00
id,name,model_id:id,group_id:id,perm_read,perm_write,perm_create,perm_unlink
access_runbot_merge_project_admin,Admin access to project,model_runbot_merge_project,runbot_merge.group_admin,1,1,1,1
[ADD] runbot_merge: ~~tree~~ freeze wizard Provides a less manual interface for creating the freeze: * takes the name of the branch to create * takes any number of PRs which must be part of the freeze * takes PRs representing the HEADs of the new branches Then essentially takes care of the test. Implementation of the actual wizard is not trivial but fairly straightforward and linear, biggest issue is not being able to `project_id.branch_ids[1]` to get the new branch, not sure why but it seems to ignore the ordering, clearing the cache doens't fix it. When creating the branches, add a sleep after each one for secondary rate limiting purposes. Same when deleting branches. Also the forwardbot has been updated to disable the forwardport cron while a freeze is ongoing, this simplifies the freezing process. Note: after recommendation of @aab-odoo, tried using `_applyChanges` in `_checkState` but it simply did not work: the two relational fields got completely frozen and were impossible to update, which is less than ideal. Oh well, hopefully it works well enough like this for now.
2021-11-12 22:04:34 +07:00
access_runbot_merge_project_freeze,Admin access to freeze wizard,model_runbot_merge_project_freeze,runbot_merge.group_admin,1,1,0,0
[FIX] runbot_merge: make freeze wizard labels lookup not shit I DECLARE BANKRUPTCY!!! The previous implementation of labels lookup was really not intuitive (it was just a char field, and matched labels by equality including the owner tag), and was also full of broken edge cases (e.g. traceback if a label matched multiple PRs in the same repo because people reuse branch names). Tried messing about with contextual `display_name` and `name_search` on PRs but the client goes wonky in that case, and there is no clean autocomplete for non-relational fields. So created a view which reifies labels, and that can be used as the basis for our search. It doesn't have to be maintained by hand, can be searched somewhat flexibly, we can add new view fields in the future if desirable, and it seems to work fine providing a nice understandable UX, with the reliability of using a normal Odoo model the normal way. Also fixed the handling of bump PRs, clearly clearing the entire field before trying to update existing records (even with a link_to inbetween) is not the web client's fancy, re-selecting the current label would just empty the thing entirely. So use a two-step process slightly closer to the release PRs instead: - first update or delete the existing bump PRs - then add the new ones The second part is because bump PRs are somewhat less critical than release, so it can be a bit more DWIM compared to the more deliberate process of release PRs where first the list of repositories involved has to be set up just so, then the PRs can be filled in each of them. Fixes #697
2023-01-24 17:19:18 +07:00
access_runbot_merge_project_freeze_prs,Admin access to freeze wizard release prs,model_runbot_merge_project_freeze_prs,runbot_merge.group_admin,1,1,1,1
[IMP] *: freeze wizard v3, freezer and wizarder Stop *staging* release PRs: they are normally fairly simple and should not fail their staging outside of unreliable tests (or possibly a few edge cases e.g. forgot one version change thing), however staging them creates the possibility of a "version hole" on the release branch which is undesirable. Instead, immediately and unconditionally push the release commits onto the newly created branches, if there are things which don't work they can be fixed afterwards (and the process refined, maybe). Also add the same feature for *bump* PRs, with the difference that the bump PRs are not created / requested by default (they have to be opted in individually). For convenience, add a feature which automatically finds the PRs via inputting the label (not really tested yet). Closes #603
2022-07-11 13:17:04 +07:00
access_runbot_merge_project_freeze_bumps,Admin access to freeze wizard bump prs,model_runbot_merge_project_freeze_bumps,runbot_merge.group_admin,1,1,1,1
[FIX] runbot_merge: make freeze wizard labels lookup not shit I DECLARE BANKRUPTCY!!! The previous implementation of labels lookup was really not intuitive (it was just a char field, and matched labels by equality including the owner tag), and was also full of broken edge cases (e.g. traceback if a label matched multiple PRs in the same repo because people reuse branch names). Tried messing about with contextual `display_name` and `name_search` on PRs but the client goes wonky in that case, and there is no clean autocomplete for non-relational fields. So created a view which reifies labels, and that can be used as the basis for our search. It doesn't have to be maintained by hand, can be searched somewhat flexibly, we can add new view fields in the future if desirable, and it seems to work fine providing a nice understandable UX, with the reliability of using a normal Odoo model the normal way. Also fixed the handling of bump PRs, clearly clearing the entire field before trying to update existing records (even with a link_to inbetween) is not the web client's fancy, re-selecting the current label would just empty the thing entirely. So use a two-step process slightly closer to the release PRs instead: - first update or delete the existing bump PRs - then add the new ones The second part is because bump PRs are somewhat less critical than release, so it can be a bit more DWIM compared to the more deliberate process of release PRs where first the list of repositories involved has to be set up just so, then the PRs can be filled in each of them. Fixes #697
2023-01-24 17:19:18 +07:00
access_runbot_merge_pr_labels,Admin access to labels view,model_runbot_merge_freeze_labels,runbot_merge.group_admin,1,0,0,0
[FIX] runbot_merge: work with admin[uid=2] * correctly fetch the admin's uid when running remote tests * looks like I had forgotten to add any sort of access rights, so add some
2018-08-27 20:28:22 +07:00
access_runbot_merge_repository_admin,Admin access to repo,model_runbot_merge_repository,runbot_merge.group_admin,1,1,1,1
[IMP] runbot_merge: split status configuration into own object Having the required statuses be a mere list of contexts has become a bit too limiting for our needs as it doesn't allow e.g. adding new required statuses on only some branches of a repository (e.g. only master), nor does it allow putting checks on only branches, or only stagings, which would be useful for overridable checks and the like, or for checks which only make sense linked to a specific revision range (e.g. "incremental" linting which would only check whatever's been modified in a PR). Split the required statuses into a separate set of objects, any of which can be separately marked as applying only to some branches (no branch = all branches). Fixes #382
2020-07-10 15:21:43 +07:00
access_runbot_merge_repository_status_admin,Admin access to repo statuses,model_runbot_merge_repository_status,runbot_merge.group_admin,1,1,1,1
[FIX] runbot_merge: work with admin[uid=2] * correctly fetch the admin's uid when running remote tests * looks like I had forgotten to add any sort of access rights, so add some
2018-08-27 20:28:22 +07:00
access_runbot_merge_branch_admin,Admin access to branches,model_runbot_merge_branch,runbot_merge.group_admin,1,1,1,1
access_runbot_merge_pull_requests_admin,Admin access to PR,model_runbot_merge_pull_requests,runbot_merge.group_admin,1,1,1,1
access_runbot_merge_pull_requests_tagging_admin,Admin access to tagging,model_runbot_merge_pull_requests_tagging,runbot_merge.group_admin,1,1,1,1
[ADD] runbot_merge: small wizard to split a PR off of its batch
2024-07-15 20:14:23 +07:00
access_runbot_merge_pull_requests_split_admin,Admin access to batch split wizard,model_runbot_merge_pull_requests_split_off,runbot_merge.group_admin,1,1,1,1
[FIX] runbot_merge: work with admin[uid=2] * correctly fetch the admin's uid when running remote tests * looks like I had forgotten to add any sort of access rights, so add some
2018-08-27 20:28:22 +07:00
access_runbot_merge_commit_admin,Admin access to commits,model_runbot_merge_commit,runbot_merge.group_admin,1,1,1,1
access_runbot_merge_stagings_admin,Admin access to stagings,model_runbot_merge_stagings,runbot_merge.group_admin,1,1,1,1
[IMP] runbot_merge: split staging heads out to join tables Currently the heads of a staging (both staging heads and merged heads) are just JSON data on the staging itself. Historically this was convenient as the heads were mostly of use to the staging process, and thus accessed directly through the staging essentially exclusively. However this makes finding stagings from merged commits e.g. for forensic research almost impossible, because querying based on the *values* of a JSON map is expensive, and indexing it is difficult. To make this use case more feasible, split the `heads` field into two join tables, one for the staging heads and one for the merged heads, this makes looking for stagings by commits much more efficient (although the queries may not be trivial). Also add two utility RPC methods, so that it's possible to query stagings reasonably easily and efficiently based on a set of commits (branch heads). related to #768
2023-08-10 14:02:37 +07:00
access_runbot_merge_stagings_heads_admin,Admin access to staging heads,model_runbot_merge_stagings_heads,runbot_merge.group_admin,1,1,1,1
access_runbot_merge_stagings_commits_admin,Admin access to staging commits,model_runbot_merge_stagings_commits,runbot_merge.group_admin,1,1,1,1
[ADD] runbot_merge: stagings canceling wizard - allows providing a canceling reason - allows nuking the splits at the same time (hopefully) Fixes #661
2022-12-07 20:45:48 +07:00
access_runbot_merge_stagings_cancel_admin,Admin access to cancelling stagings,model_runbot_merge_stagings_cancel,runbot_merge.group_admin,1,1,1,1
[FIX] runbot_merge: work with admin[uid=2] * correctly fetch the admin's uid when running remote tests * looks like I had forgotten to add any sort of access rights, so add some
2018-08-27 20:28:22 +07:00
access_runbot_merge_split_admin,Admin access to splits,model_runbot_merge_split,runbot_merge.group_admin,1,1,1,1
access_runbot_merge_batch_admin,Admin access to batches,model_runbot_merge_batch,runbot_merge.group_admin,1,1,1,1
[IMP] runbot_merge: preserve batch ordering in stagings Batch ordering in stagings is important in order to correctly reconstitute the full project history. In the old mergebot, since batches are created on the fly during staging this information is reified by the batch ids. But since batch ids are now persistent and there is no relationship between the creation of a batch and its merging (especially not relative to other batches) it's an issue as reconstituting sub-staging git history would be impossible. Which is not the worst, but is not great. The solution is to reify the join table between stagings and batches in order for *that* to keep history (simply via the sequential PK), and in converting to the new system carefully generate the new links in an order matching the old batch ids.
2024-05-17 15:51:16 +07:00
access_runbot_merge_staging_batch_admin,Admin access to batch/staging link,model_runbot_merge_staging_batch,runbot_merge.group_admin,1,1,1,1
[FIX] runbot_merge: work with admin[uid=2] * correctly fetch the admin's uid when running remote tests * looks like I had forgotten to add any sort of access rights, so add some
2018-08-27 20:28:22 +07:00
access_runbot_merge_fetch_job_admin,Admin access to fetch jobs,model_runbot_merge_fetch_job,runbot_merge.group_admin,1,1,1,1
[IMP] runbot_merge: ACL & PR name * add missing ACL for PR feedback object * configure name_get for PRs (which don't have a name), fixes some layout issues & stuff
2019-08-23 21:16:30 +07:00
access_runbot_merge_pull_requests_feedback_admin,Admin access to feedback,model_runbot_merge_pull_requests_feedback,runbot_merge.group_admin,1,1,1,1
[IMP] runbot_merge: make review rights repo-dependent As the odds of having more projects or more repos with different requirements in the same project, the need to have different sets of reviewers for different repositories increases. As a result, rather than be trivial boolean flags the review info should probably depend on the user / partner and the repo. Turns out the permission checks had already been extracted into their own function so most of the mess comes from testing utilities which went and configured their review rights as needed. Incidentally it might be that the test suite could just use something like a sequence of commoditized accounts which get configured as needed and not even looked at unless they're used.
2020-02-10 21:05:08 +07:00
access_runbot_merge_review_rights,Admin access to review permissions,model_res_partner_review,runbot_merge.group_admin,1,1,1,1
[ADD] runbot_merge: allow overriding statuses Adds an `override` mergebot command. The ability to override is set on an individual per-context per-repository basis, similar to but independent from review rights. That is, a given individual may be able to override the status X on repository A and unable to do so on repository B. Overrides are stored in the same format as regular statuses, but independent from them in order to persist them across builds. Only PR statuses can be overridden, statuses which are overridable on PRs would simply not be required on stagings. An alternative to implementing this feature in the mergebot would be to add it to individual status-generating tools on a per-need basis. Pros of that alternative: * display the correct status on PRs, currently the PR will be failing status-wise (on github) but correct as far as the mergebot is concerned * remove complexity from the mergebot Cons of that alternative: * each status-generating tool would have to implement some sort of ACL system * each status-generating tool would have to receive & parse PR comments * each status-generating tool would have to maintain per-pr state in order to track overrides Some sort of helper library / framework ought make that rather easy though. It could also be linked into the central provisioning system thing. Closes #376
2020-07-14 15:06:07 +07:00
access_runbot_merge_review_override,Admin access to override permissions,model_res_partner_override,runbot_merge.group_admin,1,1,1,1
[ADD] *: per-repository webhook secret Currently webhook secrets are configured per *project* which is an issue both because different repositories may have different administrators and thus creates safety concerns, and because multiple repositories can feed into different projects (e.g. on mergebot, odoo-dev/odoo is both an ancillary repository to the main RD project, and the main repository to the minor / legacy master-wowl project). This means it can be necessary to have multiple projects share the same secret as well, this then mandates the secret for more repositories per (1). This is a pain in the ass, so just detach secrets from projects and link them *only* to repositories, it's cleaner and easier to manage and set up progressively. This requires a lot of changes to the tests, as they all need to correctly configure the signaling. For `runbot_merge` there was *some* setup sharing already via the module-level `repo` fixtures`, those were merged into a conftest-level fixture which could handle the signaling setup. A few tests which unnecessarily set up repositories ad-hoc were also moved to the fixture. But for most of the ad-hoc setup in `runbot_merge`, as well as `forwardport` where it's all ad-hoc, events sources setup was just appended as is. This should probably be cleaned up at one point, with the various requirements collected and organised into a small set of fixtures doing the job more uniformly. Fixes #887
2024-06-06 16:07:57 +07:00
access_runbot_merge_events_sources,Admin access to event sources,model_runbot_merge_events_sources,runbot_merge.group_admin,1,1,1,1
[FIX] runbot_merge: work with admin[uid=2] * correctly fetch the admin's uid when running remote tests * looks like I had forgotten to add any sort of access rights, so add some
2018-08-27 20:28:22 +07:00
access_runbot_merge_project,User access to project,model_runbot_merge_project,base.group_user,1,0,0,0
access_runbot_merge_repository,User access to repo,model_runbot_merge_repository,base.group_user,1,0,0,0
access_runbot_merge_branch,User access to branches,model_runbot_merge_branch,base.group_user,1,0,0,0
access_runbot_merge_pull_requests,User access to PR,model_runbot_merge_pull_requests,base.group_user,1,0,0,0
[IMP] runbot_merge: ACL & PR name * add missing ACL for PR feedback object * configure name_get for PRs (which don't have a name), fixes some layout issues & stuff
2019-08-23 21:16:30 +07:00
access_runbot_merge_pull_requests_feedback,Users have no reason to access feedback,model_runbot_merge_pull_requests_feedback,,0,0,0,0
[ADD] runbot_merge: allow overriding statuses Adds an `override` mergebot command. The ability to override is set on an individual per-context per-repository basis, similar to but independent from review rights. That is, a given individual may be able to override the status X on repository A and unable to do so on repository B. Overrides are stored in the same format as regular statuses, but independent from them in order to persist them across builds. Only PR statuses can be overridden, statuses which are overridable on PRs would simply not be required on stagings. An alternative to implementing this feature in the mergebot would be to add it to individual status-generating tools on a per-need basis. Pros of that alternative: * display the correct status on PRs, currently the PR will be failing status-wise (on github) but correct as far as the mergebot is concerned * remove complexity from the mergebot Cons of that alternative: * each status-generating tool would have to implement some sort of ACL system * each status-generating tool would have to receive & parse PR comments * each status-generating tool would have to maintain per-pr state in order to track overrides Some sort of helper library / framework ought make that rather easy though. It could also be linked into the central provisioning system thing. Closes #376
2020-07-14 15:06:07 +07:00
access_runbot_merge_review_rights_2,Users can see partners,model_res_partner_review,base.group_user,1,0,0,0
access_runbot_merge_review_override_2,Users can see partners,model_res_partner_override,base.group_user,1,0,0,0
[ADD] runbot_merge: support for unstaged patches Unstaged changes can be useful or necessary for some tasks e.g. absolute emergency (where even faking the state of a staging is not really desirable, if that's even possible anymore), or changes which are so broad they're difficult to stage (e.g. t10s updates). Add a new object which serves as a queue for patch to direct-apply, with support for either text patches (udiff style out of git show or format-patch) or commits to cherry-pick. In the former case, the part of the show / format-patch before the diff itself is used for the commit metadata (author, committer, dates, message) whereas for the commit version the commit itself is reused as-is. Applied patches are simply disabled for traceability. Fixes #926
2024-10-02 17:14:09 +07:00
access_runbot_merge_pull_requests_feedback_template,access_runbot_merge_pull_requests_feedback_template,runbot_merge.model_runbot_merge_pull_requests_feedback_template,base.group_system,1,1,0,0
access_runbot_merge_patch,Patcher access,runbot_merge.model_runbot_merge_patch,runbot_merge.group_patcher,1,1,1,0
[IMP] runbot_merge: inspectability of patch parsing Show patch metadata on the patch screen, so it's easier to understand what the parser sees in case of issues. Behaviour is not *entirely* consisten, `file_ids` is correctly set but it looks like during the initial `web_read` it gets stripped out in at least some cases and the files list is empty even though files have been found in the patch. nm. Fixes #987
2024-11-28 21:41:42 +07:00
access_runbot_merge_patch_file,Patcher access to patch file,model_runbot_merge_patch_file,runbot_merge.group_patcher,1,0,0,0
[ADD] *: PR backport wizard This is not a full user-driven backport thingie for now, just one admins can use to facilitate thing and debug issues with the system. May eventually graduate to a frontend feature. Fixes #925
2024-10-22 15:53:45 +07:00
access_runbot_merge_backport_admin,Admin access to backport wizard,model_runbot_merge_pull_requests_backport,runbot_merge.group_admin,1,1,1,0
Reference in New Issue Copy Permalink