data/devices.json records, for each vendor, whether their hardware can do
OAuth 2.0 once Microsoft 365 stops accepting Basic authentication for SMTP AUTH
at the end of December 2026. It has 17 entries. Sharp is not one of them,
and Sharp MFPs and printers (BP, MX and AR series) are in a very large number of offices.
That gap is the whole task.
What to send
One entry, in the shape the file already uses:
{
"vendor": "Sharp",
"product": "MFPs and printers (BP, MX and AR series)",
"status": "check-advisory",
"models": ["the models the statement actually names"],
"evidence": "https://link-to-the-published-sharp-statement",
"notes": "What breaks, which flow is supported, and which models are not promised anything."
}status is one of: available, partial, check-advisory, unsupported,
none-planned.
The one rule that matters
Every entry must carry an evidence URL pointing at something Sharp
published. A support page, a firmware release note, a KB article, a PDF. Not a
forum post, not "my printer does this", not a guess.
If Sharp has published nothing, that is a real and useful answer — say so in
the issue and we will not invent an entry. A wrong row here sends an
administrator to buy hardware they did not need, or to skip a migration they
did need.
The two entries merged this week are worth copying as examples. The HP one is
the better model: it used partial and then named the LaserJet Pro models
that do not support OAuth, which is worth more to a reader than the list of
models that do.
Where it goes
Edit data/devices.json only. The table in docs/DEVICE-COMPATIBILITY.md and
the page under docs/devices/ are generated from it and checked in CI, so
the two cannot drift — do not edit them by hand, they will be overwritten.
Run this before opening the pull request:
python tools/build-device-table.py
Two things about how this repository treats you
Your first pull request will show its checks as pending until a maintainer
approves the workflow run. That is a GitHub default for first-time
contributors, not a judgement on your change, and there is now a job watching
that queue so it does not sit unnoticed.
If the checks come back red on something that looks unrelated to your change,
say so in the thread before you start debugging it. That happened to the last
contributor and the cause was our bug, not theirs.
Comment before you start so two people do not research the same vendor.
data/devices.jsonrecords, for each vendor, whether their hardware can doOAuth 2.0 once Microsoft 365 stops accepting Basic authentication for SMTP AUTH
at the end of December 2026. It has 17 entries. Sharp is not one of them,
and Sharp MFPs and printers (BP, MX and AR series) are in a very large number of offices.
That gap is the whole task.
What to send
One entry, in the shape the file already uses:
{ "vendor": "Sharp", "product": "MFPs and printers (BP, MX and AR series)", "status": "check-advisory", "models": ["the models the statement actually names"], "evidence": "https://link-to-the-published-sharp-statement", "notes": "What breaks, which flow is supported, and which models are not promised anything." }statusis one of:available,partial,check-advisory,unsupported,none-planned.The one rule that matters
Every entry must carry an
evidenceURL pointing at something Sharppublished. A support page, a firmware release note, a KB article, a PDF. Not a
forum post, not "my printer does this", not a guess.
If Sharp has published nothing, that is a real and useful answer — say so in
the issue and we will not invent an entry. A wrong row here sends an
administrator to buy hardware they did not need, or to skip a migration they
did need.
The two entries merged this week are worth copying as examples. The HP one is
the better model: it used
partialand then named the LaserJet Pro modelsthat do not support OAuth, which is worth more to a reader than the list of
models that do.
Where it goes
Edit
data/devices.jsononly. The table indocs/DEVICE-COMPATIBILITY.mdandthe page under
docs/devices/are generated from it and checked in CI, sothe two cannot drift — do not edit them by hand, they will be overwritten.
Run this before opening the pull request:
Two things about how this repository treats you
Your first pull request will show its checks as pending until a maintainer
approves the workflow run. That is a GitHub default for first-time
contributors, not a judgement on your change, and there is now a job watching
that queue so it does not sit unnoticed.
If the checks come back red on something that looks unrelated to your change,
say so in the thread before you start debugging it. That happened to the last
contributor and the cause was our bug, not theirs.
Comment before you start so two people do not research the same vendor.