Quickstart: make the first ADO repository visible

The shortest way from “the plugin is installed” to “a repository from Azure DevOps can be browsed in the wiki”. Three steps, about fifteen minutes. The long version, with every screen of the wizard and every special case, is in the tutorial.

Prerequisites

wkdoadogit, wkdocore, wkdostorage, wkdoado and wkcore are installed and enabled. Without wksourceview files do not open in the drawer.
The PHP extension curl is present.
A tested ADO connection exists — see Tutorial: connection. A connection fault diagnosed from here is diagnosed twice.
Administrator rights for the mount: a mount writes permissions for the whole site.

Back up conf/acl.auth.php before the first mount. The mount writes into a managed block of that file.

Step 1: understand the trade you are making

Azure DevOps is reached through one service account. Two things follow, and both apply immediately:

The wiki decides who sees what. Somebody with no Azure DevOps account can still browse a mounted repository if the wiki permits it.
Anything the service account can reach is reachable — by whoever the wiki permits.

So give the service account the narrowest Azure DevOps access that covers the repositories you intend to mount. Its reach is the ceiling; the wiki ACL is the gate.

Step 2: mount the repository

Admin → ADO-Git Repo Mounts, directly /doku.php?do=admin&page=wkdoadogit_mounts. Expand Register mount; the wizard walks four screens:

Connection — the connection from the prerequisites, listed as project / key.
ADO project — the project in Azure DevOps.
Repositories — tick one or more repositories, choose the visibility tier, then Preview.
Preview — what the tier grants, which namespace results, and every permission line that will be written. Then Register.

Four tiers are available:

Tier	Who may read
`private`	Nobody but the operations group.
`team`	The role groups of this project only — readers, contributors, maintainers.
`readonly`	Every signed-in account.
`public`	Everyone, signed in or not.

Until this mount exists, the repository is invisible in the wiki. The service account being able to see it is not enough — exposure is an explicit act.

Step 3: put the browser on a page

The mount and the markup are two separate acts. The mount only writes permissions and creates no page. The repository becomes visible only through the markup on a page. This is the commonest reason for the impression that a mount does not work.

Edit the project's repos page — en:projects:acme:repos — and put in:

{{wk:adogit>connection:ADO-project:repository region=toc}}

On this installation de:projects:dwplugins:repos carries, for example, {{wk:adogit>wvds:DokuWiki-Plugins:wkdoadogit region=toc}}.

Check the result

You see refs, a file tree and files. Every one of those requests passes the same gate, evaluated per request and never cached. That is why revoking access takes effect on the next request rather than at some later expiry.
Counter-check with a second account — the two minutes are worth spending once per installation: an account without read permission on the mount namespace sees nothing. Not a partial listing, and not an error naming the repository. Then grant read and confirm it can browse.
Read and write are two levels on the same namespace: read permission means browsing, edit permission means committing and creating refs. Nothing else has to be configured for that.

Next step

Tutorial: show an ADO repository in the wiki for the first time — the complete version, with every field and pitfall.
How to: show repository files on a wiki page
How to: clone a mounted repository — access from outside, with a personal access token under ?do=wkdoadogit_tokens.
Troubleshooting