Provide way to access all projects maintained by a user

Right now this information is not exposed anywhere.

For additional context, it is a table to table migration from D7 drupal.org to modern drupal.org https://git.drupalcode.org/project/drupalorg_migrate/-/blob/1.0.x/migrat...

We will need to decide on the format for this. It might be:
- A view with filters exposed via jsonapi for example.
- A custom endpoint exposed via drupalorg-api.

Note that this might be useful for project_browser as well.

I tried creating a view, which works, but jsonapi_views module does not expose it because the view is not based on an entity type. I used this module https://www.drupal.org/project/view_custom_table, but in this case, it’s jsonapi_views the one lacking what we need.

I’m going to try the custom drupalorg-api way.

MR needs review.

Endpoint is: /drupalorg-api/project-maintainers?nid=123&uid=456

The possible outcomes are:
- If nid and uid are passed: is_maintaner flag is returned
- If nid is passed: array with user ids and usernames returned
- If uid is passed: array with project ids and machine names returned
- If neither nid nor uid are passed: error
- If nid or uid are passed and are not valid ids: error

A "success" flag is always returned to determine if there is valid data or not.

It’s not deployed to any environment yet. I marked it as "need review" to validate the approach and review the code.

Usually @drumm helps with that, but feel free to look at the code and give feedback if needed.

Once it’s deployed, I will provide links to fully test it.

Let's depploy this, it'll help automate a lot of manual tasks

I don’t think we need this upfront, but we should make sure there’s enough surface area to add information about the types of maintainership (as in write to VCS / edit project / etc) without making breaking API changes or adding more parameters and extra complexity.

For example, “If nid is passed: array with user ids and usernames returned” might want another layer to the array to have space for the type of maintainership.

I think we can simplify a bit. Do we need:

• Logic for handling when both nid & uid are provided? That would save a bit of logic.
• Usernames when getting the list of maintainers? That would save loading users.
• Project names when getting the list of projects maintained? That would save loading nodes.

We do have an old API for this in D7: https://www.drupal.org/project/3060/maintainers.json / https://www.drupal.org/project/token/maintainers.json We don’t need to provide API compatibility here, although it couldn’t hurt. Drupal.org’s use case of providing the maintainers to sync to security.drupal.org is no longer relevant. I’m not sure how much community use it gets.

GitLab also already has an API for this: https://docs.gitlab.com/api/projects/#list-a-users-projects

I thought about providing more information about the level of maintainership, but wasn't sure about it, so I kept it as simple as possible for this implementation to precisely discuss these type of things.

> Do we need logic for handling when both nid & uid are provided?
That could be achieved by providing just one param and reading the result. I saw it as a quick 1/0 but yeah, it could actually lead to making more unnecessary calls. I'll remove the logic for "both" params.

> Do we need usernames when getting the list of maintainers?
Getting only user IDs might lead to additional calls to get the usernames. I thought that username is probably the one thing that most people will be interested in. eg: Project Browser might want this and will render links to the users. User ID and username should be enough to build things. I'll keep up unless you ask me to remove it after sharing this possible use case.

> Do we need project names when getting the list of projects maintained?
Same logic applies here. A list of project IDs might be insufficient and lead to extra calls. ID and project name gives enough information to at least render a list of links.

I wasn't aware of that old api! That's a good reference.

Action points:
- Remove logic for both nid and uid params together
- Expand output to include level of maintainership

Feedback addressed.

Case 1: /drupalorg-api/project-maintainers?nid=3060

{
    "maintainers": {
        "1": {
            "name": "Dries",
            "permissions": {
                "update_project": "1",
                "administer_maintainers": "1",
                "write_to_vcs": "40",
                "manage_releases": "1",
                "maintain_issues": "1"
            }
        },
        "3064": {
            "name": "drumm",
            "permissions": {
                "update_project": "0",
                "administer_maintainers": "0",
                "write_to_vcs": "0",
                "manage_releases": "0",
                "maintain_issues": "1"
            }
        },
        ...
    },
    "success": true
}

Case 2: /drupalorg-api/project-maintainers?uid=3064

{
    "projects": {
        "3060": {
            "name": "drupal",
            "permissions": {
                "update_project": "0",
                "administer_maintainers": "0",
                "write_to_vcs": "0",
                "manage_releases": "0",
                "maintain_issues": "1"
            }
        },
        "23508": {
            "name": "drupalorg_crosssite",
            "permissions": {
                "update_project": "1",
                "administer_maintainers": "1",
                "write_to_vcs": "40",
                "manage_releases": "1",
                "maintain_issues": "1"
            }
        },
        ...
    },
    "success": true
}

Case 3: Wrong params or IDs

{
    "error": "...the error message...",
    "success": false
}

podarok / andileco - does the current draft of the API responses fulfill your needs? How specifically are you planning to use the API?

Since API design is relatively permanent, now is our chance to get something that works long-term. We don’t need to rush to deploy something only to find something we want to change.

Project Browser might want this and will render links to the users. User ID and username should be enough to build things

Since those are made by pathauto, the user profile links are not exactly the username; spaces/punctuation/etc are altered.

Since those are made by pathauto, the user profile links are not exactly the username; spaces/punctuation/etc are altered.

Yup, my thinking would be that links would be https://www.drupal.org/user/UID and the text of the link would be the username. Username can change, UID won't.

Use cases @drumm

Given, I'm maintainer of multiple modules at drupal.org
I'm using dorgcli cli tool and JSON:API + custom REST drupal.org API to maintain modules with
- mass updating module's page description ( node body )
- mass changing permissions for users in maintainers ( add/remove user to/from 130+ projects )
- mass changing projects' taxonomy
- mass viewing all RTBC/needs work/critical issues ( at some point to be replaced by GitLab, I assume )
- mass path to MR conversion for issues with patches
- mass MR merge, tag ( these are on GitHub only, all good ) , release ( on drupal.org )

Rebased with latest changes. New MR, same code changes.

Per conversation in stand up with @drumm, this is RTBC and can be merged.

This is now deployed.

- Project maintainers: https://www.drupal.org/drupalorg-api/project-maintainers?nid=3060
- Project maintained by a user: https://www.drupal.org/drupalorg-api/project-maintainers?uid=2054544 (example from #6)