2 Commits
Author SHA1 Message Date
Lauri Ojansivu b7589737f5 File docs/Features the way the WeKan menus are.
A feature's guide now sits under the menu it is used from, read from the
templates rather than from where somebody once put it: Header-Bar,
All-Boards, Pages, Board-Header (search and every Board View), Board-Sidebar
(Board Settings, Filter, Members, Labels, Archive), Rules, Swimlanes, Lists,
Cards, Member-Settings, Admin-Panel and Login-Page. Topics used from several
menus (editor, history, theme, translations, email, troubleshooting) are in
General.

- Each area has a README mapping its menu entries to their guides and to the
  template or server module that implements them. Board-Header/README.md
  lists all 40 Board View entries with the template boardBody.jade renders;
  five views (Table, Calendar Mode, Time, Timeline, Map) have no guide of
  their own yet and say so.
- Board-View.md listed 25 views while BOARD_VIEWS has 40; it now lists all
  of them with their English labels.
- Pages keep their file names. Where a released changelog links an old path,
  a "# Moved" page stays there and points to the new one; test-menu.sh skips
  folders holding only those.
- Undo was filed under Login; it is General/Undo now.
- Every link in docs, code comments, scripts and tests follows the move;
  docsLinksResolve checks them all.

Tests that read a doc follow it to its new place. boardViewSettings now fails
when Board-View.md or Board-Header/README.md differs from BOARD_VIEWS, or
names a template boardBody.jade does not render.

Thanks to xet7 !
2026-10-16 23:45:35 +03:00
Lauri Ojansivu 6dc2651b48 Admin Panel / Problems / API: who called which endpoint, and how often.
Every other pane under Problems answers what went WRONG. This one answers what
is being DONE: `POST /api/boards` called 34 times by alice last month, 812 times
yesterday by nobody with an account. Without it the only record of REST API use
is whatever the reverse proxy happens to keep, and most instances keep none.

The table is username, endpoint, calls, the window they fall in, and the
addresses - sorted by calls, because a usage report's question is "what is used
most" where a problem report's is "what happened last".

THE NAME IS THE ROUTE PATTERN, NOT THE PATH. `/api/boards/:boardId/lists` is one
endpoint; `/api/boards/abc123/lists` and ten thousand of its siblings are that
one endpoint being used. Naming rows after paths would put a row per board in
the collection - the one-row-per-event cost this whole page exists to remove -
and a request that matched NO route is counted under a single "(no route)" name
rather than under the path it invented, because a 404 sweep is an attacker
walking a wordlist and a row per guess would let them fill the database.

ONE ROW PER ACCOUNT AND ENDPOINT, which makes the account part of a row's
identity - the one deliberate exception to the rule every other stream follows.
For those the question is "what is happening" and the caller would multiply the
rows; here "who called what" IS the report, and the cardinality is bounded by
real accounts times real endpoints. The account is stored by ID, so a rename
does not split its history in two.

NOTHING PER REQUEST. Ordinary API traffic is not rare the way a guard firing is
rare, so calls are counted in memory and folded on a timer - a thousand requests
become one write. A few seconds of counts are lost if the process stops between
flushes, which is acceptable here and nowhere else on this page: this report
decides nothing and nothing is protected by it. The tracked pairs are capped and
the rest counted, not dropped.

Counting hooks the middleware chain, not the routes, so a route cannot be added
without being counted - and it counts on the response's `finish` event, which is
where Express has filled req.route.path and authentication has run.

The pane is the SHARED event-stream report with a different column list, not a
second table page. The API stream is deliberately NOT in EVENT_STREAMS: it is
usage, not a problem, and an instance serving its API would otherwise report
thousands of new problems.

AND THE IPv4/IPv6 SPLIT IS FINISHED WHILE HERE. The summary rows have had ipv4
and ipv6 fields since the summaries were written, and not one of the four
loggers ever filled them - so the columns the design asked for could not have
worked. The fold splits the address now, once, for every stream, and the two
columns are one shared pair used by both reports rather than a copy each. They
fall back to classifying the stored `ip`, so rows written before today display
correctly instead of showing two empty columns for all of history.

Seven i18n keys in 239 language files, in en.i18n.json's order, English as the
placeholder where nothing is translated yet.

Thanks to xet7 !
2026-08-16 17:52:18 +03:00