Glossary
Terms used across the code, the back office and these docs.
| Term | Meaning |
|---|---|
| Organization | A client of the instance, with its apps, tags, members, settings and plan. Its members only see its data. |
| Plan | What an organization may do: Free, Starter, Pro, Team or Business. Set by the OwnWeb admin for an organization billed directly, otherwise chosen by its admins and paid online when the host sells the plans. The OwnWeb admin sets the price and limits of each plan. |
| Subscription | The online payment of the plan of an organization, monthly or yearly, charged at each due date until it is cancelled. Offered by the host, not by the package. |
| Due date | The day a subscription is renewed and charged. A lower plan, a switch between monthly and yearly, or a cancellation applies on that day. |
| Seat | A member of an organization, counted against its plan, a pending invitation included. |
| Quota | How many visible reports a plan allows: since the start on Free, over the last 30 days on the others. |
| Daily report limit | How many reports an app with the key only or the public form method may receive per day, set by the OwnWeb admin. Beyond it, reports are refused until midnight: the SDK sends them again then, the public form tells the visitor to try again later. Unlike the quota, it refuses reports rather than hiding them. |
| Hidden report | A report beyond the quota, at intake or once a lower plan is forced. Kept, erased and purged like the others. Members see it as a locked row, with its app, topics, kind and date, never its content, and cannot act on it. Its reporter still replies through an email received before, such as its confirmation email. |
| Reception ceiling | How many reports an organization receives, five times its quota: since the start on Free, over the last 30 days on the others. Beyond it, a new report is refused and nothing is stored. Store reviews count but are never refused, and the apps always get 10 reports in over the same window. |
| Refused report | A report an organization did not receive because of its reception ceiling. Never stored: the reception log has no line for it, the refusal log one per attempt. |
| Reception log | One line per report an organization received, without personal data, kept without limit and replayed when the plan changes. |
| Billed directly | An organization OwnWeb bills itself, outside online payment. Its members see the plans without prices. Never an organization that pays its plan online. |
| Member | A back office user of an organization, triager or admin. An admin also changes the settings of the organization and of its apps, and creates apps within the app limit of its plan. |
| OwnWeb admin | A user of the OwnWeb admin panel, who creates organizations, apps and members, apps even beyond the plan. Never sees the content of a report. |
| App | A mobile app or a website of an organization, identified by its key, generated by the back office. The OwnWeb admin regenerates the key when it leaks: the old one is refused at once. |
| SDK | The library an app embeds to send reports to the back office: the Flutter plugin or the web module. |
| Report | What one user sends from the app, its website or its public form: a bug report or a suggestion, with its context and diagnostics. Also a store review, imported as a bug report. |
| Public form | The public web page of an app where anyone sends a report without the app or its website, under the colours and logo of its organization when its plan allows. Published with the public_form method, at the address of the app. |
| Kind | What a report or a topic is about: bug (a problem to fix) or feature (an improvement to build). A report has the kind its user chose, changed by a triager while it is in no topic. Grouped, it has the kinds of its topics: both, when it is in a bug and a feature. |
| Suggestion | A report of kind feature. |
| Topic | Reports of one app grouped by a triager because they are about the same thing: a bug or a feature. A report about several things belongs to several topics. |
| Bug | A topic of kind bug. |
| Feature | A topic of kind feature. |
| Status | Stage of a topic: unplanned, in design, in development, in testing, done. Only closing a topic sets it done. |
| Priority | How urgent a topic is: high, medium or low. Set by triagers, proposed by AI for a new topic. |
| AI triage | Mistral reading a visible report to propose its topics. On for every organization whose plan includes AI (Pro, Team, Business), once the instance has a Mistral key. |
| Grouping by AI | An option of the organization: proposals naming an existing topic are applied at once, marked "Grouped by AI". |
| AI proposal | One topic Mistral proposes for a report: kind, priority, title, excerpt, and an existing topic when one matches. A triager applies or dismisses it. |
| Planned for | The quarter or month a topic is planned for, for example "Q1 2027" or "March 2027". |
| Tag | A label on topics (Design, Accessibility...), shown on the roadmap. Each organization has its own. |
| Public topic | A topic shown on the roadmap, with a public title and description written for the users. |
| Roadmap | The public web page listing the public topics of one app. It shares its address with the public form. |
| Triager | A member who reads, groups and answers reports. |
| Alert | The message telling the members of an organization that reports arrived: an email to each member who keeps them, and a post to each integration the app enables. It lists the reports received since the previous one with their title, at most once per app every 5 minutes. |
| Task tracker | The tool where a triager pushes a reviewed topic as a task: ClickUp or Trello. Each app has at most one, chosen by an admin. Not an integration. |
| Integration | A Slack or Discord channel of an organization receiving the alerts through its webhook. An admin sets it, each app enables it or not. |
| Reporter | The user who sent a report. Only reporters who gave an email can be told. The author of a store review is told by a public reply. |
| Confirmation email | The email a reporter receives once their report is received. It names the app, the kind and the title of the report, never its description. At most 3 per email and app within an hour. |
| Store review | A Google Play or App Store review of 1 to 4 stars, imported every day as a report. It has the author's pseudonym, never an email. |
| Public reply | The answer a triager publishes under a store review when its topic closes, after checking it holds no health data. |
| Sentry issue | Sentry events of one error, grouped by Sentry. A report links to an issue through its Sentry event ids. |