Skip to content

Conversation

komarov
Copy link
Collaborator

@komarov komarov commented Sep 11, 2025

New models ContributorAgreement and SignedContributorAgreement are introduced.

A new Settings > Contributor Agreements page is introduced. The page allows a user to review the text of existing contributor agreements and to sign any of them.

A new /api/v1/users/{username}/contributor-agreements/{slug} endpoint allows to check if a user has signed a contributor agreement. This api endpoint can be used by a gitea action workflow, e.g. like this:
https://projects.blender.org/Oleg-Komarov/clacheck-runner/src/branch/main/example.workflow.yml

brechtvl and others added 21 commits August 28, 2025 09:26
Provider authored by Matti Ranta and Arnd Marijnissen.
Patch taken from issue number 17715, associating the LFS pointer when the
file is downloaded.
To avoid accidentally spamming hundreds of people.
Both are off by default. This is implemented fully on the frontend, so
all issues and their details are still always loaded.
Otherwise for some browsers, users have to login again for every session.
For Blender ID hook to do this.
Don't escalate any errors, only log them, to avoid breaking sign-in.
Spam reporting is available for trusted users (org members and admins) via a
button on a spammer's profile page;
a new section Site Administration > Identity & Access > Spam Reports;
a new "pending spam reports" indicator in the header for admins.
When viewing a file that the user can't edit because they can't write to
the branch, the new, upload, patch, edit and delete functionality is no
no longer disabled.

If no user fork of the repository exists, there is now a page to create one.
It will automatically create a fork with a single branch matching the one
being viewed, and a unique repository name will be automatically picked.

When a fork exists, but it's archived, a mirror or the user can't write
code to it, there will instead be a missing explaining the situation.

If the fork exists, a message will appear at the top of the edit page
explaining that the changes will be applied to a branch in the fork. The
base repository branch will be pushed to a new branch to the fork, and
then the edits will be applied on top.

The suggestion to fork happens when accessing /_edit/, so that for
example online documentation can have an "edit this page" link to
the base repository that does the right thing.
New models ContributorAgreement and SignedContributorAgreement are introduced.

A new Settings > Contributor Agreements page is introduced.
The page allows a user to review the text of existing contributor agreements
and to sign any of them.

A new /api/v1/users/{username}/contributor-agreements/{slug} endpoint allows to
check if a user has signed a contributor agreement.
This api endpoint can be used by a gitea action workflow, e.g. like this:

```
    name: contributor agreement check

    on:
      pull_request_target:
        types: [opened, ready_for_review, reopened, review_requested]

    env:
      CONTRIBUTOR_AGREEMENT: ...

    jobs:
      check_api:
        runs-on: ...
        steps:
          - run: echo "Checking $CONTRIBUTOR_AGREEMENT for ${{ gitea.event.pull_request.user.login }}"
          - run: result=$(curl --show-error --silent "$GITHUB_API_URL/users/${{ gitea.event.pull_request.user.login }}/contributor-agreements/$CONTRIBUTOR_AGREEMENT"); if [ "$result" == "OK" ]; then exit 0; else echo $result; exit 1; fi
```
@brechtvl
Copy link
Collaborator

Some screenshots of the UI would be nice for review.

@komarov
Copy link
Collaborator Author

komarov commented Sep 30, 2025

Here is a demonstration of the user-facing UI:

  • all existing ContributorAgreement objects are displayed as a list, using Slug as a title (to make an easy connection with the same slug used in the CI action setup)
  • if an agreement has been signed, the timestamp is shown, this action is now irreversible
  • if an agreement hasn't been signed, a form that allows to sign is displayed inline
Screenshot_20250930_102310 Screenshot_20250930_102424

I'm open to any arguments on why and how this should be extended, since I was mostly aiming at a fully functioning but minimalistic implementation to save time in the initial development phase.

@blender-it blender-it force-pushed the apply-patches-v1.24.3 branch from fd75124 to 745899b Compare October 7, 2025 13:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants