Error log

Ask the user for the approximate time and the screen, and filter by them here. The URL column usually identifies the case faster than the message, because the same technical failure shows up with similar texts in different places.

The class name is abbreviated in the column; the full name is in the tooltip.

System error viewer — this is the role of the "Error log" screen within the platform.

A user reports "it gave an error when saving": (1) search the filter for a piece of the message they saw, or the screen's URL; (2) on the line found, hover over Class and Message — the context tip shows the full text; (3) quote the code from the first column in the ticket — it identifies the exact record without depending on date and time, and the user column confirms whether it was the same person.

The filter field searches by class, message or URL, and the Enter key triggers the search without needing the mouse. The Export menu in the footer generates Excel, CSV or PDF of the returned set — keep in mind that the query brings at most 1,000 records, so in long investigations filter first so the results fit within the limit, and only then export the result.

It is a hard ceiling, and the export exports those same 1,000. On an incident day, the log easily exceeds the limit and the rest simply does not appear — including the beginning of the problem, which is the part that matters.

So: filter before counting. A search by part of the message or the URL returns the right subset; looking at the loose list leads to the wrong conclusion about volume.

Access is restricted to the platform administrator, and in that context the screen shows the errors of all companies — that is why the company column matters as much as the message.

The user column may show a portal customer, not an internal user: a failure coming from the portal is always more urgent, because the one who saw the error screen was the customer.

The read/unread badge is only informational on this screen: there is no mark-as-read action here.

Each line is a captured failure with date, screen, user and the technical stack. It helps support understand what happened without depending on the user's account. A repeated error on the same screen is a sign of a defect, not of misuse — it is worth opening a ticket with the line number.

When you save a view with the Views button, it stores four things: the search text, the applied filters, which columns appear (and in what order) and which column the list is sorted by. Applying the view restores everything at once — including resetting the sort and the page you were on, so the result is exactly what the view describes. Views saved before this version remain valid: whatever they didn't store simply doesn't change when applied.

Nas fichas, sair de um campo já dispara a conferência do que dá para conferir na hora: campo obrigatório deixado em branco e e-mail mal formado. O aviso aparece embaixo do campo e desaparece quando você começa a corrigir. Campo numérico não precisa de aviso: ele simplesmente não aceita letra enquanto você digita. Isso é conforto, não a validação final: ao salvar, o sistema confere tudo de novo do lado do servidor.

The detail of each error starts with the chain of causes — one line per layer, from the outermost to the origin — and, just below, the point in our code where the problem appeared. That is where the answer lies most of the time. The rest is the full stack, useful for whoever is going to debug, and it may appear cut off at the end: the record has a maximum size, and we prefer to guarantee the cause over guaranteeing the footer. If an error appears many times in a row with the same cause, it is a single problem — not several.

This list is read-only: records cannot be edited or deleted here, because they are evidence of what happened. The top search looks in the text fields; the Filters button opens the side panel with the cuts (status, type, company…); the combination can be saved as a view and reopened with one click. In the ⋮ menu, Excel and PDF take the whole filtered set — not just the page on screen — and "export everything" asks for your password. The eye on each row opens the detail on the side.

The list no longer stops at the 1,000 most recent errors: it pages in the database, the footer number is the filter total and the export takes them all. To find an old error, search by the message, the full class or the stack trace.

Open the record and look at the Timeline on the right: it shows each change as "from one value to another", with the person and the date. When there are many changes, use the two filters at the top of the timeline — one by field, the other by person. The search runs in the database, so old changes show up just the same. You can also ask Tenkai: "who changed contract 482?".

This screen lists FAILURES: the system tried to do something it knows how to do and could not. When it refuses on purpose — deleting a customer that has a contract, settling an invoice that is already settled, approving without authority —, that is not a failure, it is the system working, and the explanation goes straight to whoever clicked. Mixing the two would make the error panel count correct decisions as problems and would hide the real failures among them.

Every profile that administers the account — in practical terms, whoever can change company settings, access or approval limits. It is read-only: nobody deletes or edits an error record here, and granting view of this screen grants nothing else on any other. If someone on your team needs to follow errors without administering the account, the way is to grant view of this screen to that person's profile, through the Access screen.