mirror of
https://codeberg.org/forgejo/forgejo.git
synced 2025-09-30 19:22:08 +00:00
3 commits
Author | SHA1 | Message | Date | |
---|---|---|---|---|
|
9354efceb1 |
fix: quota evaluation rules not working properly (#9033)
This patch is mainly intended to fix forgejo/forgejo#7721, and to fix forgejo/forgejo#9019. It also changes the evaluation of 0 limits to prevent all writes, instead of allowing one write and then failing on subsequent writes after the limit has been exceeded. This matches the expectation of the existing tests, and I believe it will better match the expectations of users. Tests have been updated accordingly where necessary, and some additional test coverage added. The fixes in this PR depend on each other in order for the quota system to function correctly, so I'm submitting them as a single PR instead of individually. ## Test Cases ### Quota subjects not covered by their parent subjects Before enabling quotas, create a test user and test repository for that user. Enable quotas, and set a default total to some large value. (Do not use unit suffixes forgejo/forgejo#8996) ```ini [quota] ENABLED = true [quota.default] TOTAL = 1073741824 ``` With the test user, navigate to "Storage overview" and verify that the quota group "Global quota" is the only group listed, containing the rule "Default", and displays the configured limit, and that the limit has not been exceeded (eg. `42 MiB / 1 GiB`). The default quota rule has the subject `size:all`, so any write action should be allowed. #### Attempt to create a new repository. Expected result: Repository is created. Actual result: Error 413, You have exhausted your quota. #### Attempt to create a new file in the existing repository. Expected result: File is created. Actual result: Error 413, You have exhausted your quota. #### Create an issue on the test repository, and attempt to upload an image to the issue. Expected result: Image is uploaded. Actual Result: Quota exceeded. Displays error message: `JavaScript promise rejection: can't access property "submitted", oi[ji.uuid] is undefined. Open browser console to see more details.` ### Unlimited quota rules incorrectly allow all writes With quotas enabled, [Use the API](https://forgejo.org/docs/latest/admin/advanced/quota/#advanced-usage-via-api) to create a quota group containing a single rule with a subject of `size |
||
|
2457f5ff22 |
chore: branding import path (#7337)
- Massive replacement of changing `code.gitea.io/gitea` to `forgejo.org`. - Resolves forgejo/discussions#258 Reviewed-on: https://codeberg.org/forgejo/forgejo/pulls/7337 Reviewed-by: Earl Warren <earl-warren@noreply.codeberg.org> Reviewed-by: Michael Kriese <michael.kriese@gmx.de> Reviewed-by: Beowulf <beowulf@beocode.eu> Reviewed-by: Panagiotis "Ivory" Vasilopoulos <git@n0toose.net> Co-authored-by: Gusted <postmaster@gusted.xyz> Co-committed-by: Gusted <postmaster@gusted.xyz> |
||
|
e1fe3bbdc0
|
feat(quota): Humble beginnings of a quota engine
This is an implementation of a quota engine, and the API routes to manage its settings. This does *not* contain any enforcement code: this is just the bedrock, the engine itself. The goal of the engine is to be flexible and future proof: to be nimble enough to build on it further, without having to rewrite large parts of it. It might feel a little more complicated than necessary, because the goal was to be able to support scenarios only very few Forgejo instances need, scenarios the vast majority of mostly smaller instances simply do not care about. The goal is to support both big and small, and for that, we need a solid, flexible foundation. There are thee big parts to the engine: counting quota use, setting limits, and evaluating whether the usage is within the limits. Sounds simple on paper, less so in practice! Quota counting ============== Quota is counted based on repo ownership, whenever possible, because repo owners are in ultimate control over the resources they use: they can delete repos, attachments, everything, even if they don't *own* those themselves. They can clean up, and will always have the permission and access required to do so. Would we count quota based on the owning user, that could lead to situations where a user is unable to free up space, because they uploaded a big attachment to a repo that has been taken private since. It's both more fair, and much safer to count quota against repo owners. This means that if user A uploads an attachment to an issue opened against organization O, that will count towards the quota of organization O, rather than user A. One's quota usage stats can be queried using the `/user/quota` API endpoint. To figure out what's eating into it, the `/user/repos?order_by=size`, `/user/quota/attachments`, `/user/quota/artifacts`, and `/user/quota/packages` endpoints should be consulted. There's also `/user/quota/check?subject=<...>` to check whether the signed-in user is within a particular quota limit. Quotas are counted based on sizes stored in the database. Setting quota limits ==================== There are different "subjects" one can limit usage for. At this time, only size-based limits are implemented, which are: - `size:all`: As the name would imply, the total size of everything Forgejo tracks. - `size:repos:all`: The total size of all repositories (not including LFS). - `size:repos:public`: The total size of all public repositories (not including LFS). - `size:repos:private`: The total size of all private repositories (not including LFS). - `size |