Publishing on DoliNews
From opening an account to the first published article.
Here, information is always dated: your announcement states the module's compatibility and maturity on the day you publish it. DoliNews does not claim to describe a module's current state, only what you have announced about it, and when. Your project sheet, by contrast, is permanent: it carries neither compatibility nor maturity.
Two things to know before you start. Writing requires a contributor account, meaning proof that you genuinely contributed to the ecosystem: reading and subscribing require none. And every announcement goes through review: an API token grants the right to submit, never the right to publish. Only its translations escape it, the text they translate having already been read.
1. Open your account
Registration is open and gives you a reader account. A verification email is sent immediately: the link it carries is single-use and activates the account.
Prefer the address you sign your commits with. If that address is already known to the author index, your account becomes a contributor account the moment you verify the email, and the next step does not concern you.
2. Prove your contribution
Qualification is distinct from authentication: the account exists first, the proof comes second. The service looks your commit author address up in an index harvested from git clones of the reference repositories - never through a forge API, so that verification survives the disappearance of any host.
Your address is never kept in clear text, neither in the index nor on the proof: only its peppered hash is stored.
Once the address is recognised, you still have to prove it is yours. Two levels:
- Simple: a one-time code is sent to the commit address, valid for one hour, five attempts.
- Strong: the service gives you a sentence to sign with the GPG key that signs your commits; you paste your public key and the signature.
Three cases where the simple route does not apply:
- Your commit address is an anonymised redirect, of the kind forges hand out: it receives no mail, so only the GPG signature or manual validation remain.
- Your address appears in no reference repository: ask the team for manual validation from that same page, explaining your situation. This is the route meant for editors without a public repository.
- That address is already bound to another account: one hash qualifies one account, and a proof revoked by moderation is never handed back by an automatism.
3. Declare your editor
The editor is the organisation or person who publishes; your project sheets and announcements belong to it. One never publishes under one's own name: without an editor, nothing can be submitted. The creation form is offered as soon as your contribution proof is accepted, and it stays available at the bottom of your articles page. An integration starting from scratch creates its editor through POST /editors instead. You own the editor you create, and you may attach other contributor accounts to it, who will then publish under the same name.
One owned editor per account: the publication credit and the queue ceiling are counted per editor. You join the others on their owner's invitation.
4. Create an API token
The token lets you publish from your integration chain, and the next step needs one. Name it after its use: the secret is shown once, at creation, and can be revoked at any time.
It goes in a header on every call. Start by checking that it answers:
TOKEN="12|..."
curl -H "Authorization: Bearer $TOKEN" -H "Accept: application/json" \
https://dolinews.com/api/v1/profileThe answer carries the two values every write depends on: is_contributor, and the list of your editors with their identifier. Note that identifier down, the following calls ask for it.
Rate: 120 reads and 10 writes per minute. A script depositing several images in a row has to account for the second limit.
5. Create your project sheet
The sheet describes the project permanently: name, summary, description, licence, typed links to the repository, the documentation, the shop or support. It carries no Dolibarr compatibility, and that is deliberate: a sheet stays in place for years, so any dated information it held would quietly turn false with nobody to fix it.
The sheet is created from your account, or through the API if you start from an integration pipeline. An article can do without a sheet - it is then an editor announcement - but a release deserves its own.
# Créer la fiche
curl -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
-d '{"editor_id":3,"name":"Mon module",
"summary":"Ce que fait le module, en une phrase.",
"license":"GPL-3.0-or-later"}' \
https://dolinews.com/api/v1/projects
# Ajouter un lien typé : dolistore, shop, demo, doc, repo, support, other
curl -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
-d '{"type":"repo","url":"https://example.org/mon-module","label":"Dépôt git"}' \
https://dolinews.com/api/v1/projects/mon-module/linksURL shorteners are refused, and a Dolistore listing already claimed by another editor raises a conflict for moderation to settle.
6. Submit your announcement
From the site, on your articles page, or through the API. The content is the same either way, and the summary is mandatory: it is what the reader skims in the feed, and its absence is what makes most release logs unreadable.
- The type separates a version release from an editor announcement; the nature of the publication - security, bugfix, feature, compatibility, end of life - only applies to a version.
- Maturity ranges from alpha to deprecated. Only stable versions show in the feed by default: the reader asks for the rest explicitly.
- Dolibarr compatibility is a range of major versions, declared either plainly or as genuinely tested. Do not declare as tested what you have not tried: the version filter depends on it.
- The body is Markdown. Outgoing links are all marked nofollow, and only images deposited on the service may illustrate an article.
An illustrated announcement is published in two steps: deposit the images, then create the article citing their addresses in the body and their identifiers in media_ids. Without those identifiers the images stay orphaned and are erased after twenty-four hours.
# 1. Déposer une capture. Elle est ré-encodée, ses métadonnées disparaissent.
curl -H "Authorization: Bearer $TOKEN" \
-F file=@capture.png -F editor_id=3 -F alt="Écran de configuration" \
https://dolinews.com/api/v1/media
# 2. Créer l'article et le soumettre dans le même appel
curl -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" \
-d '{"editor_id":3,"project_id":7,"type":"release",
"title":"Mon module 2.1","version":"2.1.0","locale":"fr_FR",
"focus":"bugfix_major","maturity":"stable","dolibarr_min":20,
"summary":"Ce que cette version change, en quelques lignes.",
"body":"## Corrections\n\n",
"media_ids":[42],"submit":true}' \
https://dolinews.com/api/v1/articlesA screenshot of a Dolibarr in service almost always contains real data - thirdparties, amounts, addresses. Clean it up before sending it.
The featured image is the one the feed, the sharing card and the feeds show for your announcement: designate it with featured_media_id among your editor's images, or with the image: line of the header when using the publishing tool. It is reviewed with the announcement, and changing it after publication goes through a revision. Without it, the first image of the body is shown; a translation shows the one of the original.
Two limits protect the queue: a publication pace per project, and a ceiling of announcements from the same editor under review at once. An announcement and its translations count as one.
7. Review, and what follows
Your article enters the queue and three moderators must accept it for it to appear. Exchanges happen in a private thread between you and the team: you answer there, you fix, you resubmit. Editing a pending article opens a new review round, because an accord bears on a precise text.
No delay is announced, and that is not an oversight: committing to the free time of volunteers would turn every delay into a breach. The review page shows the delay actually observed and the oldest wait. A security announcement goes first.
Once published, an article is never edited in place: you propose a revision, which goes back through the review, the article carries its correction mention and the original version stays readable. A translation is an article in its own right, tied to its original: the one you submit yourself appears without review, the one a translator you mandated submits goes through a reviewer; an untranslated announcement is never disadvantaged in distribution.