Session: 6c3c005c-c23f-420f-8630-d91740fb23d1
Coverage
7
Selected
7
Completed
0
Reused
0
Failed
0
Waived
Token Usage
4.55M
Prompt Tokens
87.41K
Completion Tokens
4.63M
Total Tokens
75
LLM Requests
4.38M
Cache Read
0
Cache Write
File breakdown 2 files
| File | Prompt | Completion | Cache Read | Cache Write | Total |
|---|---|---|---|---|---|
| src/Controller/SsmaController.php,src/Service/Ssma/SsmaOccur… | 4.55M | 86.24K | 4.38M | 0 | 4.63M |
| File Grouping | 418 | 1.17K | 0 | 0 | 1.59K |
Files Reviewed 7 files
- templates/ssma/occurrence/index.html.twig
- src/Service/Ssma/SsmaOccurrenceTypeConfigService.php
- templates/ssma/occurrence/occurrence_view.html.twig
- templates/ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig
- templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig
- src/Controller/SsmaController.php
- templates/ssma/occurrence/partials/_modal_event.html.twig
Session Tasks 1 tasks
File Grouping 1 requests
grouping_task
Request #1
deepseek-v4-flash
P:418 C:1.17K
9135ms
Reasoning
We need to group changed files into semantically related clusters. Files are from an SSMA module, likely Symfony app. Changes touch controller, service, templates, and partials about "occurrence". Need to infer theme.
Files:
1. src/Controller/SsmaController.php - controller modified.
2. src/Service/Ssma/SsmaOccurrenceTypeConfigService.php - service modified, probably config logic.
3. templates/ssma/occurrence/index.html.twig - occurrence list page.
4. templates/ssma/occurrence/occurrence_view.html.twig - occurrence detail page.
5. templates/ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig - new partial related to "descaracter suspect" perhaps.
6. templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig - modified injured person box.
7. templates/ssma/occurrence/partials/_modal_event.html.twig - modal event.
We need to decide whether all these are one group or split. Likely they are all part of one feature: "Ssma occurrence type config" or "event description modifications". Let's inspect paths.
Controller generic changed. Service specifically "SsmaOccurrenceTypeConfigService" - occurrence type config. Templates under occurrence. New partial "_ev_descaracter_suspect_block" (descaracter suspect? maybe "descaracter" means "decharacterized" or "removal from suspicion"? Actually "descaracter" maybe "descaracterization" of event? Need infer from naming. "_ev_" prefix likely "event" template partial. "_ev_injured_person_box" relates to injured persons. "_modal_event" modal for event.
Controller likely handles routes for occurrence and passes data. Service provides config for occurrence types. Templates render occurrence list/detail and partials.
All files seem to be in same module/feature. Group them all? But maybe we should separate based on concerns. However instructions: Files in same group if same module/feature. All are within SSMA Occurrence feature, likely one commit. Need maximum 10 files, so 7 files fit.
Need output JSON array with one group or maybe more if obvious distinct purposes. Let's think: Since service and controller and templates all likely collaborate to display occurrence types? For example, the service might add new occurrence type config, controller passes it, templates use partials to render. The partials added/modified likely for different event types but all for occurrence view. It might be a single feature "add suspect block to occurrence view based on occurrence type config". The new partial "_ev_descaracter_suspect_block" suggests a specific event type "descaracter suspect" (maybe a block showing "suspicious person without character"?). The partial is included maybe in modal event.
Could split into:
- Backend logic: Controller + Service.
- Templates: index, occurrence_view, partials.
But requirement: Files in same group typically share same directory and work together on single concern. Since service/controller relate to templates, producer/consumer. We should group together if part of same feature. The label should be short theme description. Could be "SSMA occurrence type configuration and event blocks" or "SSMA occurrence display enhancements".
Need decide exactly. Is there any evidence that files are independent? The controller modified +8/-2 likely routes or rendering. Service modified +40/-0 adds methods. Templates modifications small except partials. It sounds like a feature to add a new "suspected decharacterized" block to occurrence page, wired through controller/service/config and templates.
Thus one group with all files is reasonable. But maybe grouping all files under "Ssma occurrence" is too broad but acceptable. Need output only JSON array.
Let's output:
[
{
"label": "SSMA occurrence type configuration and display",
"files": [
"src/Controller/SsmaController.php",
"src/Service/Ssma/SsmaOccurrenceTypeConfigService.php",
"templates/ssma/occurrence/index.html.twig",
"templates/ssma/occurrence/occurrence_view.html.twig",
"templates/ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig",
"templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig",
"templates/ssma/occurrence/partials/_modal_event.html.twig"
]
}
]
Check if any file might belong to another cluster? For example index.html.twig maybe unrelated to occurrence view? But still occurrence list. Could be adjusted due to same changes. We'll include.
Need ensure no extra text.
[
{
"label": "SSMA occurrence type configuration and display",
"files": [
"src/Controller/SsmaController.php",
"src/Service/Ssma/SsmaOccurrenceTypeConfigService.php",
"templates/ssma/occurrence/index.html.twig",
"templates/ssma/occurrence/occurrence_view.html.twig",
"templates/ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig",
"templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig",
"templates/ssma/occurrence/partials/_modal_event.html.twig"
]
}
]
Conversations 1 files
src/Controller/SsmaController.php,src/Service/Ssma/SsmaOccurrenceTypeConfigService.php,templates/ssma/occurrence/index.html.twig,templates/ssma/occurrence/occurrence_view.html.twig,templates/ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig,templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig,templates/ssma/occurrence/partials/_modal_event.html.twig 74 requests
plan_task
Request #1
deepseek-v4-flash
P:14.82K C:15.72K
124271ms
Reasoning
The user wants me to analyze code changes and produce a structured review plan. Let me carefully review the changes.
Let me understand what the changes do:
1. **src/Controller/SsmaController.php**: Previously, `$ssmaCanDescharacterizeAccident` was computed by `ssmaMemberCanDescharacterizeAccident($company, $currentMemberForExport)`. Now it computes `$ssmaCanDescharacterizeByType` from a new service method `getDescharacterizeFlagsByType`, and `ssmaCanDescharacterizeAccident` is derived from `$ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false`.
2. **src/Service/Ssma/SsmaOccurrenceTypeConfigService.php**: Adds two new methods:
- `memberCanDescharacterizeForType(Company $company, int $memberId, string $typeKey): bool`
- `getDescharacterizeFlagsByType(Company $company, int $memberId): array`
It uses `SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS` for the type keys and queries `SsmaPermissionTag` by company and occurrenceTypeKey, then calls `getAprofundamentoDescaracterMemberIds($company, 'tag', $tagId)`.
3. **templates/ssma/occurrence/index.html.twig** and **occurrence_view.html.twig**: passes `ssmaCanDescharacterizeByType` into Twig components.
4. **templates/ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig**: New partial that renders suspect block if flag is enabled.
5. **templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig**: Renders descaracter block only if `ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']` is true.
6. **templates/ssma/occurrence/partials/_modal_event.html.twig**: Includes the partial with various type keys, adds JS functions `evGetTypeDescaracterRoot`, `evApplyTypeDescaracterPayload`, event listeners, populates state from data.
Now, key observations for issues:
### Behavior change analysis
The old code: `$ssmaCanDescharacterizeAccident = $company instanceof Company && $this->ssmaMemberCanDescharacterizeAccident($company, $currentMemberForExport);`
The new code:
```php
$ssmaCanDescharacterizeByType = ($company instanceof Company && $currentMemberForExport)
? $this->ssmaOccurrenceTypeConfig->getDescharacterizeFlagsByType(
$company,
(int) $currentMemberForExport->getId()
)
: [];
$ssmaCanDescharacterizeAccident = (bool) ($ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false);
```
Wait — previously, when `$currentMemberForExport` was null, the old code would call `ssmaMemberCanDescharacterizeAccident($company, $currentMemberForExport)` with null (need to check whether that method could accept null). Now the behavior is: if `$company instanceof Company && $currentMemberForExport` — what if `$currentMemberForExport` is an object but the `id` is something? Actually `getCurrentCompanyMember` returns a member (probably object) or null. The cast `(int) $currentMemberForExport->getId()` — if member exists but Id is null... hmm, `$currentMemberForExport?->getId() ?? ''` for export suggests getId could be numeric. Cast is fine.
Key semantic change: The old flag was broader: `ssmaMemberCanDescharacterizeAccident` checks if the member appears in any group with permission to descaracterize (probably by member's user id or member id across tags). The new implementation restricts ACIDENTE_PESSOAL flag by querying tags with `occurrenceTypeKey = 'ACIDENTE_PESSOAL'`. If the configuration data doesn't have a tag configured with the type key `ACIDENTE_PESSOAL` or there are tags of different type keys, the behavior changes. This is the intended business change though (descaracterization per type).
Potential regression: If old behavior used groups associated to member — `getAprofundamentoDescaracterMemberIds($company, 'tag', $tagId)`. Need to understand the semantics of this method: for a "tag" group of a specific tag Id, return member ids. So the new method queries `SsmaPermissionTag` where company = company and occurrenceTypeKey = typeKey. Then for each tag, checks if member is in the descaracter member ids of that tag.
Issue candidate: A race where a company's tags might not have the `occurrenceTypeKey` field set for all (legacy tags). If the field can be null/'' in the database, then `findBy(['company' => $company, 'occurrenceTypeKey' => $typeKey])` would not match those legacy tags, so members who previously could descaracterize accidents (per old logic, which may be based on any permission group/member relation not occurrence-type-specific) would now lose permission silently. That is a potential regression regarding authorization. But we need to check how `ssmaMemberCanDescharacterizeAccident` worked before and semantics of `SsmaPermissionTag::occurrenceTypeKey` vs `FIXED_TECHNICAL_OCCURRENCE_KEYS`.
Also, this is a hot path issue: `getDescharacterizeFlagsByType` loops over `FIXED_TECHNICAL_OCCURRENCE_KEYS` (how many? maybe 4-5), and for each key it queries tags per type (findBy), then calls `getAprofundamentoDescaracterMemberIds` per tag. N+1 queries. This is called in the controller on every occurrences page load. If `getAprofundamentoDescaracterMemberIds` executes DB queries, this is several extra queries per page. Old code called one method once. New code could add many queries. But is this page load frequent/heavy? It's a listing page of occurrences. Could be a performance concern: per page load, a handful of extra queries — medium severity maybe, but need to verify the count. Actually this depends on existing implementation details, need `code_search` to find `getAprofundamentoDescaracterMemberIds`, `ssmaMemberCanDescharacterizeAccident`, `FIXED_TECHNICAL_OCCURRENCE_KEYS`.
Also missing parameter `$typeKey` semantics — the template uses keys:
- 'ROS'
- 'QUASE_ACIDENTE'
- 'ACIDENTE_MATERIAL'
- 'ACIDENTE_AMBIENTAL'
- 'ACIDENTE_PESSOAL'
So `FIXED_TECHNICAL_OCCURRENCE_KEYS` should contain all these keys. If the constant uses different representation (e.g., lower-case or snake, or different naming, or EventTypeEnum values like 'RISK_OF_SOMETHING'), the keys in Twig wouldn't map. Need to verify constant values with code_search.
Another thing: in `SsmaOccurrenceTypeConfigService`, the new `memberCanDescharacterizeForType` uses `SsmaPermissionTag` (entity) repository via `$this->em->getRepository(...)`. But there's already `SsmaPermissionTagRepository` imported and used for `FIXED_TECHNICAL_OCCURRENCE_KEYS`. Inconsistent use but not a bug.
Now consider the `ACIDENTE_PESSOAL` semantics: the old `ssmaMemberCanDescharacterizeAccident` - it was presumably matching by member's user? The old method signature is `memberCanDescharacterizeAccident(Company $company, int $memberId): bool` — that's an existing method in this service. Wait, let me look at diff again:
```php
/** True se o membro aparece em qualquer grupo com permissão de descaracterizar. */
public function memberCanDescharacterizeAccident(Company $company, int $memberId): bool
{
```
So there is an existing method `memberCanDescharacterizeAccident(Company $company, int $memberId)`. But the controller called `$this->ssmaMemberCanDescharacterizeAccident($company, $currentMemberForExport)` — the controller's own private method maybe? Actually `$this->ssmaMemberCanDescharacterizeAccident` is a controller method (probably a private helper). Hmm, actually diff only shows controller change; the old controller code called `$this->ssmaMemberCanDescharacterizeAccident($company, $currentMemberForExport)` where `$currentMemberForExport` might be null-checked in the method. The new code uses `$this->ssmaOccurrenceTypeConfig->getDescharacterizeFlagsByType(...)`.
So the service method `memberCanDescharacterizeAccident` at the bottom (visible in the diff context) appears to be existing. Interesting that new method (`memberCanDescharacterizeForType`, `getDescharacterizeFlagsByType`) is added above it. And old controller helper `ssmaMemberCanDescharacterizeAccident` probably calls the service existing method? We don't see it. We should verify.
Potential issue — Authorization semantic regression: Previously `ssmaCanDescharacterizeAccident` was permission to descaracterize accidents granted by any tag that has the descaracterize permission (maybe type independent: an "ACIDENTE_PESSOAL" tag or generic tag?). The new logic requires tags filtered by `occurrenceTypeKey === 'ACIDENTE_PESSOAL'`. This is intentional bugfix/feature (per-type granularity) per PR title. But we need to check whether data can have tags without occurrenceTypeKey set (null). If a company has a permission tag with the "descaracterizar" flag but no `occurrenceTypeKey` (e.g., legacy records or global tags not tied to a type), those users silently lose the ability. Also the `ev_injured_person_box.html.twig` now hides the whole suspect UI when ACIDENTE_PESSOAL flag false. Is that a potential regression where previously can-descaracterize accident flag came from `ssmaMemberCanDescharacterizeAccident` which is different? The suspected persons who lost flag now won't even see suspect checkboxes => behavior change is intended per new feature (descaracterization column per tag). But if no ACIDENTE_PESSOAL type tag exists for the company (data not migrated), every specialist loses the ability and this would be a regression.
Let me note that migration may be needed: `SSMA_PERMISSION_TAG.occurrence_type_key` might be nullable — need to verify entity. Also new tags might rely on config that does not exist. That is a risk candidate to check with code_search/file_read.
Twig issues:
In `_ev_descaracter_suspect_block.html.twig`, `_type_key = type_key|default('')`, and access `ssmaCanDescharacterizeByType[_type_key]`. If `ssmaCanDescharacterizeByType` isn't passed or is default `{}`, Twig: accessing `some_array['key']` on non-existent? Actually in template `ssmaCanDescharacterizeByType|default({})` used in include. Twig's default filter applies only if the variable is undefined; if variable defined as `[]` (since index/occurrence_view passes `ssmaCanDescharacterizeByType|default({})` with `{}` but what if it actually is empty array passed from controller?) All good.
But note in `_ev_injured_person_box.html.twig`, this partial is included from `_modal_event.html.twig` with:
```
person_id: '',
person_name: '',
attendance_date: '',
breve_relato: '',
ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
```
But is `_ev_injured_person_box.html.twig` included elsewhere (e.g., the actual event modal from another template or a create new occurrence modal in index)? If it's included from other places that do not pass `ssmaCanDescharacterizeByType`, then `ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']|default(false)` would fail? In Twig, if `ssmaCanDescharacterizeByType` is undefined and you access `['ACIDENTE_PESSOAL']`, you get a runtime error unless you use a null-coalescing approach. Let's think:
```
{% if ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']|default(false) %}
```
The `default` filter applies to the result of the array access expression. But if `ssmaCanDescharacterizeByType` is undefined, Twig raises "Variable 'ssmaCanDescharacterizeByType' does not exist." in some versions? Actually `foo.bar|default('x')` when foo undefined — Twig will throw if `foo` is undefined because it must evaluate `foo.bar` to apply something... Actually in Twig, `default` is special: the compiler for the default filter wraps in a check on the value: it checks if the value is defined or empty. For `foo.bar|default(fallback)`, twig's default filter: if foo.bar is undefined or empty, return fallback. If foo is undefined, accessing foo.bar might raise... but actually Twig handles attribute on undefined? Let me recall: Twig's `default` filter compiles to `(($__internal_... = ...) ?? ...)`. For `foo.bar`, the compiled code is `(isset($context['foo']) ? ... )`? Hmm.
In Twig, `{{ foo.bar|default('x') }}` where foo is undefined — I believe returns 'x' without error because the default filter (when applied with `is defined` testing?) Twig's `default` filter is implemented as a filter that, in compiled code, uses the `twig_test_empty` check. When foo is undefined, accessing foo.bar typically throws a runtime error "Variable 'foo' does not exist." BUT with default filter: the filter's behavior when the value is undefined... The compiled code for `foo.bar|default('x')` is roughly:
```
(($context['foo'] ?? null) && ...) ? ...
```
Actually I need to recall precisely. Twig documentation: "The default filter returns the passed default value if the value is undefined or empty." And example `{{ my_var|default('my_var is not defined') }}`. For attribute access on undefined arrays, `{{ foo.bar|default('...') }}` — I believe the default filter also handles the case where the item is not defined. In Twig compiled code for a filter with the `default` filter name specifically, there's optimization — the filter gets the value which will generate a null-safe access? Hmm. Let's recall from actual Twig behavior: `{{ foo.bar|default('fallback') }}` when `foo` is not defined at all... I think Twig throws "Variable 'foo' does not exist" — no wait, using Twig 2/3, attribute access on undefined variable where attribute access is the left operand of default... The `default` filter is special because templates often write `{{ foo.bar|default('...') }}` and it works when `foo.bar` doesn't exist — e.g., `{{ user.name|default('Anonymous') }}` works even when user is undefined? Actually I think this is precisely why default is useful; Twig handles undefined anywhere in the chain: `{{ a.b.c|default('d') }}` when `a.b` doesn't exist returns 'd' — yes, I believe the default filter's implementation catches undefined values along chain? Hmm.
I recall in Twig: `{{ foo.bar|default('bar') }}` — foo undefined -> renders 'bar'. Yes, this is common pattern and safe. And `{{ foo['bar']|default('x') }}` also safe. Fine.
But there's an important subtlety in `_ev_injured_person_box.html.twig`: the partial gets included in `_modal_event.html.twig` with explicit variable passing. But partial might also be included from other pages, e.g. the create occurrence general/technical steps in `index.html.twig`? Since the PR adds to the partial a condition on `ssmaCanDescharacterizeByType`, and older include sites don't pass that var, we'd need to verify that partial access is safe for undefined variable (as above it is under default) — but the index might render a create form too. If undefined, the if would be false and the UI hidden; for a specialist who has permission that's a functional problem. But at the controller, `ssmaCanDescharacterizeByType` is now always passed in both views' data arrays? Actually index.html.twig's template data likely receives many variables passed explicitly; they add `ssmaCanDescharacterizeByType` into a JS config at line ~125. But the Twig partial's include used in `_modal_event.html.twig` — `_modal_event.html.twig` is used by both occurrences index page? During "create" flow, the modal in the page loads `ssma_config`-like JS. Hmm, the code at `index.html.twig` in the diff adds to a `SsmaOccurrenceContext`-like script config `ssmaCanDescharacterizeByType`. Similarly in occurrence_view. These are used by JS to set a global variable; and `_modal_event.html.twig` uses its own Twig var.
But look closer at `evApplyTypeDescaracterPayload`:
```js
function evApplyTypeDescaracterPayload(payload, type) {
var root = evGetTypeDescaracterRoot(type);
if (!root) return;
var chk = root.querySelector('.ev-type-descaracter-suspect');
payload.descaracter_suspect = chk && chk.checked ? 1 : 0;
var descVal = String((document.getElementById('ev_descaracterizado') || {}).value || '');
if (descVal === '0' || descVal === '1') payload.descaracterizado = descVal;
var comm = root.querySelector('.ev-type-descaracter-comment');
var commVal = comm ? String(comm.value || '').trim() : '';
if (commVal) payload.descaracter_comment = commVal;
}
```
Bugs possible:
1. The function sets `payload.descaracter_suspect = 0` even when no check selected → probably fine. But when include renders only if permission; if no root, return. Good.
2. The com `ev_descaracterizado` hidden field is global/shared across types, so when the payload for the current type is built, the value from another type's Sim/Não button could leak. If both ROS and QUASE_ACIDENTE have roots and the user selects yes for ROS, then later edits QUASE_ACIDENTE... The global `ev_descaracterizado` value would be shared. In render, all roots probably present in same modal/offcanvas. The same single indicator doesn't distinguish by type; that could leak data between types but maybe this is acceptable since per occurrence, descaracterization likely is singular.
Also `evIsDescaracterSuspectChecked` now returns true if any type check is true, else whether the global suspect checkbox is checked. But the ordering: it returns early if global `ev_descaracter_suspect` exists & checked; the type-specific root check is a fallback. Might be fine.
But major JS conflict: For ACIDENTE_PESSOAL, descaracterization is in the injured person box, uses `.ev-inj-suspect-chk`, `.ev-inj-descaracter`. On the other hand the payload function for ACIDENTE_PESSOAL doesn't call `evApplyTypeDescaracterPayload(payload, 'ACIDENTE_PESSOAL')`. Hmm, ACIDENTE_PESSOAL uses a different block (the `_ev_injured_person_box.html.twig`) which is included with flag for the "ACIDENTE_PESSOAL". Wait but payload for ACIDENTE_PESSOAL... In the diff, evApplyTypeDescaracterPayload is only invoked for ROS, QUASE_ACIDENTE, ACIDENTE_MATERIAL, ACIDENTE_AMBIENTAL (from the added lines). ACIDENTE_PESSOAL (the personal accident) branch does other handling - probably using existing `ev_descaracter_suspect` / `ev_descaracterizado` fields. In the `_ev_injured_person_box.html.twig`, the code inside (the whole descaracter block) is now wrapped in `{% if ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']|default(false) %}`. That block may rely on `ssmaCanDescharacterizeAccident`? Previously it was shown when `ssmaCanDescharacterizeAccident` true... hmm, wait previously: The block was rendered when? In the old code comment: "Descaracterização — só no aprofundamento. Suspeita editável por qualquer especialista AP; Sim/Não só quem tem permissão Descaracterizar." — with the outer div class `d-none`. Visibility was controlled by JS. Now the entire section is only output if `ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']` true. So for users with permission based on old logic which maybe was broader, could be regression (intended by new per-type model).
Important: also in the Controller line 12531 area, previously `$ssmaCanDescharacterizeAccident` was a single bool possibly used also elsewhere in this same Twig view or application for the event modal. Now they still pass it into the same places; derived from ACIDENTE_PESSOAL key. Ok.
Potential issue to verify: `ssmaMemberCanDescharacterizeAccident` in controller old code... `getCurrentCompanyMember` might return an object whose `getId()` returns int. Cast int fine. Wait, there is condition: `$company instanceof Company && $currentMemberForExport` — if `$currentMemberForExport` object `false`? Then getDescharacterizeFlags empty -> false. Old code: if `$currentMemberForExport` null but company present, called `ssmaMemberCanDescharacterizeAccident($company, $currentMemberForExport)` — a controller helper that probably handles null or casts. If a user has no company member record, previously maybe `$ssmaCanDescharacterizeAccident`=false anyway. Fine.
Also: `$currentMemberForExport?->getId() ?? ''` and then cast int in new code — if `getId()` returns non-int numeric string "000"? equals fine.
Now potential bugs with `getDescharacterizeFlagsByType`: `SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS`. Need to check that constant exists, is public, and has exactly keys with names as in Twig (e.g. `'ACIDENTE_PESSOAL'`, `'ROS'`...). If one type has different representation (the map may group event types vs occurrence type). Also maybe `FIXED_TECHNICAL_OCCURRENCE_KEYS` includes only technical keys as opposed to ROS/QUASE_ACIDENTE (which are "aprofundamento" types?). From `memberCanDescharacterizeForType` docblock: "ex.: tag 23 = QUASE_ACIDENTE." For the type key, the entity SsmaPermissionTag has property `occurrenceTypeKey`. Need to verify existence of the property and its values by searching the repository constants and entity.
Big thing: Business-rule/authorization isolation per company: Using `findBy` with company = company is good. But wait: if a company member id happens to be present in tags of other types? Each check in `memberCanDescharacterizeForType` for the typeKey returns member ids for tags of that type in... Actually `getAprofundamentoDescaracterMemberIds($company, 'tag', $tagId)` restricts by company and source? Need to inspect. Probably fine.
The semantic subtlety: The old `memberCanDescharacterizeAccident` existed in service as an existing method but not used in the new controller. It checks "member appears in any group with permission to descaracterize" — but not necessarily filtered by type key; now more specific. There might be a leftover dead code or mismatch: existing method vs new specific per type might duplicate logic or produce inconsistent outcomes, violating "única fonte de verdade" rule — same domain rule recalculated with different criteria in two service methods (e.g. `memberCanDescharacterizeAccident` vs `memberCanDescharacterizeForType(..., 'ACIDENTE_PESSOAL')`) — the old method should now delegate to new one or new controller helper `ssmaMemberCanDescharacterizeAccident` should be updated/removed. Since the old controller called custom helper, not service method. Wait bottom lines of diff show service existing method `memberCanDescharacterizeAccident`. That method remains, not removed: older path? Could be used for another page (e.g., where events are of old type?). This duplication is worth flagging as maintainability but must verify.
Now let's think about the biggest functional risk:
**Regression: `ssmaCanDescharacterizeAccident` might become false for users when tags don't have the `occurrenceTypeKey` set**: In `SsmaPermissionTag` values the column might have been introduced recently and old data could be NULL. `findBy(['occurrenceTypeKey' => 'ACIDENTE_PESSOAL'])` would miss such tags. Need to verify SsmaPermissionTag entity's occurrenceTypeKey defaults and old config data.
**N+1 / Performance**: `getDescharacterizeFlagsByType` loops over the constant keys (maybe up to 5), each iteration calls `memberCanDescharacterizeForType`: 1 query to find tags by company+typeKey plus per each tag one additional call to `getAprofundamentoDescaracterMemberIds` that likely queries DB/Groups etc. That may result in 5 + many queries per page load. Page being occurrences index listing, paginated 50. If this code runs each time for each page + maybe it also runs in the other View (occurrence_view). Not a big scale but noticeable slow route.
Also, `getAprofundamentoDescaracterMemberIds($company, 'tag', $tagId)` — second parameter is group source "tag" — meaning returns member ids of a group formed by that tag, maybe computed via `SsmaPermissionGroup` members or member tags? That might fetch and load large collections.
I should search: `getAprofundamentoDescaracterMemberIds` and `FIXED_TECHNICAL_OCCURRENCE_KEYS`, `occurrenceTypeKey`, via the review plan's tool suggestions.
And old controller helper `ssmaMemberCanDescharacterizeAccident` — where defined and what it did, to compare semantics (mismatch old vs. new behavior when a member has a "descaracterization" permission tag whose occurrenceTypeKey doesn't match; or where permission came from group-based sources other than tag, e.g., by role - like gestor direto desconsider?). The user-specific rules in Controller file emphasize careful analysis of authorization regression and not relying only on Twig hiding. But here the server flag is computed server-side; UI is updated accordingly. It's also passed down as JS config.
Another possible issue with new PHP code: the guard `if ($memberId <= 0 || $typeKey === '')`. In controller they call with `(int) $currentMemberForExport->getId()` guaranteed > 0 when object. fine.
But there's a case in the controller: `$currentMemberForExport` is an object, but old code used the controller helper which may consider more about "user member" association. Also `('company' => $company)` with company is okay.
Now Template details:
In `_modal_event.html.twig` new include with type_key 'ROS', etc. But partial checks `ssmaCanDescharacterizeByType[_type_key]`; the partial default if `ssmaCanDescharacterizeByType` is not passed: Not an issue since included with passing variable.
However, `_modal_event.html.twig` could be included from multiple top-level template contexts (event modal maybe from occurrence index) — variable exists (use default). But the value is coming from Twig vars of the view; index.html.twig adds to a JS config only, not necessarily passing a twig variable `ssmaCanDescharacterizeByType` to modal when included. Wait — The diff to `_modal_event.html.twig` uses `ssmaCanDescharacterizeByType|default({})`. If in index page context the variable `ssmaCanDescharacterizeByType` was not defined at all, include from `_modal_event` uses default {}; every suspect block hidden. Then JS config `ssmaCanDescharacterizeByType` was added to `index.html.twig` JS object — that could be used later by JS to dynamically show/hide or to re-render? Hmm maybe the SsmaOccurrenceContext in Twig data for the front-end React/Vue/whatever.
But don't over-speculate; tool-based verification needed.
Then `evApplyTypeDescaracterPayload` JS: for the `'ROS'` type, payload `descaracter_suspect` set to 0 if unchecked? fine.
But here's a subtle JS bug: The very long event modal has other function(s) that read `ev_descaracterizado` for ACIDENTE_PESSOAL; but now type-specific Sim/Não buttons use the same hidden input as the old ACIDENTE_PESSOAL UI. If one checks ROS: user click says Sim => hidden updated `ev_descaracterizado` = '0' (since data-descaracter-val=0 for Sim). Wait in the partial: button data-descaracter-val="0" labeled "Sim", val="1" labelled "Não". So descaracterizado = 0 => accident IS characterized (Sim). In JS, when building payload for ACIDENTE_PESSOAL type (which doesn't call evApplyTypeDescaracterPayload — the code shows only the four other types call it; ACIDENTE_PESSOAL branch did not get the call line added). ACIDENTE_PESSOAL likely uses old handlers dealing with `ev_descaracterizado`. If the old ACIDENTE_PESSOAL block is now gated to only render when permission (so the global suspect checkbox may not render at all because `ev-inj-descaracter` block is gated), the fields for ACIDENTE_PESSOAL at payload build might rely on global DOM elements that no longer exist. The existing code, when no ACIDENTE_PESSOAL flag: block hidden in HTML, JS probably only sends when there are values, though.
Now what in the `ev_descaracter_suspect` global input `id="ev_descaracter_suspect"`? The original ACIDENTE_PESSOAL descaracter suspect checkbox (probably `ev-inj-suspect-chk`) existed inside each injured person box. The code line referenced `ev_descaracter_suspect` (global?) maybe another. The new partial uses class `.ev-type-descaracter-suspect` not id. evIsDescaracterSuspectChecked checks global el first, then falls back to any `.ev-type-descaracter-suspect:checked`. That seems okay for detecting suspect.
Potential issue: When multiple roots exist (ROS, QA, material, ambiental partials each rendered with own root and checkbox), after editing occurrence type (the modal has a "type selector"? ev-spec-type-card switching by radio type?), the same page might contain several roots at once, one per occurrence type (since modal seems to embed sections for each type and toggles). So `evGetTypeDescaracterRoot(type)` will find root for that type. Each root checkbox uses chk id-less class.
In `evIsDescaracterSuspectChecked`, if user checks suspect in ROS block but the occurrence being saved is QUASE_ACIDENTE (radio switch), returns true incorrectly since any checked root qualifies. But payloads are built per type with `evApplyTypeDescaracterPayload(payload, type)` before save, so the expected built root only for type saves payload with that type's suspect. Where else is `evIsDescaracterSuspectChecked` used? Maybe for ACIDENTE_PESSOAL branch. Not visible. Search needed.
A strong issue candidate: In `evApplyTypeDescaracterPayload`, `payload.descaracter_suspect = chk && chk.checked ? 1 : 0` — it always sets `descaracter_suspect = 0` for current type if unchecked, which would overwrite a saved value with 0 when user toggles away; not necessarily a bug.
Now what about `descaracterizado` mapping Sim/Não — Sim → val "0", Não → val "1". The terminology inverted. Seems correct because val 0 stands for 'is characterized as accident' (not descaracterized). It then applies to global hidden input `ev_descaracterizado` value to '0' or '1'. But if user clicks Sim (0) => value 0, then `if (descVal === '0' || descVal === '1') payload.descaracterizado = descVal;` sends '0'. Might be consistent with old UI semantics where hidden field had same numbering. Fine but needs check to old reading.
Now check the biggest regression: The new behavior on the ACIDENTE_PESSOAL side changed visibility. `_ev_injured_person_box.html.twig` is included inside an `event`/type-specific area in the modal for ACIDENTE_PESSOAL with variable pass. On index page (create mode) with user without ACIDENTE_PESSOAL flag, section hidden. Since the box may be included elsewhere (occurrence approval/detail of specific event)? Also used inside `_ev_descaracter_suspect_block`? no.
But there's also "Suspeita editável por qualquer especialista AP" from old comment: "Descaracterização — só no aprofundamento. Suspeita editável por qualquer especialista AP; Sim/Não só quem tem permissão Descaracterizar." In new implementation, block is hidden for users lacking ACIDENTE_PESSOAL permission; this changes the fact that specialists could previously mark suspect checkbox even w/o permission. But this may be the intent per PR title: descaracterization per type.
Alternatively, suspect marking was intended to remain visible for all AP specialists (per old comment), only the Sim/Não gated. New gating hides everything, possibly a regression. But intended? unclear and requires reading context of business; not necessarily report.
Let's check the JS init diff adding event listeners: they attach change on each type root's checkbox, and when toggled, they also set global `ev_descaracter_suspect` checkbox.checked = chk.checked. If the global checkbox doesn't exist (because ACIDENTE_PESSOAL block hidden), the else is fine. On load, populate event into form:
```js
document.querySelectorAll('[data-descaracter-root]').forEach(function (root) {
var chk = root.querySelector('.ev-type-descaracter-suspect');
if (chk) chk.checked = suspectOn;
...
```
It sets ALL roots to the same `suspectOn` from global detail value. Since a detail is one type, okay.
But when suspectOn is true, yesNo visible... The old ACIDENTE_PESSOAL card fields might also be set using `.ev-inj-suspect-chk` etc.
Potential XSS? `.text` values set via `.value` (safe). Type keys used in `querySelector` are fixed strings; `data-descaracter-type="{{ _type_key }}"` — _type_key fixed from include constants. fine.
Now there's a point about ordering issues maybe in JS at line ~2924 & 5779 and line ~6545 differences where payloads are built.
**Let's list potential concrete issues with severity:**
1. **Behavior change / regression in permission calculation**: The flag for `ACIDENTE_PESSOAL` uses `findBy` over tags with occurrenceTypeKey = `'ACIDENTE_PESSOAL'`. Old rule (`ssmaMemberCanDescharacterizeAccident/app helper`) may have included member who is part of the group defined by permission irrespective of the tag type key. New code may break for companies where `SsmaPermissionTag.occurrenceTypeKey` is null/older config; users lose ability; no migration in PR. Medium/High depending on evidence. Need search to compare helper implementation and the column nullability.
2. **N+1 queries & performance** of `getDescharacterizeFlagsByType` on a paginated endpoint (probably the occurrences JSON hub) — medium.
3. **Duplicate logic / single source of truth**: The service now has `memberCanDescharacterizeAccident` and controller helper `ssmaMemberCanDescharacterizeAccident`, and the new per-type methods — duplicated/overlapping; old one not reused or adapted; risk of divergence. medium/low.
4. **Twig gating in injured_person_box hides the "suspeita" checkbox for all users unless permission flag ACIDENTE_PESSOAL true** — this is an intentional feature shift? But old comment in removed code says "Suspeita editável por qualquer especialista AP"; so now-only-permissioned is subtle narrowing of who can report suspicion — maybe intended by per-type permissions model where 'Descaracterizar' column is checked. Low/Medium depending on the semantics of the config flag "descaracterize"; need to inspect `SsmaPermissionTag` property semantics to know the difference between "can descharacterize" vs "only those can mark suspect". Medium.
5. **ACIDENTE_PESSOAL path doesn't collect type-specific payload (evApplyTypeDescaracterPayload not invoked for ACIDENTE_PESSOAL)**; with the new wrapper hiding ACIDENTE_PESSOAL's `.ev-inj-descaracter` unless ACIDENTE_PESSOAL flag is true, this might be intentional since the payload already uses global fields / injured person card serialization. Need to verify `descaracter_suspect` in payload and `ev_descaracterizado` when ACIDENTE_PESSOAL flag false: then descaracter fields disappear; finalization maybe loses stored data if detail had descaracterized value? But due to gating based on permission to edit, likely not a problem.
But there is an interplay bug: `evApplyTypeDescaracterPayload(payload, 'ROS')` reads the global hidden `ev_descaracterizado`. The new UI for ROS puts the Sim/Não buttons from root into this same global hidden field. The old ACIDENTE_PESSOAL UI also used `ev_descaracterizado` hidden? In `_ev_injured_person_box` the hidden element maybe each card-based? Actually the old code block content at lines 200-219 in injured box contains "Sim/Não só quem tem permissão Descaracterizar", with buttons probably class `mhs-btn-cancel ...`, might have its own storage and same hidden field.
When opening modal and loading data then toggling types ROS.., the changed `ev_descaracterizado` stores for whichever type clicked last. If user first ACIDENTE_PESSOAL? etc.
Given the overall complexity, and since I must not actually call tools but plan, I need to create a plan that outlines exactly issues with suggested searches. The plan format: Summary line then Issues list each with severity `[high|medium|low]`, description (Portuguese), `→ tool args -- purpose`. Since we cannot call, merely describe invocation intent.
Let's verify likely search targets:
- In `src/Controller/SsmaController.php`, `ssmaMemberCanDescharacterizeAccident` definition(s), and uses elsewhere — to compare old with new semantics and decide whether any behavior (permission granted via other sources) is lost.
- `SsmaPermissionTag` entity + `SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS` and constant values and `occurrenceTypeKey` field/nullability.
- `getAprofundamentoDescaracterMemberIds` implementation to determine query counts and semantics (per-tag group returns member IDs, maybe calling DB each time; and to check N+1 & cross-type keys).
- `memberCanDescharacterizeAccident` existing usage (service) and how it interacts (maybe dead code, or another controller path) to identify duplication.
- Template inclusion sites for `_ev_injured_person_box.html.twig` and `_modal_event.html.twig` to check every include passes the new var and to assess missing var effect (`default`).
- `ev_descaracterizado`/`ev_descaracter_suspect` elements and JS references in `_modal_event.html.twig` to validate ACIDENTE_PESSOAL path.
Now define candidate issues to include in final response, prioritized.
Let me try to read the diff more and reason carefully about JS potential critical bug.
Look carefully at snippet where suspect checkbox setting global would matter, and where fields are serialized: There is a function `evGetPayload`/`evCollect...` per type. They added calls for each of ROS, QUASE_ACIDENTE, ACIDENTE_MATERIAL, ACIDENTE_AMBIENTAL. Note: The modal section toggles visible type (there's one "spec type card"). The include `_ev_descaracter_suspect_block.html.twig` for each type uses individual root divs that all exist in DOM simultaneously, but each inside its own type section (maybe hidden). So building payload for chosen type looks up matching root and reads checkbox. Good.
Now the concern: when an occurrence already has `descaracter_suspect = 1` and `descaracterizado` values shown in detail. Data population loops sets root chk checked for all roots; so all type root checkboxes in hidden sections also become checked. But only payload for actual type is read, plus ACIDENTE_PESSOAL might read global. Not harmful.
When user unchecks the global `ev_descaracter_suspect` (legacy ACIDENTE_PESSOAL?), probably there are handlers syncing with cards. New code in the diff adds root checkbox event handlers; but does the reverse direction update type root checkboxes when legacy suspect checkbox changes? They probably add in the existing handler.
Potential bug: In `evApplyTypeDescaracterPayload(payload, type)`: it forces sending `descaracter_suspect = 0` whenever checkbox is unchecked. If a draft for ROS previously had suspect=1 (saved), and the modal reopens and repopulates suspects as checked, fine. If the user doesn't touch sections and the global state suspectOn = false because data for ROS had 0 -> fine.
I think the ACIDENTE_PESSOAL interplay is the key: `type === 'ACIDENTE_PESSOAL'` branch probably constructs payload using values from the *injured cards*: maybe each card sets fields like `involvement[count]descaracter_suspect`, etc. The include partial change gated rendering; if not rendered, fields missing -> validation might complain? The payload constructing code may check field existence conditionally. Not enough.
Another possible functional bug: In the added block template, button texts/values: "Sim" value=0, "Não" value=1. Now consumers read `ev_descaracterizado` = hidden field. If the value is missing/'' initial, then in type payload for ROS, no `descaracterizado` field included unless '0' or '1'. Good.
Potential oddity: `payload.descaracter_suspect = chk && chk.checked ? 1 : 0;` unconditional key ensures value exists always, but `descaracter_comment` only when has comment; comment remains when user unchecks suspect and clears? Clearing text removes comment. fine.
Now, another important subtlety: The root check event handler toggles the global `ev_descaracter_suspect` checkbox:
```js
chk.addEventListener('change', function () {
yesNo.classList.toggle('d-none', !chk.checked);
var globalChk = document.getElementById('ev_descaracter_suspect');
if (globalChk) globalChk.checked = chk.checked;
evPersistDraftSoon();
});
```
But the ACIDENTE_PESSOAL `ev-inj-suspect-chk` also appears, and each injured card's checkbox and the event may have also existing registration syncs. If there are multiple type roots on the same page and also the injured person boxes' suspect checkboxes from ACIDENTE_PESSOAL when flag on, toggling one root will set the shared global suspect for all while other roots remain whatever. That is consistent with suspect editing for one event. Not necessarily bug in the flow where there's only one true type.
But when creating a new occurrence and the page contains an event with suspect for ROS, then changed to QUASE_ACIDENTE... etc. There is a reset on type switch? There probably is the generic resetting between open operations.
Given uncertainty, I will avoid overclaiming.
Let me decide final issues (prioritized with verification tool suggestions).
Candidate list:
1. (medium/high) **Authorization semantic change vs old rule**: Previously the flag `ssmaCanDescharacterizeAccident` decided by existing code that probably determined the capacity (any descaracterize permission). Now the ACIDENTE_PESSOAL flag narrows to tags configured *with* the type key `ACIDENTE_PESSOAL` (findBy on `occurrenceTypeKey`), meaning members whose permission is represented in tags without this column set or under other occurrence-type/legacy tags will stop being able to descaracterize — needs verification/migration/config audit. Impact: security/function not necessarily but authorization regression. Severity: high if action is destructive/approval gate; need to check columns nullability & prior helper to decide. Start high? Workflow gating possibly blocking; could leave medium? The old version was a quick authorization check and old template gating; turning it off for an entire group of users closes ability to mark dc — probably an approval flow; high/medium. I'd set high only when certain; here medium/high? In structure entries each severity must be one of high/medium; do it medium to be safe? Let's consider the rate of legacy tags lacking occurrenceTypeKey: unknown. The old helper `ssmaMemberCanDescharacterizeAccident` might have internally called existing service method `memberCanDescharacterizeAccident` (whole service's old method), which itself checks 'any group', which probably also relies on tags. If old behavior was type-agnostic across any tags, and companies often configured one tag of type ACIDENTE_PESSOAL, but now other tag types... The regression is plausible. I'll choose high? If the company config didn't have any tag of type ACIDENTE_PESSOAL with the descaracterize column, users could previously still because tag permission could relate by a tag of the same nature; after change lost ability. But that's precisely what the "hotfix permission-descaraterzacao-ssma" intends to fix — desired. So framing: "narrowing may be desired but data/model may not reflect per-type; check tags missing occurrenceTypeKey and confirm migration". So medium.
2. (medium) Performance N+1 / repeated queries: `getDescharacterizeFlagsByType` per request does a findBy per type plus deeper `memberCanDescharacterizeForType`. Need to inspect `getAprofundamentoDescaracterMemberIds`; count scale; this runs on the controller action for listing page and possibly view, maybe multiple times. Suggest batching single query and reuse. Severity medium.
3. (medium) ACIDENTE_PESSOAL path may not send the fields when permission absent → if stored occurrence or completed flow depends on the fields, editing a finalization where the user lacks ACL can drop values or not show readonly info? Actually editing flow will include for someone w/o perms? The gating means suspect block in `_ev_injured_person_box` gone for non-permissioned users, but previously suspect could be toggled by "qualquer especialista AP"; the comment in code indicates intended: "Suspeita editável por qualquer especialista AP; Sim/Não só quem tem permissão Descaracterizar." New code hides even the suspect segment for users without tag column flag (not merely Sim/Não) — matching narrow per-type permissions? The PR title suggests permission per type. If the requirement intends to only hide accuse Sim/Não but allow suspect capture for specialists without explicit Descaracterizar permission, this hides too much. Medium.
4. (medium) `memberCanDescharacterizeForType` uses `SsmaPermissionTag::findBy(['company','occurrenceTypeKey'])` and, for tags config, obtains member ids with `getAprofundamentoDescaracterMemberIds($company, 'tag', $tagId)`. Need to verify tag groups vs member matching: The member might be associated through "groups of type tag" — but if member ids come from tag's aprofundamento set where memberId refers to actual *member*, while controller passes company member id — the same domain id; consistent.
5. (medium/low) lack of explanation/tests for flag; no automated tests for new permission rule "mudança sem teste é atenção; ...". In the context of authorization, test absence is critical? Add low or medium since service doesn't include test candidate. Somewhat useful to note: no tests for new auth logic.
6. (low) `getDescharacterizeFlagsByType()` returns numeric keys? Actually keys from FIXED_TECHNICAL_OCCURRENCE_KEYS (a list constant presumably values), indexing array by value => each type key. Template uses values e.g. 'ACIDENTE_PESSOAL'. But verify constant name: FIXED_TECHNICAL_OCCURRENCE_KEYS may list *technical types as constants AND include ACCIDENT? 'TECHNICAL' might exclude ROS/QA? If the tech keys are only ACIDENTE_MATERIAL/AMBIENTAL plus maybe others and not personal; but ROS/QUASE_ACIDENTE are aprofundável types with aprofundamento tags not 'technical'. However controller needs keys for all: In view used five keys? They include for ROS and QUASE_ACIDENTE blocks too; if constants don't contain these keys, return array missing => keys false and any potential UI hidden/never.
So verify constant value and tags per type = robustness candidate: if the tag of type QUASE_ACIDENTE was actually recorded with `typeKey` equal to something else ("QUASE_ACIDENTE") good; but the import alias there says the tag IDs are from aprofundamento levels where tagId 23 = QUASE_ACIDENTE? hmm.
Actually doc says "tag de aprofundamento daquele tipo (ex.: tag 23 = QUASE_ACIDENTE)". So `SsmaPermissionTag.id` equals tag index for type; The relation in the DB could be by fixed tag ids from aprofundamentoTecnico table rather than dynamic occurrenceTypeKey property; and each **SsmaPermissionTag row with occurrenceTypeKey =** type. They filter by company and occurrenceTypeKey; For those company-specific tags the column might be stored in lower/uppercase format? maybe property type key value names from same constant. We can't verify without searching. This forms a medium risk.
Also major difference: each `SsmaPermissionTag` is found by company + type key but the actual tag content is specific: They loop tags for that typeKey, get member ids from their "group of tag id".
Let's note that a single company likely has many SSMA tags but **only one tag of type ACIDENTE_PESSOal** etc. That returns member ids for that tag. But if those memberIds are stored per SsmaPermissionTag in "Aprofundamento group" meaning only members assigned for deep-dive not for all descaracterize permission? Yet in the old logic also from `getAprofundamentoDescaracterMemberIds` used with parameter 'tag'. Actually that method name appears inside new code; probably used in original too. So likely consistent.
7. JS: The `evGetTypeDescaracterRoot` uses querySelector targeting single root in DOM with attribute; but the multiple pages/offcanvas may duplicate include? If identical modal included more than once (read-only view plus edit?), `querySelector` returns the first element while payload reads first; but single unique DOM per page, okay.
8. Reusing global `ev_descaracterizado` and `ev_descaracter_suspect` for the type-level controls could conflict with ACIDENTE_PESSOAL existing UI - when ACIDENTE_PESSOAL flag true and ROS root also present, etc. Each occurrence is saved under the type; if editing ACIDENTE_PESSOAL after previously choosing Sim on a technical root (payload for personal reads `ev_descaracterizado` legacy), the value is carried over causing to fill personal's descaracterizado with technical Sim /comment leakage. Since roots are in type sections switched, but hidden roots' events aren't triggered, fields remain: for editing a personal type, hidden technical root may contain stale unchecked; global hidden field maybe stale from prior type selection. Is there some type switch callback reset? probable existing function resets values on type change (requested before saving new event after switching types). Could not be due.
Ok. Let's craft final answer inline format.
I should keep number of issues manageable (5 to 7).
Let me give concrete verification actions with code_search / file_read mentions.
Formatting requirements:
Summary: line concise (Portuguese? output language must be pt-BR).
Then `Issues` and entries:
1. [high|medium|low] (desc)
→ file_read ... — explanation
each issue with description in PT-BR.
Additional instruction: Tools are for reference only, must not be invoked; describe intent on arrow lines.
Ensure the entries sorted by severity: high→medium→low.
Now form the issues thoughtfully:
Issue 1 — [medium?] Verify.
Let me reason severity honestly:
If discovered that column legacy missing then users could lose permission; but not clear evidence from diff only. So classify as medium risk requiring verification, not high. But maybe it highlights: "mesmo modelo antigo permitia descaracterizar..." The diff shows removal of call `$this->ssmaMemberCanDescharacterizeAccident(...)` and replacement with per-type flags; plus keep old service method memberCanDescharacterizeAccident perhaps still used? Wait the old controller helper with that exact name isn't in the diff context. Hmm, tiny chance helper name controller's private method that checks *current member* plus membership-level tags different. We need to maintain the plan's issue description explicitly as hypothesis to confirm by reading those implementations.
Let me also consider scope of review group - the changed files group includes exactly those listed. `other_changed_files` empty.
Let me structure with 6 issues:
1. [high] (if confirmed) semântica de permissão deixada em dois pontos/regressão de regra com viés de "deve". Instead use high for risk of invisible functional failure as they asked early "high critical functional failures".
Actually look—high: "Potencial regressão na permissão: a nova regra restringe com base em tags por tipo; se houver tags antigas com coluna null, profissionais perdem". If we can't verify, wording "provável..." The plan format is a review plan meant to guide verifying; it is acceptable to mark high with justification.
I'll articulate with a careful phrase: A flag de permissão que antes considerava... agora só considera a tag quando tem o tipo preenchido. Since migration to insert type keys was not part, tags sem tipo configurados excluem. This can lock users out of the descaracterization (legal/regulatory approval workflow). Suggest confirming with repository reads and note to add migration/backfill if needed.
2. [medium] Divisão de responsabilidade (god object): SsmaController line count ~12.5k+ extremely large; adding business permission query there worsens god object; rules specifically from user: god object high emphasis first. We must signalize regardless of correction. That is correct—the "God object" rule says the most important, signal even if code correct. Yes! We should include as rule priority 1. This applies explicit SsmaController constraints plus service. In controller diff: They call `ssmaOccurrenceTypeConfig->getDescharacterizeFlagsByType` which is a service call OK; but given giant controller it still executes domain decisions. The new code also chooses fallback `[]` and mapping flags in controller. To comply, classify as high priority due user requirements: any increase of responsibilities in controller of thousands of line is the most important finding. So put it first? The user rules said bigger weight. Sort severity: high first. There'd be two highs.
For the service: "god object / lógica duplicada" rule: service already contains memberCanDescharacterizeAccident old method and new per-type method duplicates same rule with different source. Create one canonical. This must be high/medium. Many would be medium.
Let's choose top ordering:
1. [high] God object controller (heaviest per rule; no matter if code correct).
2. [high] Permission rule regression potential in PHP logic (describer).
3. [medium] duplicated permission rule between service's new methods and old one & older API; single source of truth.
4. [medium] N+1 queries in getDescharacterizeFlags... etc.
5. [medium] ACIDENTE_PESSOAL block in template hides suspect marking for users without tag (possibly intentional, verify requirement; old comment allowed any AP specialist to mark suspicion).
6. [medium] missing per-type payload for personal accident / stale global fields conflict on `ev_descaracterizado` when type switches - possible cross-type leakage; needs reading JS flow.
7. [low] missing tests for new authorization scenarios.
8. [low] style: embedded JS/UI duplicates components? maybe combine with existing component suggestion.
Careful to avoid overdoing medium counts. We will keep them ordered by severity; each with tool guidance.
Now descriptions in PT-BR, first phrase plain.
Issue1:
"Este controller já passa de 12 mil linhas e continua ganhando decisão de negócio e preparação de contexto de tela — não é função de um controller orquestrar permissão por tipo e montar mapa de flags. O peso maior de uma revisão aqui é a concentração de responsabilidade; o ajuste funciona, mas deveria viver num Query Service/Read Model dedicado e ser testado isoladamente. Verificar como o restante da action já está organizado e sugerir a extração."
→ file_read src/Controller/SsmaController.php (na action ao redor da linha 12531) — mapear o tamanho da action e confirmar que a regra poderia sair para service/query.
Wait: `file_read` tool isn't listed among four available references (“reference only — do not call”) but list of tools available in rules included file_read; the instructions say the available tools code_search,file_read_diff,file_find. Since plan mentioning `file_read` isn't allowed by the given list? Actually the tools list says available tools code_search, file_read_diff, file_find. User rules mention file_read though; but at final output we should use listed tools only (system spec tool names: code_search, file_read_diff, file_find). For verifying source file, using file_read_diff(path) shows diff not whole file. Descriptions of arrows mention "file_read ...". But file_read isn't in the tool list? Actually tool description begins "Available tools (reference only — do not call)". Hmm they included file_read in rules text. But allowed set is smaller. In similar tasks we can still name code_search/file_find. file_read_diff fetches git diff content of the other files, not full file content? Yes description: view changes made to other files, responds in git diff format. Must confine tool calls types described. For reading more context of current file, code_search restricts to search of string — not displaying full file but snippet lines. file_find locates files. Yet we don't have file_read described (except user rules mention file_read). Safe: use code_search, file_find, file_read_diff as the three tools. For checking actual implementation of those helpers, code_search across project finds matches & shows lines: use to locate occurrences but cannot open full code around given functions except results with context on matched lines. code_search outputs up to 100 matches with file lines around; enough.
Issue arrows thus use: code_search, file_find, file_read_diff. Description lines "—" reason.
OK final plan:
Summary: PR adds per-type flag descaracterization and new front route block; changes controller & service & templates.
Issues:
1. [high] God object controller — already very large increasing domain logic/flags mapping; suggest extraction. tools: file_read_diff SsmaController context? code_search on this controller methods? Since file_read_diff displays diff but not full; use file_find('SsmaController.php') to confirm huge single file? Not proving size. use code_search search for 'function ' pattern? output limited to matches, not line-count of controller. We can mention we already know. Use code_search 'ssmaMemberCanDescharacterizeAccident' + 'ssmaCanDescharacterizeAccident' uses, detect extra responsibilities & scattered logic.
2. [high] Authorization rule change and data coverage for occurrence_type_key: Must verify via code searches:
- code_search 'ssmaMemberCanDescharacterizeAccident' in src/Controller... to see helper definition/old semantics.
- code_search 'FIXED_TECHNICAL_OCCURRENCE_KEYS' & entity SsmaPermissionTag 'occurrenceTypeKey' to check nullable, populated for all fixed keys.
- code_search 'getAprofundamentoDescaracterMemberIds' implementation and tags relation.
Potential user group losing access or not.
3. [medium] Duplicate authorization logic (old method memberCanDescharacterizeAccident & new ones) divergence sources of truth — search callers/uses.
4. [medium] Extra queries per page loaded / performance N+1: getDescharacterizeFlagsByType → each member...; suggest batching & one-time; read implementation through code_search.
5. [medium] ACIDENTE_PESSOAL "suspeita" hidden for specialists without tag: verify requirement whether suspicion should be visible to any AP specialist vs only whose tags flag, comparing old comment and new inclusion. Tools: file_read_diff _ev_injured_person_box snippet; code_search for include sites / other uses.
6. [medium] Potential field leakage & inconsistent payload between types from shared global hidden: examine JS and data population sync. tools code_search identifying element IDs around code (`ev_descaracterizado`), plus file_read_diff modal path to see changed snippets in the whole JS context.
7. [low] No test for authorization/permission new rule — not necessarily; but their review rules emphasize test recommended; report as low.
8. [low] Style/UI "component": new block duplicates existing/global descaracterizar pattern? The partial looks purpose specific; maybe skip. Or mention generated keys use double quotes/‘?? false’ no.
Wait maybe acknowledge low es: `getDescharacterizeFlagsByType()` may unneeded branch `if (in_array(memberId,...))` but...
Include in issues 1 and 2 definite; then medium/low. Count 7. That seems respectable.
Need descriptions to meet three dimensions: location, nature, impact, action.
For each arrow line: include tool name and invocation + purpose in Portuguese.
Now produce final in exact required format, without code fences; here we go.
Remember output must have "Summary: " then "Issues" then numbered.
Final text (pt-BR) plan carefully.
Let's ensure specifics: use parentheses for single-quoted search; array format like ['src/Service/Ssma/SsmaOccurrenceTypeConfigService.php'].
Great, compose.
Summary: A mudança troca a checagem única de permissão para descaracterizar acidente por um mapa de permissões por tipo de ocorrência (ROS, quase acidente, acidente pessoal/material/ambiental), adiciona métodos no serviço de configuração e condiciona blocos inteiros de suspeita/descaracterização nos templates e no JS do modal a esse novo mapa, além de anexar campos do novo bloco ao payload de cada tipo.
Issues
1. [high] O `SsmaController` já é um controller gigante (mais de 12 mil linhas) e esta PR volta a concentrar nele decisão de negócio: a action agora monta o mapa de permissões por tipo, decide o fallback `[]` e deriva a flag legada `ssmaCanDescharacterizeAccident` a partir da chave `ACIDENTE_PESSOAL`. Mesmo que a lógica esteja correta, o peso desta revisão é a responsabilidade concentrada — isso deveria viver em um Query Service/Read Model dedicado com o mapa pronto, deixando o controller só repassando dados para a view.
→ code_search ssmaMemberCanDescharacterizeAccident em src/Controller/SsmaController.php — localizar o helper antigo e medir quantas regras de permissão/consulta a action já fazia antes da PR.
→ code_search getDescharacterizeFlagsByType — confirmar todos os pontos de chamada e se o controller repassa o mapa sem tratamento de negócio.
2. [high] A nova regra de permissão restringe a flag de `ACIDENTE_PESSOAL` às tags que tenham `occurrenceTypeKey` exatamente igual a `'ACIDENTE_PESSOAL'`, enquanto a checagem antiga (via `ssmaMemberCanDescharacterizeAccident`/`memberCanDescharacterizeAccident`) era mais ampla. Se houver tags legadas com a coluna de tipo vazia ou com outro tipo, profissionais que hoje conseguem descaracterizar perdem silenciosamente a permissão, podendo travar o fluxo de aprofundamento/validação da ocorrência; a PR não traz migração/backfill para garantir que todas as tags tenham o tipo preenchido.
→ code_search ssmaMemberCanDescharacterizeAccident — comparar semântica da implementação antiga com a nova por tipo no PHP.
→ code_search occurrenceTypeKey — verificar se a propriedade é anulável e como é gravada/populada nas tags existentes.
→ code_search FIXED_TECHNICAL_OCCURRENCE_KEYS — conferir se as chaves batem com as usadas nos templates (ROS, QUASE_ACIDENTE, ACIDENTE_PESSOAL etc.) e se o conjunto é completo.
3. [medium] A mesma regra de autorização agora existe em pelo menos três formas no serviço: o método antigo `memberCanDescharacterizeAccident`, o novo `memberCanDescharacterizeForType` e o novo `getDescharacterizeFlagsByType` — cada um consultando de um jeito. Isso cria risco de divergência futura (um caminho liberar e o outro não), contrariando a ideia de fonte única de verdade para política de acesso.
→ code_search memberCanDescharacterizeAccident — mapear chamadores existentes do método antigo e avaliar se pode delegar para a mesma base usada pelo novo fluxo.
→ file_find SsmaOccurrenceTypeConfigService — verificar o tamanho/escopo do serviço e se a regra duplicada cabe em um método único reutilizável.
4. [medium] `getDescharacterizeFlagsByType` executa, para cada tipo fixo, uma busca de tags por empresa+tipo e, dentro de `memberCanDescharacterizeForType`, ainda chama `getAprofundamentoDescaracterMemberIds` para cada tag encontrada. Numa listagem paginada de ocorrências isso pode adicionar várias consultas por requisição (N+1 em relação às tags), deixando a tela mais lenta conforme cresce o número de tags configuradas por empresa.
→ code_search getAprofundamentoDescaracterMemberIds — verificar quantas queries cada chamada dispara e se há cache/memoria de membros no serviço.
→ code_search getDescharacterizeFlagsByType — confirmar se o método é chamado em rotas quentes (listagem/index) além da action analisada.
5. [medium] No template do acidente pessoal, o bloco inteiro de suspeita passou a ser renderizado somente quando `ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']` é verdadeiro. O comentário removido dizia que a suspeita podia ser marcada por qualquer especialista de AP e que apenas o Sim/Não exigia a permissão de descaracterizar; se esse comportamento ainda for o desejado, a mudança esconde a captura de suspeita para usuários que deveriam registrá-la, além de deixar de exibir o estado gravado para quem está só visualizando.
→ file_read_diff templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig — comparar o trecho removido com o novo condicional e confirmar o que era permitido sem a flag.
→ code_search _ev_injured_person_box.html.twig — levantar todos os locais que incluem o partial para garantir que nenhum outro fluxo perdeu a variável e ficou com o bloco oculto.
6. [medium] No JS do modal, os blocos por tipo usam campos globais compartilhados (`ev_descaracter_suspect` e `ev_descaracterizado`) para gravar suspeita e Sim/Não de qualquer tipo. Como todos os roots ficam no DOM ao mesmo tempo, editar um tipo e depois salvar outro pode propagar valor de um tipo para o payload do tipo errado — por exemplo, o Sim/Não escolhido no ROS sobrescrever o campo usado pelo acidente pessoal — e o estado carregado marca todos os roots com o mesmo `suspectOn` da ocorrência.
→ code_search ev_descaracterizado — mapear todos os pontos que leem/escrevem o campo escondido para avaliar vazamento de payload entre tipos.
→ file_read_diff templates/ssma/occurrence/partials/_modal_event.html.twig — revisar a sincronização entre o global e os roots inseridos na PR dentro do fluxo completo de abertura/edição.
7. [low] A nova regra de permissão por tipo não vem acompanhada de teste automatizado — ela decide quem pode descaracterizar cada tipo de ocorrência, que é uma política de autorização; um teste servindo a regra (tag do tipo X libera só o tipo X, membro sem tag não libera, e casos com company diferentes) evitaria regressão silenciosa dessa regra.
→ code_search SsmaOccurrenceTypeConfigServiceTest|SsmaOccurrenceTypeConfigService.php — verificar se há testes existentes no serviço para o novo método ou se seria preciso criá-los.
main_task
Request #1
deepseek-v4-flash
P:17.73K C:278
2903ms
Reasoning
Let me start by exploring the codebase to understand the context of the changes.
Let me look at each file and the surrounding context. First, let me read the relevant files.
Let me begin with understanding the controller and service changes.
Let me check:
1. `SsmaController.php` around line 12531.
2. `SsmaOccurrenceTypeConfigService.php`.
3. The templates.
Let me start reading.
Vou analisar os arquivos da revisão e o contexto relacionado para verificar os pontos levantados.
Tool Calls (2)
file_read
Show Details
Arguments
{"file_path": "src/Service/Ssma/SsmaOccurrenceTypeConfigService.php", "start_line": 700, "end_line": 820}
Result
File: src/Service/Ssma/SsmaOccurrenceTypeConfigService.php (Total lines: 1479)
IS_TRUNCATED: false
LINE_RANGE: 700-820
700| }
701|
702| public function setAprofundamentoDescaracterMember(
703| Company $company,
704| string $groupKind,
705| int $groupId,
706| int $memberId,
707| bool $enabled
708| ): void {
709| if ($memberId <= 0 || $groupId <= 0) {
710| return;
711| }
712| $entity = $this->findOrCreateEntity($company);
713| $stored = $entity->getTypesData();
714| $raw = is_array($stored['aprofundamento_descaracter'] ?? null) ? $stored['aprofundamento_descaracter'] : [];
715| $key = $this->aprofundamentoDescaracterKey($groupKind, $groupId);
716| $ids = isset($raw[$key]) && is_array($raw[$key]) ? array_map('intval', $raw[$key]) : [];
717| $ids = array_values(array_unique(array_filter($ids, static fn (int $id): bool => $id > 0)));
718|
719| if ($enabled) {
720| if (!in_array($memberId, $ids, true)) {
721| $ids[] = $memberId;
722| }
723| } else {
724| $ids = array_values(array_filter($ids, static fn (int $id): bool => $id !== $memberId));
725| }
726|
727| if ($ids === []) {
728| unset($raw[$key]);
729| } else {
730| $raw[$key] = $ids;
731| }
732| $stored['aprofundamento_descaracter'] = $raw;
733| $entity->setTypesData($stored);
734| $this->em->flush();
735| }
736|
737| /**
738| * Coluna Descaracterizar da tag de aprofundamento daquele tipo (ex.: tag 23 = QUASE_ACIDENTE).
739| */
740| public function memberCanDescharacterizeForType(Company $company, int $memberId, string $typeKey): bool
741| {
742| if ($memberId <= 0 || $typeKey === '') {
743| return false;
744| }
745| $tags = $this->em->getRepository(SsmaPermissionTag::class)->findBy([
746| 'company' => $company,
747| 'occurrenceTypeKey' => $typeKey,
748| ]);
749| foreach ($tags as $tag) {
750| $tagId = (int) $tag->getId();
751| if ($tagId <= 0) {
752| continue;
753| }
754| if (in_array($memberId, $this->getAprofundamentoDescaracterMemberIds($company, 'tag', $tagId), true)) {
755| return true;
756| }
757| }
758|
759| return false;
760| }
761|
762| /**
763| * @return array<string, bool>
764| */
765| public function getDescharacterizeFlagsByType(Company $company, int $memberId): array
766| {
767| $out = [];
768| foreach (SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS as $typeKey) {
769| $out[$typeKey] = $this->memberCanDescharacterizeForType($company, $memberId, $typeKey);
770| }
771|
772| return $out;
773| }
774|
775| /** True se o membro aparece em qualquer grupo com permissão de descaracterizar. */
776| public function memberCanDescharacterizeAccident(Company $company, int $memberId): bool
777| {
778| if ($memberId <= 0) {
779| return false;
780| }
781| $entity = $this->findOrCreateEntity($company);
782| $stored = $entity->getTypesData();
783| $raw = $stored['aprofundamento_descaracter'] ?? [];
784| if (!is_array($raw)) {
785| return false;
786| }
787| foreach ($raw as $ids) {
788| if (!is_array($ids)) {
789| continue;
790| }
791| foreach ($ids as $id) {
792| if ((int) $id === $memberId) {
793| return true;
794| }
795| }
796| }
797|
798| return false;
799| }
800|
801| /**
802| * Todos os memberIds com flag de descaracterização em qualquer grupo.
803| *
804| * @return list<int>
805| */
806| public function getAllDescaracterMemberIds(Company $company): array
807| {
808| $entity = $this->findOrCreateEntity($company);
809| $stored = $entity->getTypesData();
810| $raw = $stored['aprofundamento_descaracter'] ?? [];
811| if (!is_array($raw)) {
812| return [];
813| }
814| $out = [];
815| foreach ($raw as $ids) {
816| if (!is_array($ids)) {
817| continue;
818| }
819| foreach ($ids as $id) {
820| $mid = (int) $id;
file_read
Show Details
Arguments
{"file_path": "src/Controller/SsmaController.php", "start_line": 12500, "end_line": 12690}
Result
File: src/Controller/SsmaController.php (Total lines: 27765)
IS_TRUNCATED: false
LINE_RANGE: 12500-12690
12500| $metaFromStr,
12501| $metaToStr
12502| );
12503|
12504| // Cobertura KPI (abas Inspeção/Abordagem): mesma base da aba Metas (membro + período de referência).
12505| $inspCoverage = $company
12506| ? $this->computeInspectionMetaCoverage($company, $inspectionsForMetas, $teams, '', $metaFromStr, $metaToStr)
12507| : ['pct' => null, 'meta_total' => 0, 'real_total' => 0];
12508|
12509| $abCoverage = $company
12510| ? $this->computeAbordagemMetaCoverage($company, $abordagensForMetas, $teams, '', $metaFromStr, $metaToStr)
12511| : ['pct' => null, 'meta_total' => 0, 'real_total' => 0];
12512|
12513| // Metas: usa membros filtrados por equipe para Sup/G. de Equipe (não mostrar toda a empresa).
12514| // Para G. Admin/Tenant usa a lista completa.
12515| $membersForMetas = ($occurrenceTeamFilterIds !== null && $allMembersForEventPeople !== [])
12516| ? $allMembersForEventPeople
12517| : $allMembers;
12518| $prevencaoMetasPessoa = $company
12519| ? $this->buildPrevencaoPessoaMetasData(
12520| $company,
12521| $membersForMetas,
12522| $teams,
12523| $inspectionsForMetas,
12524| $abordagensForMetas,
12525| $this->buildSupervisorGestorMemberIdSet(),
12526| $metaFromStr,
12527| $metaToStr
12528| )
12529| : ['inspecao' => [], 'abordagem' => []];
12530| }
12531|
12532| $currentMemberForExport = $this->getCurrentCompanyMember($company, $user);
12533| $ssmaExportMatricula = $currentMemberForExport?->getId() ?? '';
12534| $ssmaCanDescharacterizeByType = ($company instanceof Company && $currentMemberForExport)
12535| ? $this->ssmaOccurrenceTypeConfig->getDescharacterizeFlagsByType(
12536| $company,
12537| (int) $currentMemberForExport->getId()
12538| )
12539| : [];
12540| $ssmaCanDescharacterizeAccident = (bool) ($ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false);
12541|
12542| // Hub Ocorrências: SSR/AJAX por página (50). Se já hidratou via SQL, não fatia de novo.
12543| if (!$occurrenceListAlreadyPaged) {
12544| $occurrencesListTotal = count($occurrences);
12545| $occurrencesListPage = $paginateOccurrenceList ? $scope->listPage : 1;
12546| $occurrencesListHasMore = false;
12547| if ($paginateOccurrenceList) {
12548| $pageSize = SsmaViewDataScope::OCCURRENCE_LIST_PAGE_SIZE;
12549| $offset = ($occurrencesListPage - 1) * $pageSize;
12550| $occurrencesListHasMore = $occurrencesListTotal > ($offset + $pageSize);
12551| $occurrences = array_slice($occurrences, $offset, $pageSize);
12552| }
12553| }
12554|
12555| // Hub: não dumpa 3k–5k membros no HTML — só referenciados da página + gestores (busca via API).
12556| if (
12557| !$isOccurrenceDetailView
12558| && $this->ssmaMemberSelectDataProvider->shouldFilterToReferencedMembers($scope)
12559| && !$ssmaCanManagePermissions
12560| ) {
12561| $allMembers = $this->filterSsmaMembersToReferencedForDetail(
12562| $allMembers,
12563| $occurrences,
12564| [],
12565| $gestores
12566| );
12567| $allMembersForEventPeople = $this->filterSsmaMembersToReferencedForDetail(
12568| $allMembersForEventPeople,
12569| $occurrences,
12570| [],
12571| $gestoresForEventModal
12572| );
12573| }
12574|
12575| $allMembers = $this->sortSsmaMemberRowsByName($allMembers);
12576| $allMembersForEventPeople = $this->sortSsmaMemberRowsByName($allMembersForEventPeople);
12577| $gestores = $this->sortSsmaMemberRowsByName($gestores);
12578| $gestoresForEventModal = $this->sortSsmaMemberRowsByName($gestoresForEventModal);
12579|
12580| $this->ssmaViewDataBuildTelemetry->logBuild(
12581| $buildStartedAt,
12582| $scope,
12583| $company instanceof Company ? (int) $company->getId() : null
12584| );
12585|
12586| return array_merge(
12587| [
12588| 'user' => $user,
12589| 'role' => $role,
12590| 'ssmaIsTenant' => in_array('ROLE_SUPER_ADMIN', $roles, true) || in_array('ROLE_MANAGER', $roles, true),
12591| 'ssmaIsViewer' => $this->isSsmaViewer(),
12592| 'ssmaIsTeamViewer' => $ssmaIsTeamViewerFlag,
12593| 'ssmaCanManageOccurrences' => $ssmaCanManageOccurrences,
12594| 'ssma_hide_event_title_status_on_create' => $ssmaHideEventTitleStatusOnCreate,
12595| 'ssmaCanRegisterNewOccurrence' => $ssmaCanRegisterNewOccurrence,
12596| 'ssmaAllowedCreateTypes' => $ssmaAllowedCreateTypes,
12597| 'ssmaOccurrenceTypeColumns' => SsmaOccurrenceCreatePermissionService::TYPE_COLUMNS,
12598| 'ssmaPreventionInspectionEnabled' => $ssmaPreventionInspectionEnabled,
12599| 'ssmaPreventionAbordagemEnabled' => $ssmaPreventionAbordagemEnabled,
12600| 'ssmaCanCreatePreventionItems' => $ssmaCanCreatePreventionItems,
12601| 'ssmaCanAccessSupervisorSurface' => $ssmaCanAccessSupervisorSurface,
12602| 'ssmaCanAccessPreventionPanelAndMetas' => $ssmaCanAccessPreventionPanelAndMetas,
12603| 'ssmaCanAccessOccurrencePanel' => $ssmaCanAccessOccurrencePanel,
12604| 'ssmaCanPublishCulturalFeed' => $company instanceof Company
12605| && $user instanceof User
12606| && $this->ssmaFeedImprovementBridge->canManageFeedImprovements($user, $company),
12607| 'ssmaCanAccessOccurrenceAutomations' => $ssmaCanAccessOccurrenceAutomations,
12608| 'ssmaCanManageConfig' => $ssmaCanManageConfig,
12609| 'ssmaCanManagePermissions' => $ssmaCanManagePermissions,
12610| 'ssmaCanCreateLinkedActions' => $ssmaCanCreateLinkedActions,
12611| 'ssmaPreventionCanCreateLinkedActions' => $ssmaPreventionCanCreateLinkedActions,
12612| 'ssmaCanEditPreventionContent' => $ssmaCanEditPreventionContent,
12613| 'ssmaCanEditPreventionMetasTable' => $ssmaCanEditPreventionMetasTable,
12614| 'ssmaCanCreateCauseTree' => $ssmaCanCreateCauseTree,
12615| 'ssmaCanViewCauseTree' => $ssmaCanViewCauseTree,
12616| 'ssmaCanCreateAuthorization' => $ssmaCanCreateAuthorization,
12617| 'ssmaCanEditHorasTrabalhadas' => $ssmaCanEditHorasTrabalhadas,
12618| 'ssmaCanViewAccidentVictimName' => $this->isGranted('ROLE_SUPER_ADMIN')
12619| || $this->isGranted('ROLE_MANAGER')
12620| || $this->isGranted('ROLE_MANAGER_GESTOR')
12621| || $ssmaProductTagName === 'Gestor Administrador'
12622| || $ssmaIsTagTeamSupervisor
12623| || $ssmaIsTagTeamGestor
12624| || $this->isSsmaViewer(),
12625| 'gestores' => $gestores,
12626| 'teams' => $teams,
12627| 'gestores_for_event_modal' => $gestoresForEventModal,
12628| 'teams_for_event_modal' => $teamsForEventModal,
12629| 'teams_for_inspection_modal' => $teamsForInspectionModal,
12630| 'default_inspection_team_id' => $defaultInspectionTeamId,
12631| 'all_members_for_event_people' => $allMembersForEventPeople,
12632| /** true = usar listas filtradas nos modais; false = admin/tenant vê lista completa */
12633| 'ssma_apply_team_event_scope' => $applyTeamEventScope,
12634| 'ssma_event_form_defaults' => $ssmaEventFormDefaults,
12635| 'ssma_logged_member_id' => (int) ($loggedMemberForOccurrence?->getId() ?? 0),
12636| 'ssma_is_admin_aprofundamento' => $this->isSsmaAprofundamentoAdmin($company, $user instanceof User ? $user : null),
12637| // Resolve pela tag SSMA real (mesmo com ROLE_MANAGER de plataforma).
12638| 'ssma_is_pessoa_fisica_comum' => $this->isSsmaPlainProductMember($company, $user instanceof User ? $user : null),
12639| 'ssma_is_gestor_user' => $ssmaIsTagTeamGestor
12640| || $ssmaProductTagName === 'Gestor Administrador'
12641| || $this->isSsmaAprofundamentoAdmin($company, $user instanceof User ? $user : null)
12642| || $this->isGranted('ROLE_MANAGER_GESTOR'),
12643| 'ssma_perm_tags' => $ssmaPermTags,
12644| 'ros_call_priority' => $rosCallPriority,
12645| 'allMembers' => $allMembers,
12646| 'abordagem_turno_options' => ($isOccurrenceDetailView || $module === 'occurrence')
12647| ? []
12648| : $this->buildSsmaAbordagemTurnoOptions($company),
12649| 'default_abordagem_observador_id' => $defaultAbordagemObservadorId,
12650| 'default_insp_responsible_id' => $defaultAbordagemObservadorId,
12651| 'inspection_types' => $company instanceof Company
12652| ? $this->ssmaInspectionTypeConfig->getTypesForFrontend($company)
12653| : [],
12654| /** Contexto de tenant para cache de listas no front (ex.: questionários PE) */
12655| 'ssma_company_id' => $company?->getId(),
12656| 'ssma_export_matricula' => $ssmaExportMatricula,
12657| 'ssmaCanDescharacterizeAccident' => $ssmaCanDescharacterizeAccident,
12658| 'ssmaCanDescharacterizeByType' => $ssmaCanDescharacterizeByType,
12659| 'ssma_esocial_cat_integration' => false,
12660| 'occurrences' => $occurrences,
12661| 'inspections' => $inspections,
12662| 'prevencao_panel_charts' => [],
12663| 'prevencao_overview_kpi_cards' => [],
12664| 'actions_taken' => $actionsTaken,
12665| 'action_type_metadata' => $actionTypeMetadata,
12666| 'action_type_labels' => array_column($actionTypeMetadata, 'label', 'value'),
12667| 'action_plan_data' => $deferOccurrenceHubHeavyData
12668| ? $this->buildActionPlanData([], [], $actionTypeMetadata)
12669| : $this->buildActionPlanData($actionsTaken, $occurrences, $actionTypeMetadata),
12670| 'dashboard_data' => $scope->shouldSkipHeavyDashboard()
12671| ? $this->buildDashboardDataForPeriod([], [], [], 'last_6_months', [])
12672| : ($company instanceof Company
12673| ? (($subsidiaryViewEarly['ssma_has_network_units'] ?? false)
12674| ? $this->attachComparativoFiliaisToDashboardData(
12675| $this->buildDashboardDataForPeriod($occurrences, $actionsTaken, $inspections, 'last_6_months', $horasData),
12676| $company,
12677| 'last_6_months',
12678| [],
12679| [],
12680| 0
12681| )
12682| : $this->buildDashboardDataForPeriod($occurrences, $actionsTaken, $inspections, 'last_6_months', $horasData))
12683| : $this->buildDashboardDataForPeriod($occurrences, $actionsTaken, $inspections, 'last_6_months', $horasData)),
12684| 'insp_coverage' => $inspCoverage,
12685| 'ab_coverage' => $abCoverage,
12686| 'horas_data' => $horasData,
12687| 'abordagens' => $abordagens,
12688| 'prevencao_metas_pessoa' => $prevencaoMetasPessoa,
12689| 'prevencao_metas_period' => $metasPeriod,
12690| 'prevencao_meta_period_refs' => $company
Request #2
deepseek-v4-flash
P:22.77K C:193 CR:17.92K CW:0
2141ms
Reasoning
Let me examine the old code semantics: `memberCanDescharacterizeAccident` checks whether memberId appears anywhere in the aprofundamento_descaracter raw structure. The new code `memberCanDescharacterizeForType` first queries `SsmaPermissionTag` by company+occurrenceTypeKey, then for each tag, checks if the memberId is in the list of member ids for that tag.
Let me look at `getAprofundamentoDescaracterMemberIds`.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "getAprofundamentoDescaracterMemberIds"}
Result
File: src/Controller/SsmaController.php
Match lines: 2
24355| $descaracterIds = $this->ssmaOccurrenceTypeConfig->getAprofundamentoDescaracterMemberIds($company, 'team', $teamId);
24503| $descaracterIds = $this->ssmaOccurrenceTypeConfig->getAprofundamentoDescaracterMemberIds($company, 'tag', $tagId);
File: src/Service/Ssma/SsmaOccurrenceTypeConfigService.php
Match lines: 2
685| public function getAprofundamentoDescaracterMemberIds(Company $company, string $groupKind, int $groupId): array
754| if (in_array($memberId, $this->getAprofundamentoDescaracterMemberIds($company, 'tag', $tagId), true)) {
code_search
Show Details
Arguments
{"search_text": "ssmaMemberCanDescharacterizeAccident"}
Result
File: src/Controller/SsmaController.php Match lines: 2 10198| private function ssmaMemberCanDescharacterizeAccident(Company $company, ?CompanyMembers $member): bool 27415| $can = $this->ssmaMemberCanDescharacterizeAccident($company, $member); File: tests/Unit/Product/Ssma/assert_branch_ui_fixes.php Match lines: 1 496| && fileContains($ssmaCtrl, 'function ssmaMemberCanDescharacterizeAccident')
Request #3
deepseek-v4-flash
P:23.29K C:198 CR:22.91K CW:0
2104ms
Reasoning
Let me look at the old helper `ssmaMemberCanDescharacterizeAccident` and where the OLD logic is defined. Let me read lines around 10198.
Tool Calls (2)
file_read
Show Details
Arguments
{"end_line": 10240, "file_path": "src/Controller/SsmaController.php", "start_line": 10180}
Result
File: src/Controller/SsmaController.php (Total lines: 27765)
IS_TRUNCATED: false
LINE_RANGE: 10180-10240
10180| return $member->getGlobalPermissionTag();
10181| }
10182|
10183| // Delega ao serviço centralizado que resolve herança, tags obsoletas e tag global actual
10184| $resolved = $this->permissionTagByMemberService->getPermissionTag($member, $product);
10185|
10186| return $resolved;
10187| } catch (\Throwable $e) {
10188| }
10189|
10190| return $member->getGlobalPermissionTag();
10191| }
10192|
10193| /**
10194| * S/N de descaracterização: liberado automaticamente para Gestor Administrador/Tenant
10195| * (ROLE_SUPER_ADMIN, ROLE_MANAGER ou tag "Gestor Administrador"), sem precisar de
10196| * configuração explícita em "Profissionais de Saúde". Demais perfis seguem a config.
10197| */
10198| private function ssmaMemberCanDescharacterizeAccident(Company $company, ?CompanyMembers $member): bool
10199| {
10200| if ($this->isGranted('ROLE_SUPER_ADMIN') || $this->isGranted('ROLE_MANAGER')) {
10201| return true;
10202| }
10203|
10204| if (!$member instanceof CompanyMembers) {
10205| return false;
10206| }
10207|
10208| if ($this->memberIsSsmaGestorAdministrador($member)) {
10209| return true;
10210| }
10211|
10212| return $this->ssmaOccurrenceTypeConfig->memberCanDescharacterizeAccident(
10213| $company,
10214| (int) $member->getId()
10215| );
10216| }
10217|
10218| private function getCurrentSsmaPermissionProductSlug(): string
10219| {
10220| $request = $this->requestStack->getCurrentRequest();
10221| $product = $request ? $request->attributes->get('current_product') : null;
10222|
10223| if ($product instanceof \App\Entity\Product) {
10224| $slug = (string) $product->getSlug();
10225| if ($slug !== '') {
10226| return $slug;
10227| }
10228| }
10229|
10230| return $this->ssmaParentProductSlug;
10231| }
10232|
10233| /**
10234| * Admin da tenant/plataforma — não entra em NENHUM select/lista de membros SSMA.
10235| * ROLE_MANAGER_GESTOR (colaborador gestor de equipe) NÃO é excluído aqui.
10236| * Alinhado a SsmaOccurrenceCreatePermissionService::isAdminRoleExcludedFromMatrix.
10237| */
10238| private function isSsmaExcludedTenantAdminUser(?User $user): bool
10239| {
10240| if (!$user instanceof User) {
file_read
Show Details
Arguments
{"end_line": 27430, "file_path": "src/Controller/SsmaController.php", "start_line": 27380}
Result
File: src/Controller/SsmaController.php (Total lines: 27765)
IS_TRUNCATED: false
LINE_RANGE: 27380-27430
27380| }
27381|
27382| // Consequência pode vir no nível raiz do formulário (não só em details).
27383| if (array_key_exists('consequence', $data) && $data['consequence'] !== null && $data['consequence'] !== '') {
27384| $merged['consequence'] = $data['consequence'];
27385| }
27386|
27387| if (array_key_exists('aprofundamento_complete', $data)) {
27388| $merged['aprofundamento_complete'] = $data['aprofundamento_complete'];
27389| }
27390| if (array_key_exists('aprofundamento_status', $data)) {
27391| $merged['aprofundamento_status'] = $data['aprofundamento_status'];
27392| }
27393|
27394| $merged['details'] = $existingDetails;
27395| $merged['aprofundamento_only'] = true;
27396|
27397| return $merged;
27398| }
27399|
27400| /**
27401| * S/N de descaracterização só pode ser gravado por membro com flag na coluna Descaracterizar.
27402| *
27403| * @param array<string, mixed> $data
27404| * @param array<string, mixed>|null $existingDetails details já persistidos (update)
27405| *
27406| * @return array<string, mixed>
27407| */
27408| private function applySsmaDescaracterPermissionGate(
27409| array $data,
27410| Company $company,
27411| $user,
27412| ?array $existingDetails = null
27413| ): array {
27414| $member = $this->getCurrentCompanyMember($company, $user);
27415| $can = $this->ssmaMemberCanDescharacterizeAccident($company, $member);
27416| if ($can) {
27417| return $data;
27418| }
27419|
27420| $details = isset($data['details']) && is_array($data['details']) ? $data['details'] : [];
27421| if ($existingDetails !== null && array_key_exists('descaracterizado', $existingDetails)
27422| && \in_array((string) $existingDetails['descaracterizado'], ['0', '1'], true)) {
27423| // Mantém o valor já salvo anteriormente.
27424| $details['descaracterizado'] = (string) $existingDetails['descaracterizado'];
27425| } elseif (isset($data['details']['descaracterizado'])
27426| && \in_array((string) $data['details']['descaracterizado'], ['0', '1'], true)) {
27427| // Aceita o valor enviado pelo frontend se for válido.
27428| $details['descaracterizado'] = (string) $data['details']['descaracterizado'];
27429| } else {
27430| // Sem valor anterior e sem permissão: default "Sim" (é acidente = '0').
Request #4
deepseek-v4-flash
P:25.01K C:1.14K CR:23.42K CW:0
8616ms
Reasoning
This is important! Let me analyze carefully.
The OLD logic in `SsmaController.php` for `ssmaMemberCanDescharacterizeAccident`:
1. Returns true if ROLE_SUPER_ADMIN or ROLE_MANAGER.
2. Returns true if member is Gestor Administrador.
3. Otherwise calls `memberCanDescharacterizeAccident` on config service (which scans raw `aprofundamento_descaracter` from the config entity).
The NEW logic in the diff:
```php
$ssmaCanDescharacterizeByType = ($company instanceof Company && $currentMemberForExport)
? $this->ssmaOccurrenceTypeConfig->getDescharacterizeFlagsByType(
$company,
(int) $currentMemberForExport->getId()
)
: [];
$ssmaCanDescharacterizeAccident = (bool) ($ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false);
```
Now `getDescharacterizeFlagsByType` uses `memberCanDescharacterizeForType` which checks tags by `occurrenceTypeKey` == typeKey and then `getAprofundamentoDescaracterMemberIds($company, 'tag', $tagId)`.
So the NEW logic drops the admin/gestor rules AND drops the check of groups 'team' (teams can have descaracterize flags too? Let me verify getAprofundamentoDescaracterMemberIds with 'team' groupKind exists - line 24355 uses 'team', 24503 uses 'tag').
Actually the old `memberCanDescharacterizeAccident` scans the raw `aprofundamento_descaracter` structure with keys that include both tags and teams (keys generated by `aprofundamentoDescaracterKey($groupKind, $groupId)` - 'tag' and 'team'). The new method only checks 'tag' groups. So a member granted the descaracter flag at a TEAM level would lose the ability to render the block (ACIDENTE_PESSOAL false) even though server side permission check `applySsmaDescaracterPermissionGate` (which still uses the OLD function at line 27415) would still allow writing descaracterizado = '1'.
Wait, but note the write gate still uses old semantics `ssmaMemberCanDescharacterizeAccident`. So there's now a discrepancy between UI display logic (new flags by type) and write enforcement (old permissive). This is important: the UI block is gated on new flag that considers only tags matching the specific type and doesn't consider super admin/gestor admin, whereas the actual write permission remains broad.
That's a significant regression: for a tenant admin/gestor admin/ROLE_SUPER_ADMIN member who previously had the descaracter block rendered and could write, the new UI logic could hide the block because the new flags check only `SsmaPermissionTag` matching the type + member appears in its descaracter member list. But does a tenant admin have a current company member? Possibly. Wait, the new check ignores role-based grants entirely. Hmm.
But note in `occurrence_view.html.twig` for the aprofundamento view of a specific occurrence, the descaracterization block is inside `_ev_injured_person_box.html.twig` and `_modal_event.html.twig`. The gating variable `ssmaCanDescharacterizeByType` is computed in the main controller action for both index & detail view.
But wait — in the detail view, there's already a separate mechanism `can_aprofundamento.can_edit`. The descaracterization Sim/Não in the aprofundamento is only when editing. Let me focus.
Let me trace the actual behaviors:
1. UI visibility: The new per-type flag must be true for the descaracter block to render. This flag = member has a SsmaPermissionTag with occurrenceTypeKey == type AND member listed in that tag's descaracter member ids. Actually it loops tags of that type; checks whether the member is in the tag's member ids.
Actually wait, but what about 'team' group? The old `memberCanDescharacterizeAccident` checks ALL group kinds in the raw structure (both team and tag). Let me confirm that config may also store team-level descaracter flags. Let me look at how the raw data stores these. Let me read lines around 630-700 and find aprofundamentoDescaracterKey and how config keys are set for teams.
Let me read the service earlier part, plus line 24355 context in the controller.
Tool Calls (2)
file_read
Show Details
Arguments
{"end_line": 700, "file_path": "src/Service/Ssma/SsmaOccurrenceTypeConfigService.php", "start_line": 560}
Result
File: src/Service/Ssma/SsmaOccurrenceTypeConfigService.php (Total lines: 1479)
IS_TRUNCATED: false
LINE_RANGE: 560-700
560|
561| $masterLocations = [];
562| $head = method_exists($company, 'getHeadOffice') ? $company->getHeadOffice() : null;
563| if ($head instanceof Company && (int) $head->getId() !== (int) $company->getId()) {
564| $headEntity = $this->em->getRepository(SsmaOccurrenceTypeConfig::class)
565| ->findOneBy(['company' => $head]);
566| if ($headEntity instanceof SsmaOccurrenceTypeConfig) {
567| $headData = $headEntity->getTypesData();
568| $masterLocations = $this->normalizeLocationsList(
569| is_array($headData) ? ($headData['locations'] ?? []) : []
570| );
571| }
572| }
573|
574| $inherited = false;
575| if ($masterLocations !== []) {
576| if ($ownLocations === []) {
577| $locations = $masterLocations;
578| $inherited = true;
579| } else {
580| $locations = $this->normalizeLocationsList(array_merge($masterLocations, $ownLocations));
581| $inherited = true;
582| }
583| } else {
584| $locations = $ownLocations;
585| }
586|
587| if ($hasSelectedKey) {
588| $selected = $this->normalizeSelectedLocations($stored['selected_locations'] ?? [], $locations);
589| } else {
590| $selected = $locations;
591| }
592|
593| return [
594| 'locations' => $locations,
595| 'selected_locations' => $selected,
596| 'inherited' => $inherited,
597| 'master_locations' => $masterLocations,
598| ];
599| }
600|
601| /** @param mixed $selected @param list<string> $locations @return list<string> */
602| private function normalizeSelectedLocations(mixed $selected, array $locations): array
603| {
604| if (!is_array($selected)) {
605| return [];
606| }
607|
608| $list = [];
609| foreach ($selected as $item) {
610| $value = is_string($item) || is_numeric($item)
611| ? trim((string) $item)
612| : (is_array($item) ? trim((string) ($item['label'] ?? $item['name'] ?? $item['value'] ?? '')) : '');
613| if ($value !== '' && in_array($value, $locations, true) && !in_array($value, $list, true)) {
614| $list[] = $value;
615| }
616| }
617|
618| return array_values($list);
619| }
620|
621| /**
622| * Locais que devem aparecer no select do registro (selected ∩ catálogo).
623| *
624| * @return list<string>
625| */
626| public function getVisibleLocations(Company $company): array
627| {
628| $cfg = $this->getTypesForFrontend($company);
629|
630| return array_values(array_filter(
631| is_array($cfg['selected_locations'] ?? null) ? $cfg['selected_locations'] : [],
632| static fn ($v): bool => is_string($v) && $v !== ''
633| ));
634| }
635|
636| /**
637| * Mapa aprofundamento: occurrenceTypeKey → CompanyTeam.id
638| *
639| * @return array<string, int> e.g. ['ACIDENTE_PESSOAL' => 5, 'ACIDENTE_AMBIENTAL' => 7]
640| */
641| public function getAprofundamentoMap(Company $company): array
642| {
643| $entity = $this->findOrCreateEntity($company);
644| $stored = $entity->getTypesData();
645| $raw = $stored['aprofundamento_map'] ?? [];
646| if (!is_array($raw)) {
647| return [];
648| }
649| $out = [];
650| foreach ($raw as $typeKey => $teamId) {
651| if (is_string($typeKey) && $typeKey !== '' && is_numeric($teamId) && (int) $teamId > 0) {
652| $out[$typeKey] = (int) $teamId;
653| }
654| }
655|
656| return $out;
657| }
658|
659| /**
660| * @param array<string, int> $map ['ACIDENTE_PESSOAL' => teamId, ...]
661| */
662| public function saveAprofundamentoMap(Company $company, array $map): void
663| {
664| $entity = $this->findOrCreateEntity($company);
665| $stored = $entity->getTypesData();
666|
667| $normalized = [];
668| foreach ($map as $typeKey => $teamId) {
669| if (is_string($typeKey) && $typeKey !== '' && is_numeric($teamId) && (int) $teamId > 0) {
670| $normalized[$typeKey] = (int) $teamId;
671| }
672| }
673|
674| $stored['aprofundamento_map'] = $normalized;
675| $entity->setTypesData($stored);
676| $this->em->flush();
677| }
678|
679| /**
680| * Flags "pode descaracterizar" por grupo de aprofundamento.
681| * Chave composta: "team:{id}" ou "tag:{id}" → lista de memberIds.
682| *
683| * @return list<int>
684| */
685| public function getAprofundamentoDescaracterMemberIds(Company $company, string $groupKind, int $groupId): array
686| {
687| $entity = $this->findOrCreateEntity($company);
688| $stored = $entity->getTypesData();
689| $raw = $stored['aprofundamento_descaracter'] ?? [];
690| if (!is_array($raw)) {
691| return [];
692| }
693| $key = $this->aprofundamentoDescaracterKey($groupKind, $groupId);
694| $ids = $raw[$key] ?? [];
695| if (!is_array($ids)) {
696| return [];
697| }
698|
699| return array_values(array_unique(array_filter(array_map('intval', $ids), static fn (int $id): bool => $id > 0)));
700| }
file_read
Show Details
Arguments
{"end_line": 24380, "file_path": "src/Controller/SsmaController.php", "start_line": 24320}
Result
File: src/Controller/SsmaController.php (Total lines: 27765)
IS_TRUNCATED: false
LINE_RANGE: 24320-24380
24320| return $this->redirectToRoute('admin_ssma_index');
24321| }
24322|
24323| $team = $this->entityManager->find(CompanyTeam::class, $teamId);
24324| if (!$team || $team->getCompany()->getId() !== $company->getId()) {
24325| $this->addFlash('warning', 'Equipe não encontrada.');
24326| return $this->redirectToRoute('admin_ssma_index');
24327| }
24328|
24329| $viewData = $this->buildSsmaViewData();
24330|
24331| $companyMembers = $this->entityManager->getRepository(CompanyMembers::class)
24332| ->findBy(['company' => $company, 'isRemoved' => 0]);
24333|
24334| $companyTeams = $this->entityManager->getRepository(CompanyTeam::class)->findBy(['company' => $company]);
24335| $teamIdToName = [];
24336| foreach ($companyTeams as $ct) {
24337| $teamIdToName[(string) $ct->getId()] = Utf8MojibakeNormalizer::normalize((string) ($ct->getName() ?? ''));
24338| }
24339|
24340| $resolveFirstTeamName = static function (CompanyMembers $member, array $teamIdToName): string {
24341| $raw = $member->getTeams() ?? '';
24342| if ($raw === '') {
24343| return '';
24344| }
24345| foreach (array_map('trim', explode(',', $raw)) as $tid) {
24346| if ($tid !== '' && isset($teamIdToName[$tid])) {
24347| return $teamIdToName[$tid];
24348| }
24349| }
24350|
24351| return '';
24352| };
24353|
24354| $teamMembers = [];
24355| $descaracterIds = $this->ssmaOccurrenceTypeConfig->getAprofundamentoDescaracterMemberIds($company, 'team', $teamId);
24356| $descaracterSet = array_fill_keys($descaracterIds, true);
24357| foreach ($companyMembers as $m) {
24358| $teamsRaw = $m->getTeams() ?? '';
24359| if ($teamsRaw === '') {
24360| continue;
24361| }
24362| $memberTeamIds = array_map('trim', explode(',', $teamsRaw));
24363| if (!in_array((string) $teamId, $memberTeamIds, true)) {
24364| continue;
24365| }
24366| $memberUser = $m->getUser();
24367| $roleMember = $m->getRoleMember();
24368| $vinc = $this->ssmaMemberVinculoPresentation($m);
24369| $teamMembers[] = [
24370| 'id' => $m->getId(),
24371| 'name' => $this->ssmaMemberDisplayLabel($m),
24372| 'email' => $m->getEmail() ?? '',
24373| 'avatar' => $memberUser ? $memberUser->getAvatar() : null,
24374| 'cargo' => Utf8MojibakeNormalizer::normalize((string) ($roleMember ? $roleMember->getName() : ($m->getRole() ?? ''))),
24375| 'team_name' => Utf8MojibakeNormalizer::normalize((string) ($team->getName() ?? '')),
24376| 'vinculo' => $vinc['label'],
24377| 'vinculo_code' => $vinc['code'],
24378| 'clinica_apro' => $m->getSsmaAprofundamentoClinicaForTeam($teamId),
24379| 'can_descharacterize' => isset($descaracterSet[$m->getId()]),
24380| ];
Request #5
deepseek-v4-flash
P:28.73K C:547 CR:26.11K CW:0
4788ms
Reasoning
So the config supports 'team' and 'tag' group kinds for the descaracter flags. The old `memberCanDescharacterizeAccident` iterates ALL entries in `aprofundamento_descaracter` (both team and tag kinds) to determine if member can descaracterize. The new `memberCanDescharacterizeForType` only iterates tags of the specific type (via SsmaPermissionTag with occurrenceTypeKey == typeKey). This drops:
1. Team-level descaracter grants (via 'team' group kind).
2. Non-tag-based / other tags? Actually new only considers tags with occurrenceTypeKey==type. But if a tag has null occurrenceTypeKey, the old code would grant if the member is listed for that tag. New code won't.
Now, is the UI-gating new flag vs server write gate discrepancy critical? Let me check where `applySsmaDescaracterPermissionGate` is used vs the templates. The write gate (server) still uses `ssmaMemberCanDescharacterizeAccident` at line 27415. That gate allows ROLE_SUPER_ADMIN, ROLE_MANAGER, Gestor Administrador, and any member listed in any group (tag or team).
Now consider the UI rendering. In detail view, the `ssmaCanDescharacterizeAccident` flag was previously computed via `ssmaMemberCanDescharacterizeAccident($company, $currentMemberForExport)` — this included ROLE_SUPER_ADMIN/ROLE_MANAGER/gestor admin check plus the config. Now it's only derived from `ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']` which is new `memberCanDescharacterizeForType` per type. This new check does NOT include role-based grants nor team-level grants, and does not handle the case of a tag lacking `occurrenceTypeKey`? Actually a tag row presumably has occurrenceTypeKey field. Let's check the SsmaPermissionTag entity & repository FIXED_TECHNICAL_OCCURRENCE_KEYS.
Let me read SsmaPermissionTagRepository and the entity fields.
Tool Calls (2)
file_find
Show Details
Arguments
{"query_name": "SsmaPermissionTag"}
Result
migrations/Version20260510120000_AddSsmaPermissionTagTablesIfMissing.php src/Entity/SsmaPermissionTag.php src/Entity/SsmaPermissionTagMember.php src/Repository/SsmaPermissionTagRepository.php tests/Unit/Product/Ssma/SsmaPermissionTagRepositoryTest.php
code_search
Show Details
Arguments
{"search_text": "FIXED_TECHNICAL_OCCURRENCE_KEYS"}
Result
File: src/Controller/SsmaController.php
Match lines: 1
10538| $fullTechnicalAccessTypes = SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS;
File: src/Repository/SsmaPermissionTagRepository.php
Match lines: 3
18| public const FIXED_TECHNICAL_OCCURRENCE_KEYS = [
37| return $key !== null && $key !== '' && in_array($key, self::FIXED_TECHNICAL_OCCURRENCE_KEYS, true);
99| foreach (self::FIXED_TECHNICAL_OCCURRENCE_KEYS as $typeKey) {
File: src/Service/Ssma/SsmaOccurrenceTypeConfigService.php
Match lines: 1
768| foreach (SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS as $typeKey) {
Request #6
deepseek-v4-flash
P:29.57K C:161 CR:29.18K CW:0
2193ms
Tool Calls (2)
file_read
Show Details
Arguments
{"end_line": 120, "file_path": "src/Repository/SsmaPermissionTagRepository.php", "start_line": 1}
Result
File: src/Repository/SsmaPermissionTagRepository.php (Total lines: 125)
IS_TRUNCATED: false
LINE_RANGE: 1-120
1|<?php
2|
3|declare(strict_types=1);
4|
5|namespace App\Repository;
6|
7|use App\Entity\Company;
8|use App\Entity\SsmaPermissionTag;
9|use Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository;
10|use Doctrine\Persistence\ManagerRegistry;
11|
12|/**
13| * @extends ServiceEntityRepository<SsmaPermissionTag>
14| */
15|class SsmaPermissionTagRepository extends ServiceEntityRepository
16|{
17| /** Chaves de tipo — tags fixas de aprofundamento técnico (acidentes + ROS/Quase Acidente). */
18| public const FIXED_TECHNICAL_OCCURRENCE_KEYS = [
19| 'ACIDENTE_PESSOAL',
20| 'ACIDENTE_AMBIENTAL',
21| 'ACIDENTE_MATERIAL',
22| 'ROS',
23| 'QUASE_ACIDENTE',
24| ];
25|
26| /** @var array<string, array{name: string}> */
27| private const FIXED_TECHNICAL_TAG_DEFS = [
28| 'ACIDENTE_PESSOAL' => ['name' => 'Aprofundamento Acidente Pessoal'],
29| 'ACIDENTE_AMBIENTAL' => ['name' => 'Aprofundamento Acidente Ambiental'],
30| 'ACIDENTE_MATERIAL' => ['name' => 'Aprofundamento Acidente Material'],
31| 'ROS' => ['name' => 'Aprofundamento ROS'],
32| 'QUASE_ACIDENTE' => ['name' => 'Aprofundamento Quase Acidente'],
33| ];
34|
35| public static function isFixedTechnicalOccurrenceKey(?string $key): bool
36| {
37| return $key !== null && $key !== '' && in_array($key, self::FIXED_TECHNICAL_OCCURRENCE_KEYS, true);
38| }
39|
40| public function __construct(ManagerRegistry $registry)
41| {
42| parent::__construct($registry, SsmaPermissionTag::class);
43| }
44|
45| /**
46| * @return SsmaPermissionTag[]
47| */
48| public function findByCompanyOrdered(Company $company): array
49| {
50| return $this->createQueryBuilder('t')
51| ->where('t.company = :company')
52| ->setParameter('company', $company)
53| ->orderBy('t.createdAt', 'ASC')
54| ->getQuery()
55| ->getResult();
56| }
57|
58| public function toArray(SsmaPermissionTag $tag, array $allMembers = []): array
59| {
60| $memberIds = [];
61| $clinics = [];
62| foreach ($tag->getMemberLinks() as $link) {
63| $mid = $link->getCompanyMember()->getId();
64| $memberIds[] = $mid;
65| if ($link->getClinica() !== null && $link->getClinica() !== '') {
66| $clinics[(string) $mid] = $link->getClinica();
67| }
68| }
69|
70| $members = [];
71| if (!empty($allMembers)) {
72| foreach ($allMembers as $m) {
73| if (in_array($m['id'], $memberIds, true)) {
74| $members[] = $m;
75| }
76| }
77| }
78|
79| return [
80| 'id' => $tag->getId(),
81| 'name' => $tag->getName(),
82| 'occurrence_type_key' => $tag->getOccurrenceTypeKey(),
83| 'member_ids' => $memberIds,
84| 'members' => $members,
85| 'clinics' => $clinics,
86| ];
87| }
88|
89| /**
90| * Garante as tags fixas de aprofundamento técnico (acidentes + ROS/Quase Acidente), na ordem do Figma.
91| *
92| * @return SsmaPermissionTag[]
93| */
94| public function ensureFixedTechnicalTagsForCompany(Company $company): array
95| {
96| $em = $this->getEntityManager();
97| $out = [];
98| $needsFlush = false;
99| foreach (self::FIXED_TECHNICAL_OCCURRENCE_KEYS as $typeKey) {
100| $def = self::FIXED_TECHNICAL_TAG_DEFS[$typeKey] ?? ['name' => $typeKey];
101| $tag = $this->findOneBy([
102| 'company' => $company,
103| 'occurrenceTypeKey' => $typeKey,
104| ]);
105| if (!$tag instanceof SsmaPermissionTag) {
106| $tag = new SsmaPermissionTag();
107| $tag->setCompany($company);
108| $tag->setOccurrenceTypeKey($typeKey);
109| $tag->setName($def['name']);
110| $em->persist($tag);
111| $needsFlush = true;
112| } elseif ($tag->getName() !== $def['name']) {
113| $tag->setName($def['name']);
114| $needsFlush = true;
115| }
116| $out[] = $tag;
117| }
118| if ($needsFlush) {
119| $em->flush();
120| }
file_read
Show Details
Arguments
{"end_line": 200, "file_path": "src/Entity/SsmaPermissionTag.php", "start_line": 1}
Result
File: src/Entity/SsmaPermissionTag.php (Total lines: 117)
IS_TRUNCATED: false
LINE_RANGE: 1-117
1|<?php
2|
3|declare(strict_types=1);
4|
5|namespace App\Entity;
6|
7|use Doctrine\Common\Collections\ArrayCollection;
8|use Doctrine\Common\Collections\Collection;
9|use Doctrine\ORM\Mapping as ORM;
10|
11|/**
12| * Tag de permissão técnica do SSMA — define quem pode atuar num tipo de acidente.
13| * Independente de CompanyTeam; gerenciada exclusivamente pelo módulo SSMA.
14| *
15| * @ORM\Entity(repositoryClass="App\Repository\SsmaPermissionTagRepository")
16| * @ORM\Table(name="ssma_permission_tag")
17| * @ORM\HasLifecycleCallbacks
18| */
19|class SsmaPermissionTag
20|{
21| /**
22| * @ORM\Id
23| * @ORM\GeneratedValue
24| * @ORM\Column(type="integer")
25| */
26| private ?int $id = null;
27|
28| /**
29| * @ORM\ManyToOne(targetEntity=Company::class)
30| * @ORM\JoinColumn(nullable=false, onDelete="CASCADE")
31| */
32| private Company $company;
33|
34| /**
35| * @ORM\Column(type="string", length=255)
36| */
37| private string $name = '';
38|
39| /**
40| * Chave do tipo de ocorrência vinculado (ex.: "ACIDENTE_PESSOAL").
41| *
42| * @ORM\Column(type="string", length=100, nullable=true)
43| */
44| private ?string $occurrenceTypeKey = null;
45|
46| /**
47| * @ORM\Column(type="datetime")
48| */
49| private \DateTimeInterface $createdAt;
50|
51| /**
52| * @ORM\OneToMany(
53| * targetEntity=SsmaPermissionTagMember::class,
54| * mappedBy="tag",
55| * cascade={"persist","remove"},
56| * orphanRemoval=true
57| * )
58| */
59| private Collection $memberLinks;
60|
61| public function __construct()
62| {
63| $this->memberLinks = new ArrayCollection();
64| $this->createdAt = new \DateTime();
65| }
66|
67| /** @ORM\PrePersist */
68| public function onPrePersist(): void
69| {
70| if (!isset($this->createdAt)) {
71| $this->createdAt = new \DateTime();
72| }
73| }
74|
75| public function getId(): ?int { return $this->id; }
76|
77| public function getCompany(): Company { return $this->company; }
78| public function setCompany(Company $company): self { $this->company = $company; return $this; }
79|
80| public function getName(): string { return $this->name; }
81| public function setName(string $name): self { $this->name = trim($name); return $this; }
82|
83| public function getOccurrenceTypeKey(): ?string { return $this->occurrenceTypeKey; }
84| public function setOccurrenceTypeKey(?string $key): self { $this->occurrenceTypeKey = $key; return $this; }
85|
86| public function getCreatedAt(): \DateTimeInterface { return $this->createdAt; }
87|
88| /** @return Collection<int, SsmaPermissionTagMember> */
89| public function getMemberLinks(): Collection { return $this->memberLinks; }
90|
91| public function addMemberLink(SsmaPermissionTagMember $link): self
92| {
93| if (!$this->memberLinks->contains($link)) {
94| $this->memberLinks->add($link);
95| $link->setTag($this);
96| }
97| return $this;
98| }
99|
100| public function removeMemberLink(SsmaPermissionTagMember $link): self
101| {
102| $this->memberLinks->removeElement($link);
103| return $this;
104| }
105|
106| /** @return CompanyMembers[] */
107| public function getMembers(): array
108| {
109| $out = [];
110| foreach ($this->memberLinks as $link) {
111| $m = $link->getCompanyMember();
112| if ($m) { $out[] = $m; }
113| }
114| return $out;
115| }
116|}
117|
Request #7
deepseek-v4-flash
P:32.2K C:396 CR:29.7K CW:0
3314ms
Reasoning
Interesting: `occurrenceTypeKey` is nullable. And the tag `memberLinks` is a OneToMany from `SsmaPermissionTagMember`. But the new code `memberCanDescharacterizeForType` uses `getAprofundamentoDescaracterMemberIds($company, 'tag', $tagId)` which reads from the `SsmaOccurrenceTypeConfig` entity's `aprofundamento_descaracter` raw JSON — i.e., the "Descaracterizar" column config (coluna descaracterizar) on the tag row of the config page, not the tag membership. Wait — the config in `SsmaOccurrenceTypeConfig` (types_data -> aprofundamento_descaracter -> "tag:{id}" => memberIds). Hmm. But tags have memberLinks to tag members. So there are two concepts:
- Tag members: members assigned to the tag (via SsmaPermissionTagMember).
- Descaracter column: extra members configured with the "Descaracterizar" flag on the tag (in the aprofundamento config UI?).
Let me examine how the "coluna Descaracterizar" config is set. Look at the controller lines 24503 & 24355 context. Let me read around 24450-24530.
Tool Calls (2)
file_read
Show Details
Arguments
{"end_line": 24530, "file_path": "src/Controller/SsmaController.php", "start_line": 24440}
Result
File: src/Controller/SsmaController.php (Total lines: 27765)
IS_TRUNCATED: false
LINE_RANGE: 24440-24530
24440| return new JsonResponse(['success' => false, 'message' => 'Tag não encontrada.'], 404);
24441| }
24442|
24443| if (SsmaPermissionTagRepository::isFixedTechnicalOccurrenceKey($tag->getOccurrenceTypeKey())) {
24444| return new JsonResponse([
24445| 'success' => false,
24446| 'message' => 'Esta tag de aprofundamento técnico é fixa e não pode ser excluída.',
24447| ], 422);
24448| }
24449|
24450| $this->entityManager->remove($tag);
24451| $this->entityManager->flush();
24452|
24453| return new JsonResponse(['success' => true]);
24454| }
24455|
24456| /** GET /manager/ssma/permission-tags/{tagId} — exibe detalhes de uma tag */
24457| public function permissionTagView(int $tagId): Response
24458| {
24459| /** @var User|null $user */
24460| $user = $this->getUser();
24461| if (!$user) {
24462| return $this->redirectToRoute('app_login');
24463| }
24464| $company = $user->getCompany();
24465| if (!$company) {
24466| $this->addFlash('warning', 'Empresa não encontrada.');
24467| return $this->redirectToRoute('admin_ssma_index');
24468| }
24469|
24470| $tag = $this->entityManager->find(SsmaPermissionTag::class, $tagId);
24471| if (!$tag || $tag->getCompany()->getId() !== $company->getId()) {
24472| $this->addFlash('warning', 'Tag de permissão não encontrada.');
24473| return $this->redirectToRoute('admin_ssma_index');
24474| }
24475|
24476| $viewData = $this->buildSsmaViewData();
24477|
24478| $companyMembers = $this->entityManager->getRepository(CompanyMembers::class)
24479| ->findBy(['company' => $company, 'isRemoved' => 0]);
24480|
24481| $companyTeams = $this->entityManager->getRepository(CompanyTeam::class)->findBy(['company' => $company]);
24482| $teamIdToName = [];
24483| foreach ($companyTeams as $ct) {
24484| $teamIdToName[(string) $ct->getId()] = Utf8MojibakeNormalizer::normalize((string) ($ct->getName() ?? ''));
24485| }
24486|
24487| $resolveFirstTeamName = static function (CompanyMembers $member, array $teamIdToName): string {
24488| $raw = $member->getTeams() ?? '';
24489| if ($raw === '') { return ''; }
24490| foreach (array_map('trim', explode(',', $raw)) as $tid) {
24491| if ($tid !== '' && isset($teamIdToName[$tid])) { return $teamIdToName[$tid]; }
24492| }
24493| return '';
24494| };
24495|
24496| // Membros vinculados ?? tag (via SsmaPermissionTagMember)
24497| $linksByMemberId = [];
24498| foreach ($tag->getMemberLinks() as $link) {
24499| $linksByMemberId[$link->getCompanyMember()->getId()] = $link;
24500| }
24501|
24502| $grupoMembers = [];
24503| $descaracterIds = $this->ssmaOccurrenceTypeConfig->getAprofundamentoDescaracterMemberIds($company, 'tag', $tagId);
24504| $descaracterSet = array_fill_keys($descaracterIds, true);
24505| foreach ($companyMembers as $m) {
24506| if (!isset($linksByMemberId[$m->getId()])) { continue; }
24507| $link = $linksByMemberId[$m->getId()];
24508| $memberUser = $m->getUser();
24509| $roleMember = $m->getRoleMember();
24510| $vinc = $this->ssmaMemberVinculoPresentation($m);
24511| $grupoMembers[] = [
24512| 'id' => $m->getId(),
24513| 'name' => $this->ssmaMemberDisplayLabel($m),
24514| 'email' => $m->getEmail() ?? '',
24515| 'avatar' => $memberUser ? $memberUser->getAvatar() : null,
24516| 'cargo' => Utf8MojibakeNormalizer::normalize((string) ($roleMember ? $roleMember->getName() : ($m->getRole() ?? ''))),
24517| 'team_name' => $resolveFirstTeamName($m, $teamIdToName),
24518| 'vinculo' => $vinc['label'],
24519| 'vinculo_code' => $vinc['code'],
24520| 'clinica_apro' => $link->getClinica() ?? '',
24521| 'can_descharacterize' => isset($descaracterSet[$m->getId()]),
24522| ];
24523| }
24524|
24525| $allMembersForModal = [];
24526| foreach ($companyMembers as $m) {
24527| $memberUser = $m->getUser();
24528| if ($this->isSsmaExcludedTenantAdminUser($memberUser)) {
24529| continue;
24530| }
code_search
Show Details
Arguments
{"search_text": "aprofundamentoDescaracterKey"}
Result
File: src/Service/Ssma/SsmaOccurrenceTypeConfigService.php Match lines: 3 693| $key = $this->aprofundamentoDescaracterKey($groupKind, $groupId); 715| $key = $this->aprofundamentoDescaracterKey($groupKind, $groupId); 1051| private function aprofundamentoDescaracterKey(string $groupKind, int $groupId): string
Request #8
deepseek-v4-flash
P:34.07K C:962 CR:32.51K CW:0
8309ms
Reasoning
So the "Descaracterizar" column is configured per group (tag or team) via `aprofundamento_descaracter` in `SsmaOccurrenceTypeConfig`'s types_data. The old check `memberCanDescharacterizeAccident` iterates the entire structure and grants any member anywhere (in both tag-based and team-based group lists).
The new per-type method only considers tag groups that are mapped to the type key. And note: whether the tag exists. But also, the old code did not consider whether the config entries corresponded to tags whose `occurrenceTypeKey` matches; the config entries are keyed by groupId+kind only (e.g. "tag:5", "team:3"). The new code filters tags via DB repository by company + occurrenceTypeKey == type, then checks "tag:{tagId}" entries.
So the semantic change: In the old flow, member X who has the descaracter flag on team 3 (via "team:3") OR on tag for AP is granted. In the new flow, for the UI flag, X only granted if on a tag of that type. Also the super-admin/manager/gestor admin role bypass has been dropped in the new UI flag.
But wait — I need to understand how the UI used the flag `ssmaCanDescharacterizeAccident` before this PR and what role the templates/JS play. The requirement rules for templates and `_modal_event.html.twig` note that UI permission flags etc.
The JS part of this PR is likely the biggest issue. Let me examine the `_modal_event.html.twig` diff changes in full. We saw the diff above. Let me focus on the global hidden fields.
`ev_descaracter_suspect` is the checkbox global element, `ev_descaracterizado` hidden field. In the payload construction `evApplyTypeDescaracterPayload(payload, type)` writes `payload.descaracter_suspect`, `payload.descaracterizado`, `payload.descaracter_comment` from the type-specific root BUT uses the GLOBAL `ev_descaracterizado` hidden field value for all types! That means whichever type the payload being saved, it reads the global `ev_descaracterizado` value, not per-type Sim/Não.
The type-specific UI has its own buttons `ev-type-desc-btn` with data-descaracter-val; clicking one writes to global hidden `ev_descaracterizado`. So only one global Sim/Não across all types. If the user has multiple types with different descaracter statuses? Typically a single occurrence is of one type, so maybe only one type block is shown at a time. But the requirement text says each type (ROS, QA, acidente material, etc.) gets its own block in the same modal (all present in DOM but only visible depending on the event type being created/edited). So only one root is active at a time per occurrence since type is fixed per occurrence. In practice then it's fine-ish.
But wait — what about ACIDENTE_PESSOAL? For personal accident, they did NOT add `evApplyTypeDescaracterPayload(payload, 'ACIDENTE_PESSOAL')`. Let's check: In the diff, for ACIDENTE_PESSOAL branch, no new call added. Because `_ev_injured_person_box.html.twig` continues to use `ev-inj-suspect-chk` handling separately (existing). But they gated the whole injured person descaracter block on `ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']`.
Let me read the actual current content around the injured person box and the payload assembly to understand how descaracter fields are sent for AP. Let's read `_ev_injured_person_box.html.twig` and surrounding part of `_modal_event.html.twig` for AP payload.
Tool Calls (2)
file_read
Show Details
Arguments
{"end_line": 240, "file_path": "templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig", "start_line": 120}
Result
File: templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig (Total lines: 227)
IS_TRUNCATED: false
LINE_RANGE: 120-227
120| <option value="CRITICA">Crítica</option>
121| </select>
122| </div>
123| </div>
124| </div>
125|
126| <div class="ev-inj-body-map-slot"></div>
127|
128| <div class="form-row mt-2 ev-inj-cat-row">
129| <div class="col-6">
130| <div class="form-group ev-inj-classification-row">
131| <label>Classificação de Ocorrência <span class="text-danger">*</span></label>
132| <select class="form-control ev-inj-injury-classification">
133| <option value="" disabled selected>Selecione</option>
134| <option value="FAC" data-leave="NAO">FAC — Primeiros socorros</option>
135| <option value="MTC" data-leave="NAO">MTC — Tratamento médico</option>
136| <option value="RWC" data-leave="NAO">RWC — Trabalho restrito</option>
137| <option value="FAT" data-leave="TOTAL">FAT — Fatalidade</option>
138| <option value="LTI_INCAPACITANTE" data-leave="TOTAL">LTI — Afastamento</option>
139| <option value="LTI_FATALIDADE" data-leave="TOTAL" class="d-none">LTI — Fatalidade (legado)</option>
140| <option value="LTI" data-leave="TOTAL" class="d-none">LTI — Afastamento (legado)</option>
141| </select>
142| </div>
143| </div>
144| <div class="col-6">
145| <div class="form-group">
146| <label>Tipo de CAT</label>
147| <select class="form-control ev-inj-work-leave" disabled aria-readonly="true" tabindex="-1">
148| <option value="">Selecione a classificação</option>
149| <option value="NAO">Sem afastamento</option>
150| <option value="TOTAL">Com afastamento</option>
151| </select>
152| </div>
153| </div>
154| </div>
155|
156| <div class="form-row ev-inj-consequence-row d-none" aria-hidden="true">
157| <div class="col-6">
158| <div class="form-group mb-2">
159| <label>Consequência real <span class="text-danger">*</span></label>
160| <select class="form-control ev-inj-consequence">
161| <option value="" disabled selected>Selecione a consequência</option>
162| {% include 'ssma/occurrence/partials/_ev_consequence_options.html.twig' %}
163| </select>
164| <div class="ev-inj-derived-severity-wrap mt-2">
165| <label class="text-muted small d-block mb-1">Gravidade da ocorrência (automática)</label>
166| <span class="ev-inj-derived-severity-badge ssma-shared-tag"
167| style="background:rgba(108,117,125,0.10);color:#6c757d;border-color:#adb5bd;">—</span>
168| </div>
169| </div>
170| </div>
171| <div class="col-6">
172| <div class="form-group mb-2">
173| <label>Consequência potencial <span class="text-danger">*</span></label>
174| <select class="form-control ev-inj-potential-consequence">
175| <option value="" disabled selected>Selecione a consequência</option>
176| {% include 'ssma/occurrence/partials/_ev_consequence_options.html.twig' %}
177| </select>
178| </div>
179| </div>
180| </div>
181|
182| {# CAT eSocial — exibido quando integração estiver ativa #}
183| <div class="ev-inj-esocial-cat-wrap d-none mt-2 p-2 rounded border">
184| <div class="small font-weight-bold mb-1">Registro da CAT no eSocial (automático)</div>
185| <div class="ev-inj-esocial-cat-body small text-muted">—</div>
186| </div>
187| </div>
188|
189| <p class="small text-muted font-italic mb-0 mt-2">Oriente o profissional a anexar evidências (fotos, laudos) na etapa de registro, se aplicável.</p>
190|
191| {# Só renderiza se a coluna Descaracterizar estiver marcada na tag de Acidente Pessoal. #}
192| {% if ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']|default(false) %}
193| <div class="ev-inj-descaracter mt-3 pt-3 border-top d-none">
194| <div class="form-check mb-2">
195| <input class="form-check-input ev-inj-suspect-chk" type="checkbox">
196| <label class="form-check-label font-weight-bold">Há suspeita de descaracterização do acidente?</label>
197| </div>
198| <div class="ev-inj-descaracter-yesno-wrap d-none">
199| <label class="d-block small mb-2 font-weight-bold">
200| Caracterizado como acidente?
201| <i class="fas fa-info-circle text-muted ml-1 ev-inj-descaracter-tip"
202| style="cursor:help;font-size:12px;"
203| data-toggle="tooltip"
204| data-placement="top"
205| title="Sim = é acidente. Não (descaracterizar) só quem tem permissão na coluna Descaracterizar em Profissionais de Saúde."></i>
206| </label>
207| <div class="ev-inj-descaracter-toggle d-flex align-items-center mb-3" role="group" aria-label="Caracterizado como acidente">
208| <button type="button" class="mhs-btn-cancel ev-inj-descaracter-btn" data-descaracter-val="0" style="min-width:84px;">Sim</button>
209| <button type="button" class="mhs-btn-cancel ev-inj-descaracter-btn" data-descaracter-val="1" style="min-width:84px;">Não</button>
210| </div>
211| <div class="form-group mb-0 ev-inj-descaracter-comment-wrap">
212| <label class="small mb-1">Comentário <span class="text-danger">*</span></label>
213| <textarea class="form-control form-control-sm ev-inj-descaracter-comment"
214| rows="2"
215| maxlength="2000"></textarea>
216| </div>
217| <p class="ev-inj-descaracter-no-perm small text-muted mb-0 mt-2 d-none">
218| Sem permissão para descaracterizar o acidente.
219| Peça ao gestor que marque a coluna <strong>Descaracterizar</strong> em
220| Profissionais de Saúde (configuração de aprofundamento).
221| </p>
222| </div>
223| </div>
224| {% endif %}
225| </div>
226|</div>
227|
code_search
Show Details
Arguments
{"search_text": "ev-inj-suspect-chk"}
Result
File: templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig
Match lines: 1
195| <input class="form-check-input ev-inj-suspect-chk" type="checkbox">
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 3
2968| var suspChk = card.querySelector('.ev-inj-suspect-chk');
5808| if (!e.target || !e.target.classList.contains('ev-inj-suspect-chk')) return;
6558| var chk = card.querySelector('.ev-inj-suspect-chk');
Request #9
deepseek-v4-flash
P:37K C:297 CR:34.94K CW:0
2787ms
Reasoning
Now let me search the `_modal_event.html.twig` to find the "descaracterizado" references in JS to map the global fields and payload assembly. Let me look at where `ev_descaracterizado` appears, and the payload assembly for AP.
Let me read the areas of `_modal_event.html.twig` relevant: functions around evIsDescaracterSuspectChecked, evApplyTypeDescaracterPayload, handler registration, populate, and payload assembly around line 7039-7300.
Let me grep for `ev_descaracterizado`, `descaracter_comment`, `descaracter_suspect` in _modal_event.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "ev_descaracterizado", "file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"]}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 7
828| <input type="hidden" id="ev_descaracterizado" name="ev_descaracterizado" value="">
2648| var hidden = document.getElementById('ev_descaracterizado');
2940| var descVal = String((document.getElementById('ev_descaracterizado') || {}).value || '');
2977| var hidden = document.getElementById('ev_descaracterizado');
5796| var hidden = document.getElementById('ev_descaracterizado');
6567| evSetVal('ev_descaracterizado', descVal == null ? '' : String(descVal));
7192| descFromCard = String((document.getElementById('ev_descaracterizado') || {}).value || '');
code_search
Show Details
Arguments
{"search_text": "descaracter_comment", "file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"]}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 10
2218| descaracter_comment: (card.querySelector('.ev-inj-descaracter-comment') || {}).value || '',
2275| if (comm) comm.value = saved.descaracter_comment || '';
2944| if (commVal) payload.descaracter_comment = commVal;
6498| if (!seed.descaracter_comment && det.descaracter_comment) seed.descaracter_comment = det.descaracter_comment;
6554| if (comm) comm.value = det.descaracter_comment || data.descaracter_comment || '';
7068| delete payload.descaracter_comment;
7210| payload.descaracter_comment = descCommentFromCard
7211| || (primaryData && primaryData.descaracter_comment ? String(primaryData.descaracter_comment).trim() : '')
7214| delete payload.descaracter_comment;
7348| 'details.descaracter_comment': 'Comentário de caracterização',
Request #10
deepseek-v4-flash
P:37.74K C:151 CR:37.25K CW:0
2171ms
Reasoning
Let me look at the payload assembly around lines 7039-7300 and the AP branch which now must be handling per-card values. Let's read the modal file in the range around lines 7030-7300 plus lines 6440-6600.
Tool Calls (1)
file_read
Show Details
Arguments
{"end_line": 7300, "file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 7020}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 7020-7300
7020| payload.potential_consequence
7021| );
7022| if (derivedCrit) {
7023| payload.potential_severity = derivedCrit;
7024| }
7025| } else if (type === 'ROS') {
7026| // Campo já é a escala de gravidade (LEVE…CRITICO).
7027| var rosPc = (document.getElementById('ev_ros_potential_consequence') || { value: '' }).value;
7028| var rosSev = evResolvePotentialSeverity(rosPc);
7029| if (rosSev) payload.potential_severity = rosSev;
7030| } else if (type === 'QUASE_ACIDENTE') {
7031| var qaPc = (document.getElementById('ev_qa_potential_consequence') || { value: '' }).value;
7032| var qaCrit = evResolvePotentialSeverity(
7033| qaPc,
7034| (document.getElementById('ev_criticality') || {}).value
7035| );
7036| if (qaCrit) payload.potential_severity = qaCrit;
7037| } else {
7038| var critEl = document.getElementById('ev_criticality');
7039| if (critEl && critEl.value) {
7040| payload.potential_severity = evResolvePotentialSeverity(critEl.value) || critEl.value;
7041| }
7042| }
7043|
7044| if (evRequiresAprofundamento(type)) {
7045| payload.corrective_actions = evCollectCorrectiveActions();
7046| }
7047|
7048| // Marca 2ª etapa: backend exige campos técnicos só quando o médico finaliza o Aprofundamento.
7049| if (evCurrentStep === 'aprofundamento' && evAprofundamentoOnlyMode) {
7050| payload.aprofundamento_only = true;
7051| payload.aprofundamento_complete = !!finalizeAprofundamento;
7052| payload.aprofundamento_status = finalizeAprofundamento ? 'finalized' : 'draft';
7053| }
7054|
7055| // Etapa 1 de acidentes: não envia campos técnicos vazios (evita disparar validação da 2ª etapa).
7056| if (
7057| (type === 'ACIDENTE_PESSOAL' || type === 'ACIDENTE_MATERIAL' || type === 'ACIDENTE_AMBIENTAL')
7058| && evCurrentStep !== 'aprofundamento'
7059| && !evCanEditAprofundamento(type)
7060| ) {
7061| payload.consequence = '';
7062| payload.potential_consequence = '';
7063| delete payload.potential_severity;
7064| delete payload.injury_type;
7065| delete payload.injury_classification;
7066| delete payload.injury_severity;
7067| delete payload.descaracterizado;
7068| delete payload.descaracter_comment;
7069| delete payload.body_parts;
7070| delete payload.strategic_nature;
7071| delete payload.corrective_actions;
7072| delete payload.asset_type;
7073| delete payload.failed_barrier;
7074| delete payload.barrier_type;
7075| delete payload.environmental_medium;
7076| delete payload.pollutant_type;
7077| }
7078|
7079| if (mode === 'edit') {
7080| payload.status = document.getElementById('ev_status').value;
7081| } else {
7082| var stEl = document.getElementById('ev_status');
7083| payload.status = (stEl && stEl.value) ? stEl.value : 'ABERTO';
7084| }
7085|
7086| // ROS "Visto e resolvido" = SIM: a ocorrência já nasce (ou é salva) como resolvida.
7087| if (type === 'ROS' && evIsRosResolvedChecked()) {
7088| payload.status = 'CONCLUIDO';
7089| }
7090|
7091| if (type === 'ROS') {
7092| payload.deviation_type = document.getElementById('ev_deviation_type').value;
7093| payload.involvement_type = document.getElementById('ev_involvement_type_ros').value;
7094| // Consequência potencial = escala de gravidade; gravamos em potential_severity.
7095| // Mantém potential_consequence vazio para não conflitar com EventConsequenceEnum.
7096| payload.potential_consequence = '';
7097| payload.immediate_risk = document.getElementById('ev_immediate_risk').checked ? 1 : 0;
7098| payload.barrier_type = (document.getElementById('ev_barrier_type_ros') || { value: '' }).value;
7099| delete payload.failed_barrier;
7100| delete payload.failed_barrier_other;
7101| payload.improvement_suggestions = (document.getElementById('ev_improvement_suggestions') || { value: '' }).value;
7102| payload.ros_resolved = (document.getElementById('ev_ros_resolved') || {}).checked ? 1 : 0;
7103| payload.ros_resolution_notes = payload.ros_resolved
7104| ? ((document.getElementById('ev_ros_resolution_notes') || { value: '' }).value || '')
7105| : '';
7106| payload.ros_resolution_evidences = payload.ros_resolved ? (evRosResolutionEvidences || []).slice() : [];
7107| payload.people_ids = '';
7108| evApplyTypeDescaracterPayload(payload, 'ROS');
7109| } else if (type === 'QUASE_ACIDENTE') {
7110| payload.involvement_type = document.getElementById('ev_involvement_type_qa').value;
7111| payload.barrier_type = (document.getElementById('ev_barrier_type_qa') || { value: '' }).value;
7112| delete payload.failed_barrier;
7113| payload.potential_consequence = (document.getElementById('ev_qa_potential_consequence') || { value: '' }).value;
7114| if (payload.involvement_type === 'PERSON') {
7115| payload.person_id = (document.getElementById('ev_person_id_qa') || { value: '' }).value;
7116| payload.person_type = (document.getElementById('ev_person_type_qa') || { value: '' }).value;
7117| }
7118| evApplyTypeDescaracterPayload(payload, 'QUASE_ACIDENTE');
7119| } else if (type === 'ACIDENTE_PESSOAL') {
7120| if (typeof evSyncInjuredCardsFromInvolved === 'function') {
7121| evSyncInjuredCardsFromInvolved();
7122| }
7123| evSyncInjuredPersonDetailsHidden();
7124| var primaryId = (typeof evGetPrimaryInjuredPersonId === 'function')
7125| ? evGetPrimaryInjuredPersonId()
7126| : '';
7127| if (!primaryId) {
7128| primaryId = evFirstPeopleInvolvedId(peopleIds);
7129| }
7130| payload.person_id = primaryId || (document.getElementById('ev_person_id') || { value: '' }).value;
7131| payload.person_type = (document.getElementById('ev_person_type') || { value: '' }).value || 'COLABORADOR';
7132| var detailsObj = (typeof evGetInjuredDetailsObj === 'function') ? evGetInjuredDetailsObj() : {};
7133| var primaryData = (primaryId && detailsObj[primaryId]) ? detailsObj[primaryId] : null;
7134| var primaryCard = (typeof evGetPrimaryInjuredCard === 'function') ? evGetPrimaryInjuredCard() : null;
7135| payload.consequence = primaryCard
7136| ? ((primaryCard.querySelector('.ev-inj-consequence') || {}).value || '')
7137| : ((primaryData && primaryData.consequence) || '');
7138| payload.potential_consequence = primaryCard
7139| ? ((primaryCard.querySelector('.ev-inj-potential-consequence') || {}).value || '')
7140| : ((primaryData && primaryData.potential_consequence) || '');
7141| var consequenceReal = payload.consequence;
7142| var apDerivedCrit = evResolvePotentialSeverity(
7143| consequenceReal,
7144| payload.potential_consequence,
7145| payload.potential_severity
7146| );
7147| if (apDerivedCrit) {
7148| payload.potential_severity = apDerivedCrit;
7149| }
7150| if (consequenceReal === 'SEM_DANO') {
7151| payload.had_injury = 0;
7152| payload.injury_type = '';
7153| payload.injury_severity = '';
7154| } else {
7155| var hadEl = primaryCard
7156| ? primaryCard.querySelector('.ev-inj-had-injury')
7157| : document.getElementById('ev_had_injury');
7158| payload.had_injury = hadEl
7159| ? (hadEl.checked ? 1 : 0)
7160| : (primaryData && primaryData.had_injury ? 1 : 0);
7161| if (payload.had_injury) {
7162| var typeFromCard = primaryCard
7163| ? ((primaryCard.querySelector('.ev-inj-injury-type') || {}).value || '')
7164| : '';
7165| var sevFromCard = primaryCard
7166| ? ((primaryCard.querySelector('.ev-inj-injury-severity') || {}).value || '')
7167| : '';
7168| payload.injury_type = (document.getElementById('ev_injury_type') || { value: '' }).value
7169| || typeFromCard
7170| || (primaryData && primaryData.injury_type) || '';
7171| payload.injury_severity = (document.getElementById('ev_injury_severity') || { value: '' }).value
7172| || sevFromCard
7173| || (primaryData && primaryData.injury_severity) || '';
7174| } else {
7175| payload.injury_type = '';
7176| payload.injury_severity = '';
7177| }
7178| }
7179| payload.injury_classification = (document.getElementById('ev_injury_classification') || { value: '' }).value
7180| || (primaryData && primaryData.injury_classification) || '';
7181| payload.work_leave = (document.getElementById('ev_work_leave') || { value: '' }).value
7182| || (primaryData && primaryData.work_leave) || '';
7183| payload.injured_person_details = (document.getElementById('ev_injured_person_details') || { value: '' }).value;
7184| var suspectEl = document.getElementById('ev_descaracter_suspect');
7185| var descFromCard = (primaryData && primaryData.descaracterizado !== undefined && primaryData.descaracterizado !== '')
7186| ? String(primaryData.descaracterizado)
7187| : '';
7188| if (!descFromCard && primaryCard) {
7189| descFromCard = String(primaryCard.getAttribute('data-descaracterizado') || '');
7190| }
7191| if (!descFromCard) {
7192| descFromCard = String((document.getElementById('ev_descaracterizado') || {}).value || '');
7193| }
7194| // Fallback: médico sem permissão de descaracterizar nunca pode marcar "Não",
7195| // então se todas as fontes estiverem vazias, assume "Sim" (é acidente = '0').
7196| if (!descFromCard && evAprofundamentoOnlyMode && !evCanDescharacterizeAccident()) {
7197| descFromCard = '0';
7198| }
7199| var descAnswered = descFromCard === '0' || descFromCard === '1';
7200| payload.descaracter_suspect = evIsDescaracterSuspectChecked() ? 1 : 0;
7201| // Caracterizar só o médico no aprofundamento dedicado.
7202| if (descAnswered && evAprofundamentoOnlyMode) {
7203| payload.descaracterizado = descFromCard;
7204| } else {
7205| delete payload.descaracterizado;
7206| }
7207| var descCommentFromCard = primaryCard
7208| ? String((primaryCard.querySelector('.ev-inj-descaracter-comment') || {}).value || '').trim()
7209| : '';
7210| payload.descaracter_comment = descCommentFromCard
7211| || (primaryData && primaryData.descaracter_comment ? String(primaryData.descaracter_comment).trim() : '')
7212| || '';
7213| if (!evAprofundamentoOnlyMode) {
7214| delete payload.descaracter_comment;
7215| }
7216| if (suspectEl) {
7217| suspectEl.checked = !!payload.descaracter_suspect;
7218| }
7219| if (payload.had_injury) {
7220| var bodyParts = (typeof evCollectActiveBodyParts === 'function')
7221| ? evCollectActiveBodyParts()
7222| : [];
7223| if (!bodyParts.length && primaryData && Array.isArray(primaryData.body_parts)) {
7224| bodyParts = primaryData.body_parts;
7225| }
7226| if (bodyParts.length) payload.body_parts = bodyParts;
7227| var bldEl = document.getElementById('ev_body_location_detail');
7228| var bld = bldEl && bldEl.value ? String(bldEl.value).trim() : '';
7229| if (!bld && primaryData && primaryData.body_location_detail) bld = primaryData.body_location_detail;
7230| if (bld) payload.body_location_detail = bld;
7231| }
7232| // Campo custo removido de AP (só AM possui custo)
7233| // payload.estimated_loss = (document.getElementById('ev_estimated_loss_ap') || { value: '' }).value;
7234| payload.barrier_type = (document.getElementById('ev_barrier_type_ap') || { value: '' }).value;
7235| delete payload.failed_barrier;
7236| delete payload.strategic_nature;
7237| var apSev = evResolvePotentialSeverity(
7238| payload.consequence,
7239| payload.potential_consequence,
7240| payload.potential_severity
7241| );
7242| if (apSev) payload.potential_severity = apSev;
7243| } else if (type === 'ACIDENTE_MATERIAL') {
7244| payload.asset_type = document.getElementById('ev_asset_type').value;
7245| payload.operational_impact = document.getElementById('ev_operational_impact').checked ? 1 : 0;
7246| payload.estimated_loss = document.getElementById('ev_estimated_loss').value;
7247| payload.downtime = document.getElementById('ev_downtime').value;
7248| payload.barrier_type = (document.getElementById('ev_barrier_type_am') || { value: '' }).value;
7249| delete payload.failed_barrier;
7250| delete payload.strategic_nature;
7251| var amSev = evResolvePotentialSeverity(
7252| payload.consequence,
7253| payload.potential_consequence,
7254| payload.potential_severity
7255| );
7256| if (amSev) payload.potential_severity = amSev;
7257| evApplyTypeDescaracterPayload(payload, 'ACIDENTE_MATERIAL');
7258| } else if (type === 'ACIDENTE_AMBIENTAL') {
7259| payload.environmental_medium = document.getElementById('ev_environmental_medium').value;
7260| payload.pollutant_type = document.getElementById('ev_pollutant_type').value;
7261| payload.estimated_volume = document.getElementById('ev_estimated_volume').value;
7262| payload.containment_done = document.getElementById('ev_containment_done').checked ? 1 : 0;
7263| payload.containment_time = document.getElementById('ev_containment_time').value;
7264| // Impacto externo removido do cadastro (Parte 1 C7) — mantém 0 se legado existir no payload.
7265| payload.external_impact = 0;
7266| payload.affected_area = document.getElementById('ev_affected_area').value;
7267| payload.barrier_type = (document.getElementById('ev_barrier_type_aa') || { value: '' }).value;
7268| delete payload.failed_barrier;
7269| delete payload.strategic_nature;
7270| var aaSev = evResolvePotentialSeverity(
7271| payload.consequence,
7272| payload.potential_consequence,
7273| payload.potential_severity
7274| );
7275| if (aaSev) payload.potential_severity = aaSev;
7276| evApplyTypeDescaracterPayload(payload, 'ACIDENTE_AMBIENTAL');
7277| }
7278|
7279| var evId = document.getElementById('ev_id').value;
7280| var url = mode === 'edit'
7281| ? EV_UPDATE_URL_TPL.replace('__EV_ID__', encodeURIComponent(String(evId)))
7282| : EV_CREATE_URL;
7283|
7284| if (window.SsmaShared && typeof window.SsmaShared.hasPendingEvidenceUploads === 'function') {
7285| if (window.SsmaShared.hasPendingEvidenceUploads('event') || window.SsmaShared.hasPendingEvidenceUploads('event-ros')) {
7286| var waitMsg = 'Aguarde o envio da evidência terminar antes de salvar.';
7287| if (typeof showToast === 'function') {
7288| showToast(waitMsg, 'Evidência', 'fas fa-hourglass-half', 'bg-warning');
7289| } else {
7290| alert(waitMsg);
7291| }
7292| return;
7293| }
7294| }
7295|
7296| function ssmaEventResponseLooksLikeLoginPage(strippedText) {
7297| var s = String(strippedText || '').toLowerCase();
7298| if (!s) return false;
7299| if (s.indexOf('por favor, entre') !== -1 || s.indexOf('entrar com a sua conta') !== -1) return true;
7300| if (s.indexOf('bem-vindo') !== -1 && (s.indexOf('senha') !== -1 || s.indexOf('e-mail') !== -1)) return true;
Request #11
deepseek-v4-flash
P:42.47K C:2.9K CR:37.89K CW:0
23473ms
Reasoning
Now, this is complex. I need to look at what templates actually pass `ssmaCanDescharacterizeByType`. In the payload assembly, for ACIDENTE_PESSOAL, the values are taken from primary card and global elements, gated by `evAprofundamentoOnlyMode` and by `evCanDescharacterizeAccident()`.
But there is a very important aspect: which variable is used? `ssmaCanDescharacterizeAccident` is a JS flag passed to the modal? Let me search in the modal template for `ssmaCanDescharacterizeAccident`.
Actually, this is about where the modal gets opened. Let me look at how the variables get into the JS. The Twig data attributes include `ssmaCanDescharacterizeAccident`, `ssmaCanDescharacterizeByType`. Let me check the top-level page script data.
Now, in terms of JS functions like `evCanDescharacterizeAccident`, `evIsDescaracterSuspectChecked`, etc., let me look more broadly. Actually wait — the review scope: We must provide concise, objective review feedback on the diff. I should not get lost in the full JS. But I need to determine actual issues.
The biggest functional risk that I can see from the diff concerns in the JS: they introduced `evApplyTypeDescaracterPayload(payload, type)` which reads the global hidden field `ev_descaracterizado` and writes `payload.descaracterizado` if it's '0' or '1', and writes `payload.descaracter_suspect` from the type root checkbox.
Now the server-side write gate (`applySsmaDescaracterPermissionGate`) uses `ssmaMemberCanDescharacterizeAccident` (old broad semantics with admin role). But now the JS payload sends the `descaracterizado` value for types ROS/QA/AM/AA based on the global `ev_descaracterizado` value. Actually wait, for ROS/QA/AM/AA they now send `descaracter_suspect`, `descaracterizado`, `descaracter_comment`. The server-side gate `applySsmaDescaracterPermissionGate` currently applies to ACIDENTE_PESSOAL presumably. Let me confirm where `applySsmaDescaracterPermissionGate` is invoked (which event types). If the gate is applied to all types, then the server would still enforce permission on the "descaracterizado" value. If the member doesn't have permission (old semantics), the server keeps existing value. Hmm.
But here's the crux for the per-type gating: If the UI hides the descaracter block entirely when `ssmaCanDescharacterizeByType[type]` is false, but the write gate uses old semantics (member with ROLE_SUPER_ADMIN would have permission server-side). With the new code, a ROLE_SUPER_ADMIN / ROLE_MANAGER / Gestor Administrador who isn't in the tag list (they may not have a CompanyMembers row at all, or a tag link) will now NOT see the block even though server previously allowed them to descaracterize. That's a functional regression in UI but not necessarily data corruption because server wouldn't corrupt data—rather the UI just won't let them access. For tenant/gestor admins, they were explicitly granted before by `ssmaMemberCanDescharacterizeAccident` role bypass. The new derived `ssmaCanDescharacterizeAccident` for them would be false (because `getDescharacterizeFlagsByType` only checks tags). So UI: the AP descaracter block hidden for admins; and for the AP payload, there's a fallback `descFromCard = '0'` for "médico sem permissão" — a "Sim" (is accident) default, which is harmless.
But there's another concern: admins who previously could legitimately mark "Não" (descaracterizar) can no longer do it because the block isn't rendered. This is a real functional regression for admin users. The comment/instruction in the removed block said suspeita editable by any specialist AP; Sim/Não only with permission. The new code hides everything when per-type flag false, which is a narrower rule. This is the intended change of the PR? Actually the PR goal is "implement descharacterization flags by type for occurrences" and "hotfix/permission-descaraterzacao-ssma" - the desired new behavior seems that only members with the tag of that type can descaracterize. But it drops the admin role bypass which was an intentional old rule (documented in comment above `ssmaMemberCanDescharacterizeAccident`: "liberado automaticamente para Gestor Administrador/Tenant").
Wait — actually is the controller's changed path used for both create and detail? The `ssmaCanDescharacterizeByType` is passed to both index and occurrence_view templates. So for the creation modal and edit, admins lose the ability to see the descaracter block for all types unless they're also configured in the type tag's descaracter column.
Hmm — but maybe the "coluna Descaracterizar" for tags (i.e., a tag with the descaracter flag) is separate from membership in the tag. Actually admin bypass seems plausible because when configuring, admins would mark themselves in the column.
Wait — but let me be more careful. Let's examine what happens in the modal opening, specifically around the "aprofundamento" only flow which is what this gating affects, since the descaracter fields for technical evaluation. This is relevant because `_ev_injured_person_box` gating applies to `ACIDENTE_PESSOAL`. But for occurrence detail view (aprofundamento), maybe admins use that page to fill the technical part.
Let me also consider the security angle: the requirement's "strict focus rules" say for templates & JS we should comment on actual issues.
The most significant issues I've found:
1. In the controller, the old `ssmaMemberCanDescharacterizeAccident` also granted the role bypass for super admin / manager / Gestor Administrador. The new computation no longer does — the new flags only consider tag membership. So for admin users, both `ssmaCanDescharacterizeByType[type]` and the derived `ssmaCanDescharacterizeAccident` become false (unless they are in the tag descaracter list). This is a **functional regression** for admins who previously could descaracterize. This deserves a high severity comment.
Also, the old semantics allowed members configured at the TEAM level (`getAprofundamentoDescaracterMemberIds($company, 'team', ...)`) — config in "Profissionais de Saúde" per team. Actually wait: In the config page, can the descaracter flag be set for a team? Look at controller usage at line 24355 for a team view and line 24503 for a tag view. The columns `can_descharacterize` exists in both team and tag membership pages. So the config (aprofundamento_descaracter raw) holds entries for both 'team' and 'tag' kinds. The old memberCanDescharacterizeAccident scans the whole raw map for the member id, so members flagged in a team context also get permission. The new per-type check only considers tag-based entries with the type's key, so team-flagged descaracter members lose ability for the UI as well.
Actually wait, let's reconsider whether the UI descaracterization for these types is what previously rendered based on `ssmaCanDescharacterizeAccident`. Yes, that flag was previously passed into the templates (unchanged usage) and computed with the role bypass + any group. Now it's computed from the new map for AP only. So the change narrows who can descaracterize in UI. This can cause regression of access to the descaracterization block for admin/manager roles, and also the derived flag is now duplicated logic in controller which is a side effect of moving semantics.
2. There is a mismatch between server write gate (old semantics `ssmaMemberCanDescharacterizeAccident`, applied in save path) and new UI visibility logic (per-type tag membership). Two different criteria could cause:
- UI hides block for someone who server would have allowed (regression of access; the person simply cannot input).
- UI shows block for someone who server will not allow (they can input but the server would scrub the value, e.g. an AP specialist that belongs to type's tag but no role...). Wait, is there a scenario where new UI flag is TRUE but server gate would be FALSE? The new UI flag true requires membership in the type tag's descaracter member ids list (member in config "tag:{id}"). The old server gate grants if member is in the whole config (any group). So if the new UI flag is true, the server gate is also true (since the raw structure contains tag:{id} list with that member). Except the role bypass is a super-set. So new true → old true. So no security issue where UI shows but server blocks. Actually the server gate also runs `isGranted('ROLE_SUPER_ADMIN')` etc. but if new UI flag is true, then old server also true. So no UI/server discrepancy in the direction of overgranting. But wait — what about the derived `ssmaCanDescharacterizeAccident` false for the "permission" gating in JS (e.g., `evCanDescharacterizeAccident()`)? That's the legacy JS fallback. Hmm.
Actually, there's a possible discrepancy: The write gate for ACIDENTE_PESSOAL checks `applySsmaDescaracterPermissionGate` with old logic. For admin roles the server permits writing descaracterizado. But the new UI doesn't show the block for admins, so they can't write it. That is the regression.
But does the JS block hide only on create flow? Let me check where the block is used in detail view. The `_ev_injured_person_box.html.twig` partial is included in the injured persons box. Let me confirm which context variables are available in the partial include at line 672 in `_modal_event.html.twig` — the include passes `ssmaCanDescharacterizeByType` now. Good.
3. JS bug potential in `evApplyTypeDescaracterPayload`: it reads the GLOBAL `ev_descaracterizado` value regardless of the type root. So if the user fills descaracter on ROS (Sim/Não = Não), then switches to ACIDENTE_MATERIAL and fills its own, the global ev_descaracterizado holds the last clicked value across all roots; saving the ROS after changing AM would pick AM's value. But in practice there is one occurrence type at a time in the modal... Actually can an occurrence have multiple types? In the same occurrence modal, `ev_spec_type` select defines which type block is shown. But these type blocks all share the same DOM. When editing an occurrence, its type is fixed, so only one root is visible/active. However the payload assembly path matches the same `type`, so the type being edited corresponds to one root. The global field is shared between ACIDENTE_PESSOAL handling (existing code uses global ev_descaracterizado) and new per-type roots. If someone edits an AP occurrence that has both ACIDENTE_PESSOAL root? No, AP doesn't include the new per-type block; it uses the injured person box. So the roots are ROS, QA, AM, AA. A single occurrence has one type. So sharing a global hidden is probably OK at runtime since only one type at a time.
BUT consider editing an occurrence from type ROS that previously stored descaracterizado='1', and the ROS root's Sim/Não buttons both being unmarked (they are toggle buttons). `evApplyTypeDescaracterPayload` reads global hidden which is set on click of buttons anywhere. It was initialized only for AP in `evSetVal('ev_descaracterizado', ...)` at line 6567, which is in the generic populate? Wait line 6567 `evSetVal('ev_descaracterizado', descVal == null ? '' : String(descVal));` — populate for AP cards. Let me read around line 6540-6580 to understand populate logic for the descaracter zone. Also line 2924-2945 where evIsDescaracterSuspectChecked and evApplyTypeDescaracterPayload. And 5779-5808 where the per-type root event binding is added. Let's read these segments.
Let me read relevant region: 2900-3010, 5760-5840, 6520-6600.
Tool Calls (2)
file_read
Show Details
Arguments
{"end_line": 3010, "file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 2915}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 2915-3010
2915| return true;
2916| } catch (e) {
2917| return false;
2918| }
2919| }
2920|
2921| function evCanDescharacterizeAccident() {
2922| return window.SSMA_CAN_DESCARACTERIZE === true || window.SSMA_CAN_DESCARACTERIZE === 'true';
2923| }
2924|
2925| function evIsDescaracterSuspectChecked() {
2926| var el = document.getElementById('ev_descaracter_suspect');
2927| if (el && el.checked) return true;
2928| return !!document.querySelector('.ev-type-descaracter-suspect:checked');
2929| }
2930|
2931| function evGetTypeDescaracterRoot(type) {
2932| return document.querySelector('[data-descaracter-root][data-descaracter-type="' + type + '"]');
2933| }
2934|
2935| function evApplyTypeDescaracterPayload(payload, type) {
2936| var root = evGetTypeDescaracterRoot(type);
2937| if (!root) return;
2938| var chk = root.querySelector('.ev-type-descaracter-suspect');
2939| payload.descaracter_suspect = chk && chk.checked ? 1 : 0;
2940| var descVal = String((document.getElementById('ev_descaracterizado') || {}).value || '');
2941| if (descVal === '0' || descVal === '1') payload.descaracterizado = descVal;
2942| var comm = root.querySelector('.ev-type-descaracter-comment');
2943| var commVal = comm ? String(comm.value || '').trim() : '';
2944| if (commVal) payload.descaracter_comment = commVal;
2945| }
2946|
2947| function evIsCreateMode() {
2948| return ((document.getElementById('ev_form_mode') || { value: 'create' }).value === 'create');
2949| }
2950|
2951| function evSyncDescaracterStageUi() {
2952| var isAp = evSelectedType() === 'ACIDENTE_PESSOAL';
2953| // Sim/Não aparece no passo aprofundamento (especialista only-mode OU admin em openEdit).
2954| var isDoctorAprof = !!evAprofundamentoOnlyMode || evCurrentStep === 'aprofundamento';
2955| var form = document.getElementById('form-event-new');
2956| if (form) form.classList.toggle('is-doctor-aprof', isDoctorAprof);
2957| // Checkbox global de suspeita (etapa 1) fica sempre oculto — suspeita agora é por card no aprofundamento.
2958| var suspectWrap = document.getElementById('ev-suspeita-wrap');
2959| if (suspectWrap) {
2960| suspectWrap.classList.add('d-none');
2961| }
2962| document.querySelectorAll('.ev-inj-descaracter').forEach(function (el) {
2963| // Seção de descaracterização só aparece no aprofundamento do especialista.
2964| el.classList.toggle('d-none', !isAp || !isDoctorAprof);
2965| });
2966| // Sincroniza Sim/Não de cada card com o estado do checkbox de suspeita do próprio card.
2967| document.querySelectorAll('.ev-injured-person-box').forEach(function (card) {
2968| var suspChk = card.querySelector('.ev-inj-suspect-chk');
2969| var yesNoWrap = card.querySelector('.ev-inj-descaracter-yesno-wrap');
2970| if (suspChk && yesNoWrap) {
2971| yesNoWrap.classList.toggle('d-none', !suspChk.checked);
2972| }
2973| });
2974| }
2975|
2976| function evSyncDescaracterUi() {
2977| var hidden = document.getElementById('ev_descaracterizado');
2978| var canSn = evCanDescharacterizeAccident();
2979| var cur = String((hidden || {}).value || '');
2980|
2981| evSyncDescaracterStageUi();
2982|
2983| // Pré-seleciona "Sim" quando o profissional não tem permissão de descaracterização
2984| // e o campo ainda está vazio. Ele só pode dizer "Sim" de qualquer forma, então
2985| // pré-preencher evita a validação falhar sem o usuário perceber o que falta.
2986| if (!canSn && cur === '' && evAprofundamentoOnlyMode && hidden) {
2987| hidden.value = '0';
2988| cur = '0';
2989| document.querySelectorAll('.ev-injured-person-box').forEach(function (c) {
2990| c.setAttribute('data-descaracterizado', '0');
2991| });
2992| }
2993|
2994| document.querySelectorAll('.ev-injured-person-box').forEach(function (card) {
2995| var noPerm = card.querySelector('.ev-inj-descaracter-no-perm');
2996| var cardDesc = card.getAttribute('data-descaracterizado') || cur;
2997| if (noPerm) noPerm.classList.toggle('d-none', canSn);
2998| card.querySelectorAll('.ev-inj-descaracter-btn').forEach(function (b) {
2999| var val = b.getAttribute('data-descaracter-val');
3000| // Sem permissão: "Não" fica visível mas desabilitado — o par Sim/Não precisa aparecer.
3001| if (val === '1' && !canSn) {
3002| b.disabled = true;
3003| b.classList.remove('d-none');
3004| b.setAttribute('title', 'Sem permissão para descaracterizar o acidente.');
3005| } else {
3006| b.disabled = false;
3007| b.classList.remove('d-none');
3008| b.removeAttribute('title');
3009| }
3010| });
file_read
Show Details
Arguments
{"end_line": 5845, "file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 5760}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 5760-5845
5760| if (potEl) {
5761| potEl.addEventListener('change', evPersistDraftSoon);
5762| }
5763| var derivedSel = document.getElementById('ev_derived_criticality_select');
5764| if (derivedSel) {
5765| derivedSel.addEventListener('change', function () {
5766| var hidden = document.getElementById('ev_derived_criticality');
5767| var critSel = document.getElementById('ev_criticality');
5768| if (hidden) hidden.value = this.value || '';
5769| if (critSel && this.value) critSel.value = this.value;
5770| evPersistDraftSoon();
5771| });
5772| }
5773| // Descaracterização: suspeita na 1ª etapa; caracterizado na caixinha (aprofundamento).
5774| var suspectChk = document.getElementById('ev_descaracter_suspect');
5775| if (suspectChk) {
5776| suspectChk.addEventListener('change', function () {
5777| evSyncDescaracterStageUi();
5778| evSyncInjuredPersonDetailsHidden();
5779| evPersistDraftSoon();
5780| });
5781| }
5782| document.querySelectorAll('[data-descaracter-root]').forEach(function (root) {
5783| var chk = root.querySelector('.ev-type-descaracter-suspect');
5784| var yesNo = root.querySelector('.ev-type-descaracter-yesno');
5785| if (chk && yesNo) {
5786| chk.addEventListener('change', function () {
5787| yesNo.classList.toggle('d-none', !chk.checked);
5788| var globalChk = document.getElementById('ev_descaracter_suspect');
5789| if (globalChk) globalChk.checked = chk.checked;
5790| evPersistDraftSoon();
5791| });
5792| }
5793| root.addEventListener('click', function (e) {
5794| var btn = e.target && e.target.closest ? e.target.closest('.ev-type-desc-btn') : null;
5795| if (!btn) return;
5796| var hidden = document.getElementById('ev_descaracterizado');
5797| if (hidden) hidden.value = btn.getAttribute('data-descaracter-val') || '';
5798| if (window.SsmaShared && typeof window.SsmaShared.toggleYesNo === 'function') {
5799| window.SsmaShared.toggleYesNo(root.querySelectorAll('.ev-type-desc-btn'), hidden ? hidden.value : null, {
5800| valueAttr: 'data-descaracter-val'
5801| });
5802| }
5803| evPersistDraftSoon();
5804| });
5805| });
5806| // Checkbox de suspeita por card (aprofundamento): mostra/oculta Sim/Não do próprio card.
5807| document.addEventListener('change', function (e) {
5808| if (!e.target || !e.target.classList.contains('ev-inj-suspect-chk')) return;
5809| var card = e.target.closest('.ev-injured-person-box');
5810| if (!card) return;
5811| var yesNoWrap = card.querySelector('.ev-inj-descaracter-yesno-wrap');
5812| if (yesNoWrap) yesNoWrap.classList.toggle('d-none', !e.target.checked);
5813| // Atualiza o data-descaracter-suspect do card para serialização.
5814| card.setAttribute('data-descaracter-suspect', e.target.checked ? '1' : '0');
5815| // Espelha no campo global usado pelo payload (evIsDescaracterSuspectChecked).
5816| var globalChk = document.getElementById('ev_descaracter_suspect');
5817| if (globalChk) globalChk.checked = e.target.checked;
5818| evSyncInjuredPersonDetailsHidden();
5819| evPersistDraftSoon();
5820| });
5821| var contDone = document.getElementById('ev_containment_done');
5822| if (contDone) {
5823| contDone.addEventListener('change', function () {
5824| evSyncContainmentTimeEnabled();
5825| evPersistDraftSoon();
5826| });
5827| }
5828| var form = document.getElementById('form-event-new');
5829| if (form) {
5830| form.addEventListener('change', evPersistDraftSoon);
5831| form.addEventListener('input', evPersistDraftSoon);
5832| }
5833| document.addEventListener('ev:formLoaded', function () {
5834| evSyncCriticalityField(evSelectedType());
5835| evSyncDerivedSeverityFromConsequence();
5836| evSyncInjuryTypeByConsequence();
5837| evSyncInjuryClassificationByLeave();
5838| if (typeof window.initAllCustomSelectWrappers === 'function') {
5839| window.initAllCustomSelectWrappers();
5840| }
5841| evFilterInjuredPersonSelect();
5842| evSyncDescaracterUi();
5843| evSyncContainmentTimeEnabled();
5844| });
5845| document.addEventListener('ev:peopleTagsChanged', function () {
Request #12
deepseek-v4-flash
P:48.15K C:194 CR:42.37K CW:0
2771ms
Reasoning
Let me look at populate (6520-6600) region.
Tool Calls (2)
file_read
Show Details
Arguments
{"end_line": 6620, "file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 6510}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 6510-6620
6510| } catch (eSeed) {}
6511| var injEl = document.getElementById('ev_injured_person_details');
6512| if (injEl) injEl.value = String(injRaw || '');
6513| var personSelSeed = document.getElementById('ev_person_id');
6514| if (personSelSeed && personIdForBox) {
6515| personSelSeed.setAttribute('data-primary-injured-id', String(personIdForBox));
6516| // Não deixa valor no select (select = adicionar); primary vai via data-attr.
6517| personSelSeed.value = '';
6518| if (typeof window.setCustomSelectValue === 'function') {
6519| window.setCustomSelectValue('ev_person_id', '');
6520| }
6521| }
6522| evFilterInjuredPersonSelect();
6523| evRenderInjuredPersonBoxes();
6524|
6525| if (type === 'ACIDENTE_PESSOAL') {
6526| // Re-sync depois das tags + details: garante caixinhas médicas mesmo se
6527| // setTagSelectValues rodou antes do hidden ou membro não estava no select.
6528| syncBodyRegionVisibility();
6529| evSyncInjuryFieldsByConsequence();
6530| if (typeof window.evSyncLtiAvailability === 'function') { window.evSyncLtiAvailability(); }
6531| evSyncInjuredCardsFromInvolved();
6532| // Se sync ainda não viu pessoas nas tags, remonta a partir dos details salvos.
6533| var wrapAfter = document.getElementById('ev_injured_person_boxes');
6534| var hasMedCards = !!(wrapAfter && wrapAfter.querySelector('.ev-injured-person-box[data-person-id]'));
6535| if (!hasMedCards && Object.keys(evGetInjuredDetailsObj() || {}).length) {
6536| evRenderInjuredPersonBoxes();
6537| }
6538| if (evCurrentStep === 'aprofundamento' && typeof evEnsurePrimaryInjuredCardExpanded === 'function') {
6539| evEnsurePrimaryInjuredCardExpanded();
6540| }
6541| }
6542|
6543| // ── Descaracterização ────────────────────────────────
6544| // Restaura suspeita por card a partir do det ou do injured_person_details do card primário.
6545| var suspectRaw = det.descaracter_suspect != null ? det.descaracter_suspect : data.descaracter_suspect;
6546| var suspectOn = suspectRaw === true || suspectRaw === 1 || suspectRaw === '1';
6547| evSetChk('ev_descaracter_suspect', suspectOn);
6548| document.querySelectorAll('[data-descaracter-root]').forEach(function (root) {
6549| var chk = root.querySelector('.ev-type-descaracter-suspect');
6550| if (chk) chk.checked = suspectOn;
6551| var yesNo = root.querySelector('.ev-type-descaracter-yesno');
6552| if (yesNo) yesNo.classList.toggle('d-none', !suspectOn);
6553| var comm = root.querySelector('.ev-type-descaracter-comment');
6554| if (comm) comm.value = det.descaracter_comment || data.descaracter_comment || '';
6555| });
6556| // Propaga suspeita para cada card (checkbox editável no aprofundamento).
6557| document.querySelectorAll('.ev-injured-person-box').forEach(function (card) {
6558| var chk = card.querySelector('.ev-inj-suspect-chk');
6559| if (chk) chk.checked = suspectOn;
6560| card.setAttribute('data-descaracter-suspect', suspectOn ? '1' : '0');
6561| var yesNoWrap = card.querySelector('.ev-inj-descaracter-yesno-wrap');
6562| if (yesNoWrap) yesNoWrap.classList.toggle('d-none', !suspectOn);
6563| });
6564| var descVal = det.descaracterizado != null ? det.descaracterizado : data.descaracterizado;
6565| if (descVal === true || descVal === 1) descVal = '1';
6566| if (descVal === false || descVal === 0) descVal = '0';
6567| evSetVal('ev_descaracterizado', descVal == null ? '' : String(descVal));
6568| evSyncDescaracterUi();
6569|
6570| // ── Evidências já anexadas ──────────────────────────
6571| var evidences = Array.isArray(det.evidences) ? det.evidences : (Array.isArray(data.evidences) ? data.evidences : []);
6572| evEvidences = evidences.map(function (e) {
6573| return {
6574| name: e.name || e.filename || '',
6575| path: e.path || '',
6576| persisted: true
6577| };
6578| });
6579| evEvidenceRenderList();
6580|
6581| // ── Labels do modal ─────────────────────────────────
6582| var btnLbl = document.getElementById('ev-btn-label');
6583| var modalTitle = document.getElementById('ev-modal-title');
6584| if (modalTitle) modalTitle.textContent = 'Editar ocorrência';
6585| evApplyAuraTitleStatusVisibility('edit');
6586| evSetStep('general');
6587| $('#ev_manager').trigger('change');
6588| };
6589|
6590| /**
6591| * Abre o offcanvas no aprofundamento (especialista).
6592| * Admin/gestor administrador edita tudo desde informações gerais — não trava o 1º passo.
6593| */
6594| window.EvModal.openAprofundamento = function (data) {
6595| data = data || {};
6596| var serverCanEditAprofundamento = (data._can_edit_aprofundamento === true || data._can_edit_aprofundamento === false)
6597| ? data._can_edit_aprofundamento
6598| : null;
6599| if (EV_IS_ADMIN_APROFUNDAMENTO && window.OccurrenceModal && typeof window.OccurrenceModal.openEdit === 'function') {
6600| window.OccurrenceModal.openEdit(data);
6601| return;
6602| }
6603| var EV_GET_URL = '{{ path('ssma_event_get', {id: '__EV_ID__'})|e('js') }}';
6604|
6605| function openWith(full) {
6606| full = full || data;
6607| if (serverCanEditAprofundamento !== null) {
6608| full._can_edit_aprofundamento = serverCanEditAprofundamento;
6609| }
6610| window.EvModal.populateForEdit(full);
6611| evAprofundamentoCanEditFromServer = (full._can_edit_aprofundamento === true || full._can_edit_aprofundamento === false)
6612| ? full._can_edit_aprofundamento
6613| : null;
6614| evAprofundamentoOnlyMode = true;
6615| evAprofundamentoFinalizeIntent = true;
6616| var modalTitle = document.getElementById('ev-modal-title');
6617| if (modalTitle) modalTitle.textContent = 'Aprofundamento técnico';
6618| if (typeof evEnsureCorrectiveActionsSeed === 'function') {
6619| evEnsureCorrectiveActionsSeed();
6620| }
file_read
Show Details
Arguments
{"end_line": 2280, "file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 2180}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 2180-2280
2180| function evAssignCanonicalInjuryIds(card) {
2181| if (!card) return;
2182| evClearCanonicalInjuryIds();
2183| var map = [
2184| ['.ev-inj-had-injury', EV_INJ_CANONICAL_IDS.had],
2185| ['.ev-inj-injury-type', EV_INJ_CANONICAL_IDS.type],
2186| ['.ev-inj-injury-severity', EV_INJ_CANONICAL_IDS.severity],
2187| ['.ev-inj-work-leave', EV_INJ_CANONICAL_IDS.leave],
2188| ['.ev-inj-injury-classification', EV_INJ_CANONICAL_IDS.classification]
2189| ];
2190| map.forEach(function (pair) {
2191| var el = card.querySelector(pair[0]);
2192| if (el) el.id = pair[1];
2193| });
2194| var had = card.querySelector('.ev-inj-had-injury');
2195| var hadLabel = had && had.closest('.form-check') ? had.closest('.form-check').querySelector('label') : null;
2196| if (had) {
2197| had.name = 'ev_had_injury';
2198| if (!had.id) had.id = EV_INJ_CANONICAL_IDS.had;
2199| if (hadLabel) hadLabel.setAttribute('for', had.id);
2200| }
2201| }
2202|
2203| function evReadCardInjuryData(card) {
2204| if (!card) return {};
2205| var isActive = card.classList.contains('is-expanded');
2206| var data = {
2207| attendance_date: (card.querySelector('.ev-inj-attendance') || {}).value || '',
2208| breve_relato: (card.querySelector('.ev-inj-relato') || {}).value || '',
2209| had_injury: !!(card.querySelector('.ev-inj-had-injury') || {}).checked,
2210| injury_type: (card.querySelector('.ev-inj-injury-type') || {}).value || '',
2211| injury_severity: (card.querySelector('.ev-inj-injury-severity') || {}).value || '',
2212| work_leave: (card.querySelector('.ev-inj-work-leave') || {}).value || '',
2213| injury_classification: (card.querySelector('.ev-inj-injury-classification') || {}).value || '',
2214| consequence: (card.querySelector('.ev-inj-consequence') || {}).value || '',
2215| potential_consequence: (card.querySelector('.ev-inj-potential-consequence') || {}).value || '',
2216| descaracter_suspect: evIsDescaracterSuspectChecked() ? 1 : 0,
2217| descaracterizado: '',
2218| descaracter_comment: (card.querySelector('.ev-inj-descaracter-comment') || {}).value || '',
2219| body_parts: []
2220| };
2221| var cardDescHidden = card.getAttribute('data-descaracterizado');
2222| if (cardDescHidden !== null && cardDescHidden !== '') {
2223| data.descaracterizado = cardDescHidden;
2224| } else {
2225| var cardBtns = card.querySelectorAll('.ev-inj-descaracter-btn.active');
2226| if (cardBtns.length) {
2227| data.descaracterizado = cardBtns[0].getAttribute('data-descaracter-val') || '';
2228| }
2229| }
2230| if (isActive) {
2231| data.body_parts = evCollectActiveBodyParts();
2232| var bld = document.getElementById('ev_body_location_detail');
2233| data.body_location_detail = bld && bld.value ? String(bld.value).trim() : '';
2234| } else {
2235| var prev = evGetInjuredDetailsObj()[card.getAttribute('data-person-id')] || {};
2236| data.body_parts = Array.isArray(prev.body_parts) ? prev.body_parts : [];
2237| data.body_location_detail = prev.body_location_detail || '';
2238| }
2239| return data;
2240| }
2241|
2242| function evApplyCardInjuryData(card, saved) {
2243| if (!card || !saved) return;
2244| var att = card.querySelector('.ev-inj-attendance');
2245| if (att) att.value = saved.attendance_date || evTodayDateInputValue();
2246| var rel = card.querySelector('.ev-inj-relato');
2247| if (rel) rel.value = saved.breve_relato || '';
2248| var had = card.querySelector('.ev-inj-had-injury');
2249| if (had) had.checked = saved.had_injury === undefined ? true : !!saved.had_injury;
2250| var type = card.querySelector('.ev-inj-injury-type');
2251| if (type && saved.injury_type) type.value = saved.injury_type;
2252| var sev = card.querySelector('.ev-inj-injury-severity');
2253| if (sev && saved.injury_severity) sev.value = saved.injury_severity;
2254| var leave = card.querySelector('.ev-inj-work-leave');
2255| if (leave) leave.value = saved.work_leave === 'PARCIAL' ? 'TOTAL' : (saved.work_leave || '');
2256| var klass = card.querySelector('.ev-inj-injury-classification');
2257| if (klass) {
2258| var ic = saved.injury_classification || '';
2259| if (ic === 'LTI_FATALIDADE') ic = 'FAT';
2260| if (ic) klass.value = ic;
2261| }
2262| if (typeof evSyncCardCatFromClassification === 'function') {
2263| evSyncCardCatFromClassification(card);
2264| }
2265| var cons = card.querySelector('.ev-inj-consequence');
2266| if (cons && saved.consequence) cons.value = saved.consequence;
2267| var pot = card.querySelector('.ev-inj-potential-consequence');
2268| if (pot && saved.potential_consequence) pot.value = saved.potential_consequence;
2269| if (typeof evFilterCardConsequences === 'function') evFilterCardConsequences(card);
2270| if (typeof evSyncCardDerivedSeverity === 'function') evSyncCardDerivedSeverity(card);
2271| if (typeof evSyncCardPotentialGteReal === 'function') evSyncCardPotentialGteReal(card);
2272| var descVal = saved.descaracterizado != null ? String(saved.descaracterizado) : '';
2273| if (descVal !== '') card.setAttribute('data-descaracterizado', descVal);
2274| var comm = card.querySelector('.ev-inj-descaracter-comment');
2275| if (comm) comm.value = saved.descaracter_comment || '';
2276| evRenderInjuredPersonSummary(card, card.getAttribute('data-person-id'));
2277| evUpdateInjuredCardSummary(card);
2278| if (typeof syncInjuryFieldsForCard === 'function') syncInjuryFieldsForCard(card);
2279| }
2280|
Request #13
deepseek-v4-flash
P:51.98K C:3.46K CR:48.26K CW:0
28885ms
Reasoning
This is a big complex JS. Let me step back and figure out the essential question: is the changed code correct enough, or are there real issues?
Let me carefully think about the actual logic in the new type blocks. The key bug-prone place:
In `evApplyTypeDescaracterPayload(payload, type)`:
- `payload.descaracter_suspect` = from type root checkbox.
- `payload.descaracterizado` = from GLOBAL `ev_descaracterizado` hidden field. But per-type root's Yes/No buttons don't have their own hidden storage; they write to the global `ev_descaracterizado`. Actually wait, in the new type roots, yes/no state is tracked by toggling classes among the buttons via `SsmaShared.toggleYesNo` on the buttons, and the value is written to the global hidden `ev_descaracterizado`. So the global hidden holds the last clicked value across all the types. Since only one type's root can be active (per occurrence type) at a given time and a single occurrence's type doesn't change, the global hidden is fine as a source for the one active type. But hold on: when loading an occurrence to edit (populateForEdit), the saved descaracterizado value is set via `evSetVal('ev_descaracterizado', descVal...)` (line 6567) — independent of type. Then, when rendering the per-type roots' Sim/Não buttons (line 6550-6552), they set the yes/no display toggle (`d-none`) based on `suspectOn`, but do NOT set which Sim/Não button is highlighted from the saved descaracterizado. They don't restore which button is active. When the user later clicks save, the payload descaracterizado = value of the global hidden which was set at load to the saved value. OK. But if the user opens ROS occurrence, sees saved descaracterizado = '1' but doesn't touch buttons, the global hidden stays '1', good. The buttons don't visually reflect saved '1' though, since no button was set active at load — a UX regression (load displays neither Sim nor Não active though the record already is descaracterizado). Actually maybe toggleYesNo highlights. But at load they don't call toggleYesNo. This might be a minor UI issue: after load, the visual toggled state does not reflect the stored Sim/Não. Combined with earlier comment in `evSyncDescaracterUi`, hidden field preselected.
Hmm wait — but there might be a bigger issue: when opening a type with the block and saving the draft, if a user simply checks "Há suspeita..." but never clicks Sim/Não, descaracterizado is not in payload (unless the hidden has old value '0'/'1' from another type...). Actually when creating a new ROS occurrence, at the moment the create modal is rendered the global hidden `ev_descaracterizado` = '' (its default in the HTML). But if the user first creates an occurrence with a different type that had a descaracterizado value and then the modal re-opened? openCreate resets? Maybe EvModal.openCreate resets form fields. In these big flows, we can't fully confirm.
Wait but does the user ever change type in the same modal? For create flow, there's an event type selector; and type-specific sections become visible per type selection. A user might start with ACIDENTE_PESSOAL, and there they may set suspect etc. Actually AP uses per-card descaracter handling.
But a user switching type after filling ROS: whether they are allowed to switch type in a single occurrence? Let me check `ev_spec_type` and whether the type changes re-render the payload. If one were creating ROS, check suspect, choose Não (writes to global hidden = '1'), then switch to QUASE_ACIDENTE, check suspect but don't click Sim/Não, the QA payload will include descaracterizado='1' from the ROS click, causing the QA occurrence to be saved with descaracterizado = Não (1) even though user never answered for QA. That's a real cross-type data contamination bug if type switch is possible within the same open modal. But if type is fixed once set (create uses wizard steps: general → type select; the event type gets fixed at start), probably the type is locked when going into technical sections. Let me check whether the user can change type after data entry. Search for evSelectedType and spec type select change. Let me find where ev_spec_type change handler disables switching. This is getting deep.
Given the review guidance to focus on real issues and precision over recall, let me identify the most concrete and defensible issues:
### Issue A (high): Change in permission semantics for the UI vs the old behavior
The controller previously computed `ssmaCanDescharacterizeAccident` via `ssmaMemberCanDescharacterizeAccident` which includes ROLE_SUPER_ADMIN/ROLE_MANAGER and Gestor Administrador bypass, plus any group (team or tag) config. New behavior derives it solely from the per-type tag lookup; tenant/gestor admins who rely on the role bypass, and members flagged via team config, will lose the visible descaracterization block and the derived flag `ssmaCanDescharacterizeAccident`. Meanwhile the server write gate `applySsmaDescaracterPermissionGate` still uses the old broad function — so UI and backend disagree. This is a functional regression. Since the write gate still uses the old function, server would still accept (and let them) write. Wait — the server gate uses OLD function which includes role bypass. So if UI hides the block, the user simply cannot set "Não". But does the server gate scrub? The user isn't able to set it because UI hides. So they lose a feature they had (admin could descaracterize). Impact: admins (tenant/gestor) can no longer mark "Não" (descaracterized) for personal accident occurrences even though they had this privilege. Is that a bug? The purpose of the PR may be precisely to restrict descaracterization to those with the tag column set. But the requirement says the hotfix is about "permission-descaraterzacao-ssma". Hmm, that's exactly what the PR intends: only those allowed by type tags. But is restricting tenant/gestor admin intentional? These roles were explicitly granted previously by documented behavior (comment in `ssmaMemberCanDescharacterizeAccident`: "liberado automaticamente para Gestor Administrador/Tenant... sem precisar de configuração explícita"). So the change drops this documented intentional allowance. If that's intended, should also update server gate consistently. If not intended, it's a regression. Either way it's worth flagging: the removal of the role bypass + team-based grants means the derived flag and server gate are inconsistent.
I'll flag this at the controller diff location where `ssmaCanDescharacterizeAccident` is derived from the new map. Also flag in service file that the new by-type method ignores team groups and role bypasses that `memberCanDescharacterizeAccident` supports.
Actually more precise and defensible: the semantic difference between old `memberCanDescharacterizeAccident` (whole config scan, incl team group keys) and new `memberCanDescharacterizeForType` (only tag keys whose tag is present in the DB with the specific type key) is a behavioral change. Members configured via a team's "Descaracterizar" column (there's clear code at controller line 24355 supporting the team group kind UI with `can_descharacterize`) would have their UI access silently revoked for personal accident. And members granted on a tag whose occurrenceTypeKey is null/empty (nullable column) are no longer recognized for any type. That is a real regression risk if team-level configuration is actually usable.
Let me verify that the "team" group kind is really used for descaracter config. Line 24355: `getAprofundamentoDescaracterMemberIds($company, 'team', $teamId)` in a team view; and earlier `setAprofundamentoDescaracterMember` accepts groupKind 'team'/'tag'. So yes, the config UI supports per-team flag.
Now for ACIDENTE_PESSOAL old block (per injured person box) previously the visibility was NOT gated by any permission (the block always present? actually it had class `d-none`, toggled by `evSyncDescaracterStageUi` only for AP in aprofundamento). The comment says "Suspeita editável por qualquer especialista AP; Sim/Não só quem tem permissão Descaracterizar". Wait the old template comment: "{# Descaracterização — só no aprofundamento. Suspeita editável por qualquer especialista AP; Sim/Não só quem tem permissão Descaracterizar. #}" then the block. The yes/no "Não" button disabled if not canSn (evSyncDescaracterUi at line 3001-3003). So previously the block was always rendered and the JS enabled/disabled the Não button based on permission. Now the whole block is hidden if `ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']` is false. But before, any AP specialist (i.e., anyone who can fill aprofundamento for AP) could mark the suspect checkbox; the Sim/Não was allowed only with the descaracter permission. Since this block is in the "aprofundamento", only people who can do the aprofundamento see it. Hmm, but in the old model, `ssmaCanDescharacterizeAccident` flag controlled whether the Não button is disabled. Now with the new logic, for a user who is a specialist but not granted "coluna Descaracterizar", the whole suspect section will be hidden, including the checkbox "Há suspeita de descaracterização?" — which previously any specialist could tick. So it's now impossible for a specialist without descaracter permission to flag suspicion. This may be intentional though: the new rule might be that only when the tag has Descaracterizar column marked, you can indicate suspicion. That's business-rule nuance; given the PR title "implement descharacterization flags by type", it seems intentionally: only those flagged in the tag can use it.
But hold on—for types other than AP (ROS, QA, AM, AA), the new block `_ev_descaracter_suspect_block` is gated by type flag. If not flagged, no UI for suspeita. Previously ROS/QA/etc. had no descaracter UI? Actually new blocks for ROS, QA, AM, AA are entirely NEW (previously those types didn't have descaracterization? The global `ev_descaracter_suspect` / `ev_descaracterizado` were part of the payload from general, but maybe the UI existed differently).
Actually, note that for AM/AA etc., the prior behavior was to not include descaracterization at all. Wait, but `evIsDescaracterSuspectChecked` previously only read `#ev_descaracter_suspect`, and AP cards used `.ev-inj-suspect-chk`. And payload for AP reads `descaracter_suspect` via `evIsDescaracterSuspectChecked()`. For other types, was descaracter_suspect/descaracterizado included in payload before? Let me search for the payload deletion at line 7068 & 7057: in "etapa 1 de acidentes" (not aprofundamento) payload fields descaracterizado/descaracter_comment are deleted. This is all existing.
OK. I need to stop going too deep into the JS and focus on what's confirmable.
### Issue B (high, security-ish / correctness): The new `memberCanDescharacterizeForType` uses per-request new DB query for each type key, plus `getAprofundamentoDescaracterMemberIds` per tag - N+1 queries. Since it's called on every occurrence hub page / detail view rendering (per page load) with 5 keys, each querying tags and for each found tag calling findOrCreateEntity + reading config. That's roughly 5 tag queries + up to 5 config entity loads per page load. Could be moderate. But is the page per-user? It renders for the logged user only, once per page. This is a per-request DB cost but probably small (few tags). Also `findOrCreateEntity` might create entities on read if not found (that's a side effect on a GET page!). Let me check `findOrCreateEntity`. If the page load for a user whose company has no SsmaOccurrenceTypeConfig row will flush-create one — a write on GET requests; probably existing behavior since old `memberCanDescharacterizeAccident` also used findOrCreateEntity. So same.
Actually wait — old controller computed only ONE check (single memberCanDescharacterizeAccident) which loads the whole config entity once (findOrCreateEntity), scanning raw structure. New code: for each of 5 keys, `em->getRepository(SsmaPermissionTag::class)->findBy([...])` = 5 queries, plus for each tag, `getAprofundamentoDescaracterMemberIds` → `findOrCreateEntity` each time (each invocation loads the config entity again — Doctrine identity map caches it per request so the second call returns cached, fine). So added 5 queries per occurrence page. Not huge, but could mention as minor perf. I'd focus on real issues.
Actually, wait—a bigger concern: `memberCanDescharacterizeForType` returns false when the typeKey tag doesn't exist in the DB. But `ensureFixedTechnicalTagsForCompany` creates fixed tags for the 5 types when the permission-tags management page is opened, not necessarily for every company. If the company never opened that page, there may be no SsmaPermissionTag rows at all → flags all false → descaracterization blocks hidden. But wait, then no one can descaracterize... Actually if there are no tags at all for the company, descaracterization of any type would be impossible, even if configured in the legacy aprofundamento_descaracter config with team/tag groups of older flow (from the "Profissionais de Saúde" config page that shows "can_descaracterize" per team and tag). Hmm, let me check the "Profissionais de Saúde" config UI that sets aprofundamento_descaracter. Actually it's per "tag" in permission tags page (line 24503) or per team in team page (line 24355). So both derive from same entity.
But more importantly, whether old flow always ensured fixed tags exist. Where is ensureFixedTechnicalTagsForCompany called? Probably when opening permission tags management. If a company has never been to that page but had legacy configuration... the legacy config page (setAprofundamentoDescaracterMember) stores "tag:{id}" and "team:{id}". "tag:{id}" only valid if the tag exists (i.e., the group must exist for it to be configured). So tags exist for tag-based config. But team-based grants are legitimate and get dropped in new logic.
OK. That's issue A which I'll formulate carefully.
### Issue C (data integrity): The new per-type UI posts `descaracterizado` for ROS/QA/AM/AA payloads from the global hidden. Server-side `applySsmaDescaracterPermissionGate` — does it run for ROS/QA/AM/AA? Let me confirm the server stores `descaracterizado` for these types and permission gate function invocation points. Search where applySsmaDescaracterPermissionGate is invoked.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "applySsmaDescaracterPermissionGate"}
Result
File: src/Controller/SsmaController.php Match lines: 3 25312| $data = $this->applySsmaDescaracterPermissionGate($data, $company, $user); 25527| $data = $this->applySsmaDescaracterPermissionGate( 27408| private function applySsmaDescaracterPermissionGate(
code_search
Show Details
Arguments
{"search_text": "SSMA_CAN_DESCARACTERIZE"}
Result
File: docs/ssma/ocorrencia-07-suspeita-descaracterizacao-ui.md
Match lines: 1
25|Permissão: flag `ssmaCanDescharacterizeAccident` / `SSMA_CAN_DESCARACTERIZE` (coluna Descaracterizar em Profissionais de Saúde).
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 2
57| window.SSMA_CAN_DESCARACTERIZE = {{ ssmaCanDescharacterizeAccident|default(false) ? 'true' : 'false' }};
2922| return window.SSMA_CAN_DESCARACTERIZE === true || window.SSMA_CAN_DESCARACTERIZE === 'true';
Request #14
deepseek-v4-flash
P:55.71K C:187 CR:55.42K CW:0
2292ms
Reasoning
Let me read those doc files and see how the whole descaracterização UI was expected to behave. Let me read docs/ssma/ocorrencia-07-suspeita-descaracterizacao-ui.md.
Tool Calls (2)
file_read
Show Details
Arguments
{"file_path": "docs/ssma/ocorrencia-07-suspeita-descaracterizacao-ui.md"}
Result
File: docs/ssma/ocorrencia-07-suspeita-descaracterizacao-ui.md (Total lines: 38) IS_TRUNCATED: false LINE_RANGE: 1-38 1|# 7 — Suspeita de descaracterização (texto vermelho + Sim/Não) 2| 3|**Fonte:** Figma Parte 2 · Etapas 6 e 8 4|**Status:** **Aplicado** (ajustado 16/07/2026) 5| 6|## Pedido 7| 8|1. Se **suspeita** marcada → texto vermelho: 9| **`SUSPEITA DE DESCARACTERIZAÇÃO DE OCORRÊNCIA`** 10|2. Profissional de saúde **com permissão** de descaracterizar → abaixo da frase, botões **Sim / Não** para: 11| **“Não caracterizado como acidente.”** 12|3. Sem permissão → não mostra S/N (mensagem de sem permissão). 13| 14|> A 4ª imagem (S/N rabiscado) é só o **conceito** de escolha binária — a UI usa botões `Sim` / `Não` do design system, não letras soltas. 15| 16|## Backend 17| 18|| UI | Campo | Valor | 19||----|-------|--------| 20|| Suspeita marcada | `descaracter_suspect` | `1` | 21|| Sim (descaracterizado) | `descaracterizado` | `1` | 22|| Não (não descaracterizado) | `descaracterizado` | `0` | 23|| Sem resposta | `descaracterizado` | `''` | 24| 25|Permissão: flag `ssmaCanDescharacterizeAccident` / `SSMA_CAN_DESCARACTERIZE` (coluna Descaracterizar em Profissionais de Saúde). 26| 27|## Implementação 28| 29|| Peça | Onde | 30||------|------| 31|| UI na caixinha | `_ev_injured_person_box.html.twig` | 32|| Sync | `evSyncDescaracterUi()` + bind em `evBindInjuredCardEvents` | 33|| Gate permissão | `evCanDescharacterizeAccident()` | 34| 35|## Validação 36| 37|Com permissão: marcar suspeita → banner vermelho + Sim/Não. Sem permissão: banner + “Sem permissão…”. 38|
file_read
Show Details
Arguments
{"end_line": 25330, "file_path": "src/Controller/SsmaController.php", "start_line": 25290}
Result
File: src/Controller/SsmaController.php (Total lines: 27765)
IS_TRUNCATED: false
LINE_RANGE: 25290-25330
25290|
25291| // =========================================================================
25292| // EVENTOS SSMA (SSMAEvent tipado)
25293| // =========================================================================
25294|
25295| /**
25296| * POST /manager/ssma/events
25297| * Cria um novo evento SSMA tipado.
25298| */
25299| public function createEvent(Request $request): JsonResponse
25300| {
25301| /** @var \App\Entity\User|null $user */
25302| $user = $this->getUser();
25303| $company = $user?->getCompany();
25304| if (!$user || !$company) {
25305| return new JsonResponse(['success' => false, 'message' => 'Não autenticado.'], 401);
25306| }
25307|
25308| $data = json_decode($request->getContent(), true) ?? [];
25309| $data = $this->normalizeSsmaEventPayload($data, $company);
25310| $data = $this->normalizeSsmaEventManagerInDetails($data, $company);
25311| $data = $this->forceSsmaRosReporterForPlainMember($data, $company, $user);
25312| $data = $this->applySsmaDescaracterPermissionGate($data, $company, $user);
25313| $data = $this->ensureSsmaEventTitle($data);
25314|
25315| $validator = new \App\Service\Ssma\SsmaEventValidator();
25316| $errors = $validator->validate($data, [
25317| 'allowed_type_keys' => $this->ssmaOccurrenceTypeConfig->getAllowedTypeKeys($company),
25318| ]);
25319| if ($errors !== []) {
25320| return new JsonResponse([
25321| 'success' => false,
25322| 'message' => implode(' ', $errors),
25323| 'errors' => $errors,
25324| ], 422);
25325| }
25326|
25327| if (!$this->canMemberRegisterOwnOccurrence($company, $user)) {
25328| return new JsonResponse(['success' => false, 'message' => 'Você não tem autorização para registrar ocorrências.'], 403);
25329| }
25330|
Request #15
deepseek-v4-flash
P:57.07K C:1.26K CR:55.81K CW:0
12107ms
Reasoning
The descaracterização write gate runs for all event creations (createEvent and updateEvent presumably at 25527). `applySsmaDescaracterPermissionGate` uses old broad semantics. So the server keeps the old semantics (member anywhere in descaracter column, plus role bypass). So the new UI hides blocks for admins etc. but doesn't change the server permission. Actually wait — if the UI is hidden but the user has no way to mark it, then this is a UI permission regression. However, is it possible that an admin role (ROLE_MANAGER/ROLE_SUPER_ADMIN) user would not have a matching tag but does have old bypass? In `ssmaMemberCanDescharacterizeAccident`, roles ROLE_SUPER_ADMIN/ROLE_MANAGER return true; also Gestor Administrador tag members. These are typically company users. For ROLE_SUPER_ADMIN/ROLE_MANAGER platform roles, `currentMemberForExport` maybe null. Then new flags `[]` → `ssmaCanDescharacterizeAccident` = false. Previously those platform admins passed because `ssmaMemberCanDescharacterizeAccident` returned true regardless of member. So yes, they will lose access in the UI.
For a "Gestor Administrador" member without a tag descaracter membership: new flag false, old flag true (memberIsSsmaGestorAdministrador). So UI hides. So regression for them.
Thus the PR likely intentionally restricts the UI to specific descaracter-per-tag config; but the role bypass remains on the server gate, meaning:
- Access divergence between UI (client) and backend (server). But as discussed, server is more permissive than UI; so security not impacted, but functionality regression for admin roles, and inconsistent because if admin uses the API directly the server still allows.
Wait: but is there any case where UI flag is true but the server would not allow (i.e., no ability to write)? Server gate with old semantics is broader, so no.
So main impact: members that previously could see & use descaracterization UI (admins, gestor admin, team-level flagged) can no longer. This might be the intended tightening of the hotfix (permission-descaraterzacao). Hmm. Given the branch is "hotfix/permission-descaraterzacao-ssma", the whole point may be to fix over-permission: restricting the permission to only tags by type. In that case, maybe the changed server gate should be aligned. Because now server gate is inconsistent with the new per-type rule - for ROS/QA/AM/AA new types payload `descaracterizado` is set from global field; server `applySsmaDescaracterPermissionGate` checks OLD broad permission. That means even a member who isn't in the type tag at all could send `descaracterizado=1` directly and the server would accept if they're in any descaracter group or an admin. But UI only allows those with type tag. That inconsistency suggests the server enforcement hasn't been updated to per-type. This is the hotfix branch: should fix server-side. The PR as written implements per-type gating only on the UI (rendering/payload), not on server write. The server gate remains the old broad rule. Wait, but this is only relevant for ROS/QA/AM/AA (new types), because for AP the old UI only allowed Não if SSMA_CAN_DESCARACTERIZE... which was old broad rule.
Hmm let's reflect: with per-type block for ROS etc., the payload sends `descaracterizado` if value is '0' or '1' from global hidden. This field is stored in details (e.g. detail 'descaracterizado'). The server gate scrubs descaracterizado for non-permitted. For ROS events maybe there is no actual business meaning of descaracterizar acidente? Actually descaracterizar is about characterizing something as not an accident. For ROS/QA/AM/AA types, is descaracterização semantically relevant? Suspeita de descaracterização da ocorrência appears on all. Hmm.
Let me confirm the server normalization handles details' descaracterizado across types. This might be too deep.
Let me re-read the doc and confirm `descaracterizado` semantics: value '1' = "Sim (descaracterizado)"; '0' = "Não (não descaracterizado)". Wait table says:
- Sim (descaracterizado) | descaracterizado | 1
- Não (não descaracterizado) | descaracterizado | 0
Wait confusing because in the UI, Sim button has data-descaracter-val="0" and Não button has val="1". In the template above: button Sim val=0 "Sim", button Não val=1. And tooltip says "Sim = é acidente. Não (descaracterizar) ...". So Sim val 0 (is accident), Não val 1 (descaracterizado). Yes matches.
OK.
Now let's weigh issues to report. Review output should focus on files in the review list.
Let me check the templates used to include `_ev_injured_person_box.html.twig` to ensure the variable `ssmaCanDescharacterizeByType` is always provided. The partial is included at modal_event line 672 with the variable. Are there other includes? Search.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "_ev_injured_person_box.html.twig"}
Result
File: docs/engineering/pr/hotfix-ssma-ambiental-material-brenda-new-production/PR_descricao_hotfix-ssma-ambiental-material-brenda-new-production.md
Match lines: 1
87|| `_ev_injured_person_box.html.twig` | Consequências no card do acidentado |
File: docs/engineering/pr/hotfix-ssma-ap-validacao-etapa1-new-production/PR_arquivos_hotfix-ssma-ap-validacao-etapa1-new-production.txt
Match lines: 1
222|M templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig
File: docs/engineering/pr/hotfix-ssma-ap-validacao-etapa1-new-production/PR_impacto_hotfix-ssma-ap-validacao-etapa1-new-production.txt
Match lines: 1
222| .../partials/_ev_injured_person_box.html.twig | 106 +-
File: docs/ssma/ocorrencia-02-caixinha-por-acidentado.md
Match lines: 1
21|| Template da caixinha | `_ev_injured_person_box.html.twig` |
File: docs/ssma/ocorrencia-03-data-atendimento.md
Match lines: 1
21|| Input | `.ev-inj-attendance` em `_ev_injured_person_box.html.twig` |
File: docs/ssma/ocorrencia-04-breve-relato.md
Match lines: 1
22|| Textarea | `.ev-inj-relato` em `_ev_injured_person_box.html.twig` |
File: docs/ssma/ocorrencia-06-tudo-na-caixinha-descaracter.md
Match lines: 1
25|| Campos da pessoa | `_ev_injured_person_box.html.twig` |
File: docs/ssma/ocorrencia-07-suspeita-descaracterizacao-ui.md
Match lines: 1
31|| UI na caixinha | `_ev_injured_person_box.html.twig` |
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 1
671| {% include 'ssma/occurrence/partials/_ev_injured_person_box.html.twig' with {
File: tests/Unit/Product/Ssma/assert_branch_ui_fixes.php
Match lines: 1
43|$injured = $root . '/templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig';
file_read_diff
Show Details
Arguments
{"path_array": ["templates/ssma/occurrence/partials/_modal_event.html.twig"]}
Result
==== FILE: templates/ssma/occurrence/partials/_modal_event.html.twig ====
diff --git a/templates/ssma/occurrence/partials/_modal_event.html.twig b/templates/ssma/occurrence/partials/_modal_event.html.twig
--- a/templates/ssma/occurrence/partials/_modal_event.html.twig
+++ b/templates/ssma/occurrence/partials/_modal_event.html.twig
@@ -462,6 +462,10 @@
</div>
</div>
</div>
+ {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
+ type_key: 'ROS',
+ ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
+ } %}
</div>
{# ── QUASE ACIDENTE ───────────────────── #}
@@ -532,6 +536,10 @@
</div>
</div>
</div>
+ {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
+ type_key: 'QUASE_ACIDENTE',
+ ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
+ } %}
</div>
</div>{# /ev-spec-type-card #}
@@ -664,7 +672,8 @@
person_id: '',
person_name: '',
attendance_date: '',
- breve_relato: ''
+ breve_relato: '',
+ ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
} %}
</div>
@@ -875,6 +884,10 @@
_hide_failed_barrier: true,
_show_barrier_help: true
} %}
+ {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
+ type_key: 'ACIDENTE_MATERIAL',
+ ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
+ } %}
</div>
{# ── ACIDENTE AMBIENTAL ───────────────── #}
@@ -891,6 +904,10 @@
_hide_failed_barrier: true,
_show_barrier_help: true
} %}
+ {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
+ type_key: 'ACIDENTE_AMBIENTAL',
+ ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
+ } %}
</div>
</div>{# /ev-technical-section #}
@@ -2907,7 +2924,24 @@
function evIsDescaracterSuspectChecked() {
var el = document.getElementById('ev_descaracter_suspect');
- return !!(el && el.checked);
+ if (el && el.checked) return true;
+ return !!document.querySelector('.ev-type-descaracter-suspect:checked');
+ }
+
+ function evGetTypeDescaracterRoot(type) {
+ return document.querySelector('[data-descaracter-root][data-descaracter-type="' + type + '"]');
+ }
+
+ function evApplyTypeDescaracterPayload(payload, type) {
+ var root = evGetTypeDescaracterRoot(type);
+ if (!root) return;
+ var chk = root.querySelector('.ev-type-descaracter-suspect');
+ payload.descaracter_suspect = chk && chk.checked ? 1 : 0;
+ var descVal = String((document.getElementById('ev_descaracterizado') || {}).value || '');
+ if (descVal === '0' || descVal === '1') payload.descaracterizado = descVal;
+ var comm = root.querySelector('.ev-type-descaracter-comment');
+ var commVal = comm ? String(comm.value || '').trim() : '';
+ if (commVal) payload.descaracter_comment = commVal;
}
function evIsCreateMode() {
@@ -5745,6 +5779,30 @@
evPersistDraftSoon();
});
}
+ document.querySelectorAll('[data-descaracter-root]').forEach(function (root) {
+ var chk = root.querySelector('.ev-type-descaracter-suspect');
+ var yesNo = root.querySelector('.ev-type-descaracter-yesno');
+ if (chk && yesNo) {
+ chk.addEventListener('change', function () {
+ yesNo.classList.toggle('d-none', !chk.checked);
+ var globalChk = document.getElementById('ev_descaracter_suspect');
+ if (globalChk) globalChk.checked = chk.checked;
+ evPersistDraftSoon();
+ });
+ }
+ root.addEventListener('click', function (e) {
+ var btn = e.target && e.target.closest ? e.target.closest('.ev-type-desc-btn') : null;
+ if (!btn) return;
+ var hidden = document.getElementById('ev_descaracterizado');
+ if (hidden) hidden.value = btn.getAttribute('data-descaracter-val') || '';
+ if (window.SsmaShared && typeof window.SsmaShared.toggleYesNo === 'function') {
+ window.SsmaShared.toggleYesNo(root.querySelectorAll('.ev-type-desc-btn'), hidden ? hidden.value : null, {
+ valueAttr: 'data-descaracter-val'
+ });
+ }
+ evPersistDraftSoon();
+ });
+ });
// Checkbox de suspeita por card (aprofundamento): mostra/oculta Sim/Não do próprio card.
document.addEventListener('change', function (e) {
if (!e.target || !e.target.classList.contains('ev-inj-suspect-chk')) return;
@@ -6487,6 +6545,14 @@
var suspectRaw = det.descaracter_suspect != null ? det.descaracter_suspect : data.descaracter_suspect;
var suspectOn = suspectRaw === true || suspectRaw === 1 || suspectRaw === '1';
evSetChk('ev_descaracter_suspect', suspectOn);
+ document.querySelectorAll('[data-descaracter-root]').forEach(function (root) {
+ var chk = root.querySelector('.ev-type-descaracter-suspect');
+ if (chk) chk.checked = suspectOn;
+ var yesNo = root.querySelector('.ev-type-descaracter-yesno');
+ if (yesNo) yesNo.classList.toggle('d-none', !suspectOn);
+ var comm = root.querySelector('.ev-type-descaracter-comment');
+ if (comm) comm.value = det.descaracter_comment || data.descaracter_comment || '';
+ });
// Propaga suspeita para cada card (checkbox editável no aprofundamento).
document.querySelectorAll('.ev-injured-person-box').forEach(function (card) {
var chk = card.querySelector('.ev-inj-suspect-chk');
@@ -7039,6 +7105,7 @@
: '';
payload.ros_resolution_evidences = payload.ros_resolved ? (evRosResolutionEvidences || []).slice() : [];
payload.people_ids = '';
+ evApplyTypeDescaracterPayload(payload, 'ROS');
} else if (type === 'QUASE_ACIDENTE') {
payload.involvement_type = document.getElementById('ev_involvement_type_qa').value;
payload.barrier_type = (document.getElementById('ev_barrier_type_qa') || { value: '' }).value;
@@ -7048,6 +7115,7 @@
payload.person_id = (document.getElementById('ev_person_id_qa') || { value: '' }).value;
payload.person_type = (document.getElementById('ev_person_type_qa') || { value: '' }).value;
}
+ evApplyTypeDescaracterPayload(payload, 'QUASE_ACIDENTE');
} else if (type === 'ACIDENTE_PESSOAL') {
if (typeof evSyncInjuredCardsFromInvolved === 'function') {
evSyncInjuredCardsFromInvolved();
@@ -7186,6 +7254,7 @@
payload.potential_severity
);
if (amSev) payload.potential_severity = amSev;
+ evApplyTypeDescaracterPayload(payload, 'ACIDENTE_MATERIAL');
} else if (type === 'ACIDENTE_AMBIENTAL') {
payload.environmental_medium = document.getElementById('ev_environmental_medium').value;
payload.pollutant_type = document.getElementById('ev_pollutant_type').value;
@@ -7204,6 +7273,7 @@
payload.potential_severity
);
if (aaSev) payload.potential_severity = aaSev;
+ evApplyTypeDescaracterPayload(payload, 'ACIDENTE_AMBIENTAL');
}
var evId = document.getElementById('ev_id').value;
Request #16
deepseek-v4-flash
P:61.05K C:424 CR:58.24K CW:0
4512ms
Reasoning
Let me analyze the JS in detail to confirm a couple of functional bug hypotheses.
Consider the draft-saving flow. When user edits a ROS occurrence with saved `descaracterizado='1'`, populateForEdit sets the global hidden `ev_descaracterizado` to '1'. But the Sim/Não button state isn't synced to root buttons (they don't toggleYesNo). But payload uses the hidden field, so the value survives.
But consider the scenario in the create modal for a ROS occurrence. The type block is inside `ev-spec-type-card`. When the occurrence type is chosen (say the flow starts with the event type select — actually the create flow presumably chooses a type before these type-specific sections become visible), if it's the only type block, no cross-type issues.
Let me check the create flow: In the create modal (step general?), maybe the user selects a type first, then enters technical type. All type sections are in the DOM and toggled by the selected type. If the type can't change once the section data is entered (because it's selected early and the DOM displays per type). Usually, users can switch the type before saving.
Let me find ev_spec_type select change to see whether type switch is blocked once entered. Search for ev_spec_type.
Tool Calls (2)
code_search
Show Details
Arguments
{"file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"], "search_text": "ev_spec_type"}
Result
No matches found
code_search
Show Details
Arguments
{"search_text": "function evBindTypeSectionToggle", "file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"]}
Result
No matches found
Request #17
deepseek-v4-flash
P:61.5K C:1.6K CR:61.44K CW:0
14367ms
Reasoning
No `ev_spec_type` in this template. Let me search for how type sections are shown; likely the modal for a given type is opened directly with `type` param. Let's look for functions toggling the type sections, e.g., `data-occ-type` or where sections have class. Let me search for 'ev-type' + 'show' and how section display is handled, and where evSelectedType is derived.
Actually, given the flow: The create modal may be reused; if the user picks "ROS" then the ROS card is shown. Let's search for occurrence_type_selected etc. Not necessary to chase everything.
Let me focus and try to finalize real issues. Let me more deeply examine the critical data-integrity concern about the descaracter payload for types ROS/QA/AM/AA being silently dropped when the user does not have the block (i.e., tag not flagged) - this means data previously recorded could be dropped on edit by someone without the flag.
Actually here is an important issue: In the populate for edit, the type-specific per-root comment textarea and suspect checkbox are restored only for roots that exist in DOM. All 5 roots exist (but the AP type doesn't have the per-type block, only the 4 others). Suppose an ROS occurrence has saved `descaracter_suspect=1` and `descaracter_comment='...'` and `descaracterizado='1'`. If the current editor is NOT in the ROS tag's descaracter list, the ROS root isn't rendered (because block only renders if flag true). Then during save, `evApplyTypeDescaracterPayload(payload, 'ROS')` finds no root, returns early without setting `descaracter_suspect`. What does the payload assembly produce for `descaracter_suspect` then? `evIsDescaracterSuspectChecked()` returns false now (only checks global checkbox and type-specific checkbox). Also descaracterizado would only be sent if the global hidden holds a value: at load `evSetVal('ev_descaracterizado', descVal)` stores saved '1' (global). So payload.descaracterizado would be set to '1' if hidden set. Wait, but in ROS branch, only `evApplyTypeDescaracterPayload` sets descaracter fields; no other place sets `payload.descaracterizado` for ROS. If root absent → nothing set → descaracter fields are not sent in payload (they're just absent). What does the server do on edit when these fields absent? In `applySsmaDescaracterPermissionGate`, `existingDetails` may contain descaracterizado='1' and it maintains it (line 27421-27424). So saved descaracterizado stays. But descaracter_suspect and descaracter_comment aren't managed by gate; if absent from details in payload, they might be preserved by merge? We need to know merge semantics: `merged['details'] = $existingDetails;` and details may be replaced per key.
Actually, there's bigger issue: editing by a user without the flag might erase descaracter_suspect/comment data silently because the root not rendered, payload not set, and server may overwrite details (based on merge). This could be data loss. But is the descaracter data still displayed to users without permission? They shouldn't see it; hiding it is the point. But on saving any other edit, they may wipe previously stored descaracter_suspect/comment. Given how complex the merge is, I can't confirm without knowing the update merge. This is speculative.
Let's look at how updateEvent merges descaracter fields into details, to see whether absent fields get cleared. Search for the update handler around line 25527 & existingDetails semantics.
Actually this is too deep and likely beyond the scope. But the biggest, most concrete & defensible points:
1. **Inconsistency server/UI on who may descaracterize**: new per-type flags (tag-only, no admin/gestor role bypass, no team-level grants) vs old server gate and old UI logic (role bypass + any group incl. teams). Concrete consequences:
- Super admin/manager/gestor admins (explicitly granted in old controller helper) lose ability in UI to see descaracter block.
- Members configured for descaracterizar at team level lose visibility.
- Yet the server's write gate unchanged → rule diverges: a user who cannot see the block could still be accepted by the backend if they forge a request, meaning the tightening isn't really enforced server-side, and a user who the backend trusts (admin) can't do it through the UI.
2. **Legacy UI expectation removed**: for AP, old rule: suspeita by any specialist AP; Sim/Não only by flagged. New: everything hidden unless the type tag has the Descaracterizar column for that member. If a company never assigned a member to the type tag's Descaracterizar column, no one can even mark suspicion, even specialists with the AP tag that previously could. This is a functional regression and might be unintended (because for a member with the aprofundamento tag, suspect might be legit). Given rule specificity? Not sure if intended. We'll mention as attention.
3. **God object / responsabilidade no controller**: The controller is 27k lines; the change further computes a permission map inside the action. Wait, but it was already calling ssmaOccurrenceTypeConfig->memberCanDescharacterizeAccident in helper inside the controller? The helper `ssmaMemberCanDescharacterizeAccident` existed and contained business logic (role bypass). The new change moves the decision to service method getDescharacterizeFlagsByType. Actually now the controller calls the service; the derivation `ssmaCanDescharacterizeAccident = map['ACIDENTE_PESSOAL']` replicates the decision... where? It drops the role-bypass logic that was inside the controller helper. It's still more delegation to the service, arguably reducing controller business logic. However, now the controller derives `ssmaCanDescharacterizeAccident` by choosing the key 'ACIDENTE_PESSOAL', effectively baking business semantics into the controller instead of the service; but this matches what the service method provides. Also the maps are built via service methods. The change reduced the controller's business logic? Previously it called the service in the helper; the helper still exists (used by applySsmaDescaracterPermissionGate). So now there are two mechanisms.
I should focus on the review files but mention code duplication as a maintainability issue: the by-type methods duplicate logic that diverges from memberCanDescharacterizeAccident.
Now, let me verify the claim about divergence in the controller with more detail: is `ssmaCanDescharacterizeAccident` still used by templates to render blocks and gate behavior? Yes, JS uses SSMA_CAN_DESCARACTERIZE to allow/disallow the "Não" button in AP cards. And the `occurrence_view.html.twig` also receives flag? Let's check uses of ssmaCanDescharacterizeAccident across templates.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "ssmaCanDescharacterizeAccident"}
Result
File: docs/ssma/CORRECOES-OCORRENCIA-FIGMA-PARTE-2.md
Match lines: 1
164|**Status:** **Feito** (flag `ssmaCanDescharacterizeAccident` ↔ coluna Descaracterizar)
File: docs/ssma/ocorrencia-07-suspeita-descaracterizacao-ui.md
Match lines: 1
25|Permissão: flag `ssmaCanDescharacterizeAccident` / `SSMA_CAN_DESCARACTERIZE` (coluna Descaracterizar em Profissionais de Saúde).
File: src/Controller/SsmaController.php
Match lines: 2
12540| $ssmaCanDescharacterizeAccident = (bool) ($ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false);
12657| 'ssmaCanDescharacterizeAccident' => $ssmaCanDescharacterizeAccident,
File: src/Service/Ssma/ViewData/SsmaPermissionContextResolver.php
Match lines: 1
27| 'ssmaCanDescharacterizeAccident',
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 1
57| window.SSMA_CAN_DESCARACTERIZE = {{ ssmaCanDescharacterizeAccident|default(false) ? 'true' : 'false' }};
file_find
Show Details
Arguments
{"query_name": "SsmaOccurrenceTypeConfigServiceTest"}
Result
tests/Unit/Product/Ssma/SsmaOccurrenceTypeConfigServiceTest.php
Request #18
deepseek-v4-flash
P:63.46K C:383 CR:62.98K CW:0
3867ms
Reasoning
Let me look at the `SsmaOccurrenceTypeConfigServiceTest.php` to see if there are tests for `memberCanDescharacterizeAccident`, and if the new methods are untested.
Also check the "view data scope" listing where the whole ssma view is built - this is the occurrence hub and detail view. Let me examine whether other actions build the same variables but aren't updated. Search for other usages of getDescharacterizeFlagsByType. Only the controller line. Also other spots that pass `ssmaCanDescharacterizeAccident`? Only the main buildSsmaViewData? Actually SsmaController at 12532 appears in buildSsmaViewData? Let's identify which method this is. Around line 12532 we're in a large method. Search for the enclosing method name and to confirm there is exactly one place the view data is built (used for many pages incl. index). This may mean the new per-type computation happens even for other views (config, dashboards...). Let me confirm the method name at that area.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "function buildSsmaViewData", "file_patterns": ["src/Controller/SsmaController.php"]}
Result
File: src/Controller/SsmaController.php Match lines: 1 11521| private function buildSsmaViewData(?array $detailScope = null): array
file_read
Show Details
Arguments
{"end_line": 120, "file_path": "tests/Unit/Product/Ssma/SsmaOccurrenceTypeConfigServiceTest.php", "start_line": 1}
Result
File: tests/Unit/Product/Ssma/SsmaOccurrenceTypeConfigServiceTest.php (Total lines: 434)
IS_TRUNCATED: false
LINE_RANGE: 1-120
1|<?php
2|
3|declare(strict_types=1);
4|
5|namespace App\Tests\Unit\Product\Ssma;
6|
7|use App\Entity\Company;
8|use App\Entity\SsmaOccurrenceTypeConfig;
9|use App\Enum\Ssma\EventTypeEnum;
10|use App\Service\Ssma\SsmaOccurrenceTypeConfigService;
11|use Doctrine\ORM\EntityManagerInterface;
12|use Doctrine\ORM\EntityRepository;
13|
14|final class SsmaOccurrenceTypeConfigServiceTest extends SsmaTestCase
15|{
16| public function testDefaultCategoriesPerBuiltinType(): void
17| {
18| $service = $this->createServiceWithStoredTypes([]);
19|
20| $cfg = $service->getTypesForFrontend($this->createCompany());
21| $byKey = $this->indexTypesByKey($cfg['types']);
22|
23| self::assertCount(count(SsmaOccurrenceTypeConfigService::MASTER_CATEGORIES), $byKey[EventTypeEnum::ROS]['categories']);
24| self::assertCount(count(SsmaOccurrenceTypeConfigService::MASTER_CATEGORIES), $byKey[EventTypeEnum::QUASE_ACIDENTE]['categories']);
25| self::assertCount(53, $byKey[EventTypeEnum::ACIDENTE_PESSOAL]['categories']);
26| self::assertCount(21, $byKey[EventTypeEnum::ACIDENTE_MATERIAL]['categories']);
27| self::assertCount(18, $byKey[EventTypeEnum::ACIDENTE_AMBIENTAL]['categories']);
28|
29| self::assertContains('Queda de Pessoas', $byKey[EventTypeEnum::ACIDENTE_PESSOAL]['categories']);
30| self::assertNotContains('Ameaça à Fauna/Flora', $byKey[EventTypeEnum::ACIDENTE_PESSOAL]['categories']);
31|
32| self::assertContains('Desvio de Trânsito', $byKey[EventTypeEnum::ACIDENTE_MATERIAL]['categories']);
33| self::assertNotContains('Queda de Pessoas', $byKey[EventTypeEnum::ACIDENTE_MATERIAL]['categories']);
34|
35| self::assertContains('Vazamento de Cianeto', $byKey[EventTypeEnum::ACIDENTE_AMBIENTAL]['categories']);
36| self::assertNotContains('Queda em Altura', $byKey[EventTypeEnum::ACIDENTE_AMBIENTAL]['categories']);
37| }
38|
39| public function testMigratesLegacyNatureCategoriesToNewDefaults(): void
40| {
41| $legacy = [
42| 'Queda',
43| 'Choque Elétrico',
44| 'Arco Elétrico',
45| 'Prensamento',
46| 'Esmagamento',
47| 'Corte',
48| 'Impacto',
49| 'Projeção de Partículas',
50| 'Atropelamento',
51| 'Vazamento',
52| 'Incêndio',
53| 'Explosão',
54| 'Exposição Química',
55| 'Exposição Biológica',
56| 'Exposição Física',
57| 'Falha Operacional',
58| ];
59|
60| $service = $this->createServiceWithStoredTypes([
61| [
62| 'key' => EventTypeEnum::ACIDENTE_PESSOAL,
63| 'label' => 'Acidente Pessoal',
64| 'active' => true,
65| 'categories' => $legacy,
66| 'selected_categories' => $legacy,
67| ],
68| ]);
69|
70| $cfg = $service->getTypesForFrontend($this->createCompany());
71| $byKey = $this->indexTypesByKey($cfg['types']);
72|
73| self::assertCount(53, $byKey[EventTypeEnum::ACIDENTE_PESSOAL]['categories']);
74| self::assertContains('Queda de Pessoas', $byKey[EventTypeEnum::ACIDENTE_PESSOAL]['categories']);
75| self::assertNotContains('Queda', $byKey[EventTypeEnum::ACIDENTE_PESSOAL]['categories']);
76| }
77|
78| public function testPreservesCustomCategoriesOutsideLegacySet(): void
79| {
80| $custom = ['Queda', 'Minha Categoria Customizada'];
81|
82| $service = $this->createServiceWithStoredTypes([
83| [
84| 'key' => EventTypeEnum::ACIDENTE_PESSOAL,
85| 'label' => 'Acidente Pessoal',
86| 'active' => true,
87| 'categories' => $custom,
88| 'selected_categories' => $custom,
89| ],
90| ]);
91|
92| $cfg = $service->getTypesForFrontend($this->createCompany());
93| $byKey = $this->indexTypesByKey($cfg['types']);
94|
95| self::assertSame($custom, $byKey[EventTypeEnum::ACIDENTE_PESSOAL]['categories']);
96| }
97|
98| public function testSelectedLocationsDefaultToFullCatalog(): void
99| {
100| $service = $this->createServiceWithStoredData([
101| 'types' => [],
102| 'locations' => ['Mina', 'Almoxarifado'],
103| ]);
104|
105| $cfg = $service->getTypesForFrontend($this->createCompany());
106|
107| self::assertSame(['Mina', 'Almoxarifado'], $cfg['locations']);
108| self::assertSame(['Mina', 'Almoxarifado'], $cfg['selected_locations']);
109| self::assertFalse($cfg['locations_inherited']);
110| }
111|
112| public function testSelectedLocationsRespectsStoredSubset(): void
113| {
114| $service = $this->createServiceWithStoredData([
115| 'types' => [],
116| 'locations' => ['Mina', 'Almoxarifado', 'Britagem'],
117| 'selected_locations' => ['Mina', 'Britagem'],
118| ]);
119|
120| $cfg = $service->getTypesForFrontend($this->createCompany());
Request #19
deepseek-v4-flash
P:65.44K C:262 CR:63.74K CW:0
2854ms
Reasoning
The controller method that adds the map is `buildSsmaViewData` starting at 11521 (the huge method) - used for index/hub AND occurrence detail and other SSMA pages. Let me check whether `buildSsmaViewData` is invoked for permission-tag/config pages (not the occurrence views) too, and whether passing new var there is harmless. It doesn't matter much.
Now, what about the test file: there are existing tests for memberCanDescharacterizeAccident? Let me search in test file.
Tool Calls (2)
code_search
Show Details
Arguments
{"file_patterns": ["tests/Unit/Product/Ssma/SsmaOccurrenceTypeConfigServiceTest.php"], "search_text": "Descaracter|descaracter"}
Result
No matches found
code_search
Show Details
Arguments
{"file_patterns": ["src/Controller/SsmaController.php"], "search_text": "buildSsmaViewData\\("}
Result
No matches found
Request #20
deepseek-v4-flash
P:65.73K C:1.21K CR:65.66K CW:0
10717ms
Reasoning
So no tests exist at all for the descaracterization permissions, old or new. New permission logic has no test coverage.
Now let me examine the JS concern in more detail about `evApplyTypeDescaracterPayload` for `ACIDENTE_PESSOAL`. Note: They did NOT call `evApplyTypeDescaracterPayload` for AP because AP's block differs (per-card). But `payload.descaracter_suspect` for AP is set via `evIsDescaracterSuspectChecked()` which now returns true if global or type-root checkbox checked. Since the AP's own injured person boxes are `.ev-inj-suspect-chk`... Wait, the global checkbox id `ev_descaracter_suspect` is updated when an injured person card's `.ev-inj-suspect-chk` toggles (in the bind at 5807-5817: globalChk.checked = e.target.checked). So for AP, the suspect state lives in the cards and global checkbox is mirrored. OK.
But there's a subtle behavior change: `evIsDescaracterSuspectChecked()` now also returns true when any per-type root checkbox `.ev-type-descaracter-suspect:checked` is set, even for the wrong type. Scenario: an AP occurrence being edited while one of the per-type roots (ROS root etc.) is checked? But per-type roots only exist for ROS/QA/AM/AA. All roots exist in the DOM always, even when the current event is AP. If during an earlier action in the same page session the user had previously opened another occurrence of type ROS (in the same SPA, e.g. using the "hub", an occurrence of ROS is edited → root checked; then open an AP occurrence and populate) — if the ROS root checkbox remains checked because populate for AP does not clear it (only sets global + AP cards; the forEach sets all roots from data.descaracter_suspect). Wait populate sets ALL roots' checkbox to `suspectOn` from the current occurrence data. For an AP occurrence loaded without suspect, suspectOn=false, so the ROS root is unchecked. Since populate always applies the same suspectOn to all roots, and AP's suspect is from card; if AP has any card with suspect=1, then suspectOn = true → ROS root check also = true (but ROS root's yes-no area shown). This doesn't matter because payload for AP reads global plus injured card `.ev-inj-descaracter-comment`; note payload for AP sets `descaracter_suspect = evIsDescaracterSuspectChecked()`. If an AP occurrence has no suspect in data but user previously opened another modal without clearing global root, unlikely because the modal reloads data each time.
Hmm. Actually each time the modal is opened fresh with populate, all values reset. So cross-contamination only matters if the same modal instance switches types without repopulate, which seems unlikely since populateForEdit is called each time opening an occurrence.
However — the shared global `ev_descaracterizado` does create a genuine single-value-write problem: When creating an event, the payload assembly calls `evApplyTypeDescaracterPayload` only for the current type. But the current type may switch in the create form? Actually creation has a type selector (`ev_occurrence_type`?) Let me search the create open function to see whether type can be chosen interactively and the modal reused for different types.
Given limited time, let me nail down which findings are worth reporting and with which severity. I will produce the following comments:
### Files & comments
**1. SsmaController.php (lines ~12534-12540)** — high: new flag is derived only from type tag; drops the tenant/gestor admin role bypass and the legacy "any group (incl. team)" semantics of `ssmaMemberCanDescharacterizeAccident`; the write gate still uses the old rule. Consequence: admins/gestores and team-configured users lose UI access while backend still allows (or someone forge). Suggest aligning one rule and place a single source of truth.
Actually, let me reconsider: The purpose is to have per-type flags. Maybe the intended change is fine (only those flagged on the tag of that type can descaracterize). But the inconsistency with the server gate and the legacy `ssmaMemberCanDescharacterizeAccident` used by `applySsmaDescaracterPermissionGate` remains. Since the UI now sends `descaracterizado` for ROS/QA/AM/AA for the first time (new types), and the server gate applies broad permissions, a user can bypass type restriction by crafting the request. But is descaracterizado validated for types ROS/QA/AM/AA by validator? descaracterizado is a detail stored. Actually the validator may require descaracter comment if descaracterizado=1 and suspect. The scrubbing gate at 27421 preserves the existing value; but if new value sent and member not permitted and no existing, it falls to default "Sim" (descaracterizado = '0'). Wait lines 27425-27431 (read earlier, we saw partial). Let me re-read gate fully lines 27420-27470 for the details; we read 27408-27430. Let me read lines 27420-27480.
Tool Calls (1)
file_read
Show Details
Arguments
{"end_line": 27500, "file_path": "src/Controller/SsmaController.php", "start_line": 27420}
Result
File: src/Controller/SsmaController.php (Total lines: 27765)
IS_TRUNCATED: false
LINE_RANGE: 27420-27500
27420| $details = isset($data['details']) && is_array($data['details']) ? $data['details'] : [];
27421| if ($existingDetails !== null && array_key_exists('descaracterizado', $existingDetails)
27422| && \in_array((string) $existingDetails['descaracterizado'], ['0', '1'], true)) {
27423| // Mantém o valor já salvo anteriormente.
27424| $details['descaracterizado'] = (string) $existingDetails['descaracterizado'];
27425| } elseif (isset($data['details']['descaracterizado'])
27426| && \in_array((string) $data['details']['descaracterizado'], ['0', '1'], true)) {
27427| // Aceita o valor enviado pelo frontend se for válido.
27428| $details['descaracterizado'] = (string) $data['details']['descaracterizado'];
27429| } else {
27430| // Sem valor anterior e sem permissão: default "Sim" (é acidente = '0').
27431| // Quem não pode descaracterizar nunca poderia marcar "Não" de qualquer forma.
27432| $details['descaracterizado'] = '0';
27433| }
27434| unset($data['descaracterizado']);
27435| $data['details'] = $details;
27436|
27437| return $data;
27438| }
27439|
27440| /**
27441| * Resolve manager_id a partir de manager_name quando o front/LLM só enviou o nome.
27442| *
27443| * @param array<string, mixed> $data
27444| *
27445| * @return array<string, mixed>
27446| */
27447| private function normalizeSsmaEventManagerInDetails(array $data, Company $company): array
27448| {
27449| $details = $data['details'] ?? [];
27450| if (!is_array($details)) {
27451| return $data;
27452| }
27453|
27454| $rawId = $details['manager_id'] ?? null;
27455| if ($rawId !== null && $rawId !== '') {
27456| $details['manager_id'] = (int) $rawId;
27457| $data['details'] = $details;
27458|
27459| return $data;
27460| }
27461|
27462| $name = trim((string) ($details['manager_name'] ?? ''));
27463| if ($name === '') {
27464| return $data;
27465| }
27466|
27467| $membersById = [];
27468| $members = $this->entityManager->getRepository(CompanyMembers::class)
27469| ->findBy(['company' => $company, 'isRemoved' => 0]);
27470| foreach ($members as $cm) {
27471| if (!$cm instanceof CompanyMembers) {
27472| continue;
27473| }
27474| $memberId = (int) $cm->getId();
27475| if ($memberId <= 0) {
27476| continue;
27477| }
27478| $label = $this->ssmaMemberDisplayLabel($cm);
27479| if ($label === '') {
27480| $label = (string) ($cm->getEmail() ?? '');
27481| }
27482| if ($label !== '') {
27483| $membersById[$memberId] = ['name' => $label];
27484| }
27485| }
27486|
27487| $resolvedId = $this->resolveCompanyMemberIdByDisplayLabel($name, $membersById);
27488| if ($resolvedId > 0) {
27489| $details['manager_id'] = $resolvedId;
27490| $data['details'] = $details;
27491| }
27492|
27493| return $data;
27494| }
27495|
27496| /**
27497| * @param array<int, array<string, mixed>> $membersById
27498| *
27499| * @return array<string, mixed>
27500| */
Request #21
deepseek-v4-flash
P:67.97K C:1.68K CR:66.94K CW:0
14368ms
Reasoning
OK so the write gate semantics: for non-permitted users, if they try to set `descaracterizado` it keeps existing or defaults to '0' (Sim). The important note: "Aceita o valor enviado pelo frontend se for válido" — the branch at line 27425 handles *only* `$data['details']['descaracterizado']`; wait it's inside `if (!$can)`. So if the member cannot descaracterize, the data value is only accepted when there's no existing value but they send a value... Wait actually re-reading:
If not can:
- If existingDetails has descaracterizado (a valid '0'/'1'), keep it.
- elseif the incoming data has descaracterizado and valid → accepts the incoming value?? That contradicts the doc's claim that the frontend value is scrubbed for non-permitted users. Let me read more carefully. Wait — this elseif seems to accept value from frontend even without permission? That is weird but maybe there is a reason (e.g., non-permitted user is allowed to only set "Sim"?). Actually wait, this branch means: a non-permitted user can freely set descaracterizado as '0'/'1'. That seems a bug — the "Não" (descaracterizar) option should be blocked. Hmm but maybe the condition means it was already in the middle of an edit and data sent by the same flow; maybe in practice non-permitted never sends '1'. Whatever; this isn't part of the diff. Focus.
Wait, careful reading: If `$can` is false, we're in the "no permission" case; the branch accepts whatever value was sent. So actually server-side enforcement is extremely lax. Not our diff though.
Now reconsider precisely the controller diff:
Old code:
```php
$ssmaCanDescharacterizeAccident = $company instanceof Company
&& $this->ssmaMemberCanDescharacterizeAccident($company, $currentMemberForExport);
```
New code:
```php
$ssmaCanDescharacterizeByType = ($company instanceof Company && $currentMemberForExport)
? $this->ssmaOccurrenceTypeConfig->getDescharacterizeFlagsByType($company, (int)$currentMemberForExport->getId())
: [];
$ssmaCanDescharacterizeAccident = (bool)($ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false);
```
Old semantics: grant if ROLE_SUPER_ADMIN / ROLE_MANAGER, or member is Gestor Administrador, or member in the aprofundamento_descaracter config in any group (team or tag). Also if the member was null but platform role present, still true.
New semantics: only via per-type tags (matching occurrenceTypeKey) and requires member with id (if no member → empty map → false). Tenant/gestor admins lose.
Since `SSMA_CAN_DESCARACTERIZE` toggles whether the "Não" button is enabled in the injured-person box for AP (in the aprofundamento editing), for an admin who previously could mark Não it is now disabled/hidden. This is a regression for the admin/gestor roles. But could it be intended? The hotfix branch name "permission-descaraterzacao-ssma" suggests the intent to allow descaracterization only for members flagged on tags. In that case, the removal of the admin bypass may or may not be intentional — the PR doesn't update the server-side gate. This inconsistency (UI stricter than server, and legacy role-bypass helper still used by the gate) is a concrete issue to flag. I'll mark it high as functional/security-contract inconsistency.
Also, for the map being empty in `_ev_injured_person_box` the whole descaracter block hidden. But note: When the current member is `null` (platform admin), map empty → false. If the AP occurrence's aprofundamento is being filled by the platform admin (ROLE_MANAGER), previously the admin was able to see/act; now no. This is a likely bug if tenant admins test/approve occurrences.
Wait, hold on, though. This flag is about the person editing "acidente pessoal" in the occurrence aprofundamento. But for an actual specialist in the tag the flag must be marked in the "Descaracterizar" column for that tag. The requirement in the rules about `_modal_event.html.twig` says the UI edit permission is from server backend flags `can_aprofundamento.can_edit` and only the Sim/Não permission. This per-type descaracterization flag is separate.
OK. Another important nuance: `occurrence_view.html.twig` passes `ssmaCanDescharacterizeByType` into the modal, but `_ev_injured_person_box.html.twig` is rendered within `_modal_event.html.twig`. But in the view (occurrence detail page), the "aprofundamento" sections that show descaracterização on the page outside the modal? The `_ev_injured_person_box` is used in the event modal. Also there might be summary display elsewhere; but OK.
### Also the create flow uses index.html.twig with the modal. index.html.twig passes the map. Good.
### The `_ev_descaracter_suspect_block.html.twig` checks for `QUASE_ACIDENTE` id attribute etc.
Let me also consider JS: `evApplyTypeDescaracterPayload` sets `payload.descaracter_suspect = 0` when root exists and unchecked — a value 0 is always set (never deletes). For ROS/QA/AM/AA the old code never set `descaracter_suspect` at all (except global?). Actually previously `descaracter_suspect`? For these types, was it in payload before? Probably not (fields absent unless user had them). The server may set defaults; check if payload `descaracter_suspect=0` creates stored value '0' (which is fine semantics: no suspicion).
But importantly, for an existing ROS/QA/AM/AA occurrence where `descaracter_suspect` and `descaracter_comment` were already saved (e.g., by LLM or other editor) and the current user without tag permission opens in edit mode... Wait edit of occurrence goes through `OccurrenceModal.openEdit` and populateForEdit; the ROS root not rendered for those users. In payload assembly, `evApplyTypeDescaracterPayload` returns early without resetting. So fields stay preserved unless the server wipes them because they are absent in payload.
Actually, wait — there is another huge issue: Even when the root IS rendered (user with the tag permission), if they don't touch the checkbox, `payload.descaracter_suspect = 0` gets set, potentially erasing an existing suspect flag on every save (because the checkbox was set from the data in populate — it sets it checked based on suspectOn). Actually populate sets root chk checked = suspectOn from data, so it preserves. Good.
But when root NOT rendered: no payload field set → if server uses whole `details` replaced per fields... we can't know.
Let me examine updateEvent merge semantics to see whether missing fields wipe. In update, `data` normalized to details; server persists entire details? Let me find how details stored/merged (mergeWithExisting) around line 25527.
Tool Calls (1)
file_read
Show Details
Arguments
{"end_line": 25580, "file_path": "src/Controller/SsmaController.php", "start_line": 25480}
Result
File: src/Controller/SsmaController.php (Total lines: 27765)
IS_TRUNCATED: false
LINE_RANGE: 25480-25580
25480| }
25481|
25482| $data = json_decode($request->getContent(), true) ?? [];
25483| $aprofundamentoOnly = !empty($data['aprofundamento_only']);
25484| $existingDetails = is_array($event->getDetails()) ? $event->getDetails() : [];
25485| $aprofundamentoStatus = strtolower(trim((string) ($existingDetails['aprofundamento_status'] ?? '')));
25486| $aprofundamentoFinalized = $aprofundamentoStatus === 'finalized'
25487| || !empty($existingDetails['aprofundamento_complete']);
25488|
25489| $canFullEdit = $this->canEditSsmaEvent($company, $user, $event);
25490| $eventTypeForAccess = (string) ($data['type'] ?? $event->getType());
25491| $canAprofundamento = $this->canAccessSsmaEventAprofundamento(
25492| $company,
25493| $user,
25494| $eventTypeForAccess,
25495| is_array($data['details'] ?? null) ? $data['details'] : $existingDetails,
25496| (int) ($event->getCreatedById() ?? 0)
25497| );
25498| $isAprofundamentoUpdate = $aprofundamentoOnly
25499| || !empty($data['aprofundamento_complete'])
25500| || strtolower(trim((string) ($data['aprofundamento_status'] ?? ''))) === 'finalized';
25501|
25502| if (!$canFullEdit) {
25503| if (!$isAprofundamentoUpdate || !$canAprofundamento) {
25504| return new JsonResponse(['success' => false, 'message' => 'Você não tem autorização para editar esse tipo de ocorrência.'], 403);
25505| }
25506| if ($aprofundamentoFinalized && !$this->isSsmaAprofundamentoAdmin($company, $user)) {
25507| return new JsonResponse(['success' => false, 'message' => 'Aprofundamento finalizado. Somente um administrador ou gestor administrador pode alterar.'], 403);
25508| }
25509| $data = $this->mergeSsmaEventAprofundamentoOnlyPayload($event, $data);
25510| } else {
25511| $data = array_merge($this->eventToValidationArray($event), $data);
25512| if ($aprofundamentoFinalized && !$this->isSsmaAprofundamentoAdmin($company, $user)) {
25513| if ($aprofundamentoOnly || $isAprofundamentoUpdate) {
25514| return new JsonResponse(['success' => false, 'message' => 'Aprofundamento finalizado. Somente um administrador ou gestor administrador pode alterar.'], 403);
25515| }
25516| $data = $this->stripSsmaEventAprofundamentoFieldsFromPayload(
25517| $data,
25518| (string) ($data['type'] ?? $event->getType()),
25519| $existingDetails
25520| );
25521| }
25522| }
25523|
25524| $data = $this->normalizeSsmaEventPayload($data, $company);
25525| $data = $this->normalizeSsmaEventManagerInDetails($data, $company);
25526| $data = $this->forceSsmaRosReporterForPlainMember($data, $company, $user);
25527| $data = $this->applySsmaDescaracterPermissionGate(
25528| $data,
25529| $company,
25530| $user,
25531| $existingDetails
25532| );
25533|
25534| $eventType = (string) ($data['type'] ?? $event->getType());
25535| $eventDetails = is_array($data['details'] ?? null) ? $data['details'] : [];
25536| // Em modo só-aprofundamento o especialista já está autorizado; não stripa o que acabou de enviar.
25537| if (
25538| !$aprofundamentoOnly
25539| && !$this->canAccessSsmaEventAprofundamento($company, $user, $eventType, $eventDetails, $event->getCreatedById())
25540| && in_array($eventType, ['ROS', 'QUASE_ACIDENTE', 'ACIDENTE_PESSOAL', 'ACIDENTE_MATERIAL', 'ACIDENTE_AMBIENTAL'], true)
25541| ) {
25542| $data = $this->stripSsmaEventAprofundamentoFieldsFromPayload(
25543| $data,
25544| $eventType,
25545| $existingDetails
25546| );
25547| }
25548|
25549| // Draft vs finalize do aprofundamento (especialista / admin).
25550| $wantsFinalize = false;
25551| if ($aprofundamentoOnly || !empty($data['aprofundamento_complete']) || array_key_exists('aprofundamento_status', $data)) {
25552| $detailsOut = is_array($data['details'] ?? null) ? $data['details'] : [];
25553| $wantsFinalize = !empty($data['aprofundamento_complete'])
25554| || strtolower(trim((string) ($data['aprofundamento_status'] ?? ''))) === 'finalized';
25555| if ($wantsFinalize) {
25556| $data['aprofundamento_complete'] = true;
25557| $detailsOut['aprofundamento_complete'] = true;
25558| $detailsOut['aprofundamento_status'] = 'finalized';
25559| } else {
25560| $data['aprofundamento_complete'] = false;
25561| $detailsOut['aprofundamento_complete'] = false;
25562| $detailsOut['aprofundamento_status'] = 'draft';
25563| }
25564| $data['details'] = $detailsOut;
25565| }
25566|
25567| // Valida apenas se type ou details estiverem presentes no payload (atualização parcial ok)
25568| if (!empty($data['type']) || !empty($data['details'])) {
25569| $validator = new \App\Service\Ssma\SsmaEventValidator();
25570| $errors = $validator->validate($data, [
25571| 'allowed_type_keys' => $this->ssmaOccurrenceTypeConfig->getAllowedTypeKeys($company),
25572| 'soft_aprofundamento' => $aprofundamentoOnly && !$wantsFinalize,
25573| ]);
25574| if ($errors !== []) {
25575| return new JsonResponse(['success' => false, 'errors' => $errors], 422);
25576| }
25577| }
25578|
25579| $teamScopeErr = $this->validateSsmaEventPayloadAgainstTeamScope($data, $company, $user);
25580| if ($teamScopeErr !== null) {
Request #22
deepseek-v4-flash
P:71.35K C:784 CR:69.63K CW:0
7869ms
Reasoning
The update event path strips aprofundamento fields when user can't access, and merges `mergeSsmaEventAprofundamentoOnlyPayload`. The descaracter_suspect handling across types depends. But there's more: `stripSsmaEventAprofundamentoFieldsFromPayload` — let me read that function since it likely deletes descaracter fields. And `mergeSsmaEventAprofundamentoOnlyPayload` at ~27360.
But this may be too deep; the practical issue concerns what gets persisted when the UI root isn't rendered for a given type, but the previous data was saved. If the user edits (non-aprofundamento, general update), and the descaracter fields have already been saved into details (from an aprofundamento with an admin), then a non-flagged editor updating a general field won't wipe them, because fields come from `eventToValidationArray` for full-edit or from `strip...` merges for aprofundamento-edit. I think the existing code handles preserving. Let me not dive deeper.
Let me instead check `evIsDescaracterSuspectChecked` change: originally the code only read the global `#ev_descaracter_suspect`. That global checkbox was updated by AP cards. Now it also picks per-type roots. For ACIDENTE_PESSOAL payload, `payload.descaracter_suspect = evIsDescaracterSuspectChecked() ? 1 : 0`. If an AP card isn't checked but some other type's root is checked (because previously opened and stored as data in populate?) Actually populate applies the SAME suspectOn from this event's data to every root. If the current AP event has suspect on card, then all roots = checked. That means `payload.descaracter_suspect=1`, which mirrors suspectOn. Fine.
Now — the type-specific roots each include a checkbox `.ev-type-descaracter-suspect`, comment etc. When the event type being edited is ROS and its suspectOn = false, but ROS comment field may carry data? populate sets comment value from det.descaracter_comment || data.descaracter_comment into ALL roots (including ROS & AA etc.). Then payload descaracter_comment only set for the current type root if non-empty. If the user opens an AM occurrence whose comment is empty, but the populate step put a stored comment into the ROS root as well (since stored descaracter_comment shared by data)... Actually the data.details is per event, so there is a single descaracter_comment per event record. All roots receive the same stored comment. So only one type root matters.
OK. I'm now confident that for the payload the per-type approach is not really per-type; there's a single descaracterização state per event record (single details). Which is fine given that an event has one type.
Let me now investigate whether the modal can open without `ssmaCanDescharacterizeByType` in the view context. The `occurrence_view.html.twig` and `index.html.twig` now pass it. But is the modal also used in other templates (create flow popups) where the variable is not defined? Search includes of `_modal_event.html.twig` across templates.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "_modal_event.html.twig"}
Result
File: .opencodereview/rule.json
Match lines: 1
56| "path": "templates/ssma/occurrence/partials/_modal_event.html.twig",
File: .opencodereview/rules/ssma/occurrence-ros-aprofundamento-readonly.md
Match lines: 2
7|- `templates/ssma/occurrence/partials/_modal_event.html.twig` — `EvModal.openAprofundamento`, `evAprofundamentoCanEditFromServer`, `evCanEditAprofundamento`, `evSetAprofundamentoReadonly`
35|**Modal (`_modal_event.html.twig`):**
File: CONFLITOS_REAIS_DYNAMIC_COLOR_ICONS.md
Match lines: 1
152|- `templates/ssma/occurrence/partials/_modal_event.html.twig` ✅
File: docs/engineering/pr/feature-ssma-ocorrencia-correcoes-new-production/PR_descricao_feature-ssma-ocorrencia-correcoes-new-production.md
Match lines: 1
29|- `occurrence_view.html.twig`, `_tab_occurrences.html.twig`, `_modal_event.html.twig` — Readequação, validação, suspeita/caracterizar só para médico (`.is-doctor-aprof`), Reprovar com cor da plataforma
File: docs/engineering/pr/homolog/PR_arquivos_homolog.txt
Match lines: 1
71|M templates/ssma/occurrence/partials/_modal_event.html.twig
File: docs/engineering/pr/homolog/PR_impacto_homolog.txt
Match lines: 1
71| .../occurrence/partials/_modal_event.html.twig | 54 +++-
File: docs/engineering/pr/hotfix-ssma-ambiental-material-brenda-new-production/PR_descricao_hotfix-ssma-ambiental-material-brenda-new-production.md
Match lines: 2
41|- Formulário compartilhado `_modal_event.html.twig` — listagem e detalhe.
84|| `_modal_event.html.twig` | AA nativo, barreiras, consequências, AP, ROS/QA, exclusão envolvido/testemunha |
File: docs/engineering/pr/hotfix-ssma-ap-validacao-etapa1-new-production/PR_arquivos_hotfix-ssma-ap-validacao-etapa1-new-production.txt
Match lines: 1
225|M templates/ssma/occurrence/partials/_modal_event.html.twig
File: docs/engineering/pr/hotfix-ssma-ap-validacao-etapa1-new-production/PR_descricao_hotfix-ssma-ap-validacao-etapa1-new-production.md
Match lines: 1
45|| `_modal_event.html.twig` | Etapa 1 não envia campos técnicos para Membro; botão **Registrar**; validação só do passo ativo; labels humanizadas nos toasts |
File: docs/engineering/pr/hotfix-ssma-ap-validacao-etapa1-new-production/PR_impacto_hotfix-ssma-ap-validacao-etapa1-new-production.txt
Match lines: 1
225| .../occurrence/partials/_modal_event.html.twig | 1821 ++++++++----
File: docs/engineering/pr/hotfix-ssma-occ-type-perms-datatables-new-production/PR_arquivos_hotfix-ssma-occ-type-perms-datatables-new-production.txt
Match lines: 1
7|M templates/ssma/occurrence/partials/_modal_event.html.twig
File: docs/engineering/pr/hotfix-ssma-occ-type-perms-datatables-new-production/PR_descricao_hotfix-ssma-occ-type-perms-datatables-new-production.md
Match lines: 2
36|- Formulário compartilhado `_modal_event.html.twig` (create/update de ocorrências e aprofundamento).
93|| `templates/ssma/occurrence/partials/_modal_event.html.twig` | `EvModal.openAprofundamento`, botões rascunho/finalizar, payload `aprofundamento_only` |
File: docs/engineering/pr/hotfix-ssma-occ-type-perms-datatables-new-production/PR_impacto_hotfix-ssma-occ-type-perms-datatables-new-production.txt
Match lines: 1
7| .../occurrence/partials/_modal_event.html.twig | 146 ++++++-
File: docs/engineering/pr/hotfix-ssma-ros-barrier-type-422/PR_descricao_hotfix-ssma-ros-barrier-type-422.md
Match lines: 1
50|| Flash report | `occurrence_view.html.twig`, `_modal_event.html.twig`, `_tab_config.html.twig`, `new_automation.html.twig` |
File: docs/engineering/pr/hotfix-ssma-ux-pos-merge-231-new-production/PR_arquivos_hotfix-ssma-ux-pos-merge-231-new-production.txt
Match lines: 1
7|M templates/ssma/occurrence/partials/_modal_event.html.twig
File: docs/engineering/pr/hotfix-ssma-ux-pos-merge-231-new-production/PR_impacto_hotfix-ssma-ux-pos-merge-231-new-production.txt
Match lines: 1
7| .../occurrence/partials/_modal_event.html.twig | 35 +-
File: docs/engineering/pr/new_staging2/PR_arquivos_new_staging2.txt
Match lines: 1
1631|M templates/ssma/occurrence/partials/_modal_event.html.twig
File: docs/engineering/pr/new_staging2/PR_impacto_new_staging2.txt
Match lines: 1
1631| .../occurrence/partials/_modal_event.html.twig | 162 +-
File: docs/logs/engineering/frontend_console_inventory.md
Match lines: 1
794|| templates/ssma/occurrence/partials/_modal_event.html.twig | templates | nao | 2 | 0 | 2 | 0 | 0 | 0 | 0 |
File: docs/pr-hotfix-ssma-ap-parte-medica-new-production.md
Match lines: 1
25|| Alterado | `templates/ssma/occurrence/partials/_modal_event.html.twig` |
File: docs/ssma/ALINHAMENTO-TITULO-OPCIONAL-E-MEMBROS-SEM-ADMIN.md
Match lines: 2
229|- UI: `_modal_event.html.twig` — esconder `#ev-gravity-wrap` nos tipos com `#ev_consequence`; mostrar badge/read-only de gravidade no bloco de classificação técnica.
269|- UI: `_modal_event.html.twig` — opções de `#ev_work_leave` + filtro/auto-select do select de classificação ao mudar afastamento.
File: docs/ssma/CORRECOES-FECHAMENTO-FIGMA-PENDENTES.md
Match lines: 3
38|**Onde:** `templates/ssma/occurrence/partials/_modal_event.html.twig` (`ev_datetime`, `evDefaultDatetimeToday`).
95|| 3 | `_modal_event.html.twig` |
97|| 5 | `_modal_event.html.twig`, `SsmaController.php`, `SsmaEventValidator.php` |
File: docs/ssma/CORRECOES-OCORRENCIA-FIGMA-PARTE-2.md
Match lines: 1
46|- UI: `_modal_event.html.twig` / `_modal_occurrence.html.twig` (`SSMA_IS_AURA_ADMIN`, hide na criação).
File: docs/ssma/PAINEL-OCORRENCIAS-INDICADORES-PLANO.md
Match lines: 1
377|| Classificação FAC/LTI/RWC/MTC | `_modal_event.html.twig` → `#ev_injury_classification`; persistido em `SsmaEvent.details.injury_classification` |
File: docs/ssma/PRODUTO_SSMA_MAPA_COMPLETO.md
Match lines: 2
199|3. No offcanvas **Evento SSMA** (`_modal_event.html.twig`): escolher tipo (ROS, Quase acidente, Acidente pessoal/material/ambiental).
219|| Criar/editar evento | `_modal_event.html.twig` |
File: docs/ssma/ocorrencia-01-colab-acidentado-pessoas-envolvidas.md
Match lines: 1
21|| Filtro do select | `evFilterInjuredPersonSelect()` em `_modal_event.html.twig` |
File: templates/ssma/occurrence/index.html.twig
Match lines: 1
114| {% include 'ssma/occurrence/partials/_modal_event.html.twig' with {
File: templates/ssma/occurrence/occurrence_view.html.twig
Match lines: 1
1308| {% include 'ssma/occurrence/partials/_modal_event.html.twig' with {
File: templates/ssma/occurrence/partials/_modal_occurrence.html.twig
Match lines: 1
2|{# Modal legado (listagem/detalhe). Fluxo principal de registro: _modal_event.html.twig (offcanvas tipado). #}
File: templates/ssma/occurrence/tabs/_tab_occurrences.html.twig
Match lines: 1
1891| // ── Open "Nova ocorrência" offcanvas (implementação em _modal_event.html.twig) ──
File: templates/ssma/partials/_ssma_body_map_entry.html.twig
Match lines: 1
9| - occurrence/partials/_modal_event.html.twig → Novo evento / edição
File: tests/Ssma/ValidateLocalFixesTest.php
Match lines: 2
18| * 2. _modal_event.html.twig — todos os <option value> batem com EnvironmentalMediumEnum
87| // Exatamente as <option value="..."> de _modal_event.html.twig para ACIDENTE_AMBIENTAL
File: tests/Unit/Product/Ssma/SsmaBodyMapEntryRegressionTest.php
Match lines: 1
46| $modal = $this->read('templates/ssma/occurrence/partials/_modal_event.html.twig');
File: tests/Unit/Product/Ssma/assert_branch_ui_fixes.php
Match lines: 2
40|$modal = $root . '/templates/ssma/occurrence/partials/_modal_event.html.twig';
201|$modalEvent = $root . '/templates/ssma/occurrence/partials/_modal_event.html.twig';
File: tests/Unit/Product/Ssma/assert_flash_report_flow.php
Match lines: 1
140|$modalEvent = $root . '/templates/ssma/occurrence/partials/_modal_event.html.twig';
code_search
Show Details
Arguments
{"search_text": "include 'ssma/occurrence/partials/_ev_injured_person_box.html.twig'"}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 1
671| {% include 'ssma/occurrence/partials/_ev_injured_person_box.html.twig' with {
Request #23
deepseek-v4-flash
P:74.74K C:565 CR:72.06K CW:0
4874ms
Reasoning
`_modal_event.html.twig` is included from only index.html.twig and occurrence_view.html.twig — both updated with the map. Good; no missing variable from the include perspective (the include always gets `ssmaCanDescharacterizeByType`).
But wait: index.html.twig and occurrence_view.html.twig receive data from buildSsmaViewData (a huge action). It will always pass `ssmaCanDescharacterizeByType` now. Good.
However — are there contexts where occurrence_view.html.twig is rendered with detailScope etc.? It should always have the key now.
Wait: What about the include of `_ev_descaracter_suspect_block` inside `_modal_event.html.twig` at line 462 etc. It's included for ROS, QA, AM, AA with the variable `ssmaCanDescharacterizeByType|default({})`. But inside `_modal_event.html.twig`, is `ssmaCanDescharacterizeByType` defined at the top? It is only passed as a parameter to the include of the partial (from index/occurrence_view). Inside _modal_event.html.twig, the included partial references `ssmaCanDescharacterizeByType|default({})` which reads from the template context (inherited from page-level includes). Since `_modal_event.html.twig` is included with `ssmaCanDescharacterizeByType: ...` variable? Let's look at index.html.twig & occurrence_view lines: they include _modal_event with `ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})`. In the earlier diff for index.html.twig, they added `ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})` inside the same `include` call? Let's check index line 114-126.
Tool Calls (2)
file_read
Show Details
Arguments
{"end_line": 135, "file_path": "templates/ssma/occurrence/index.html.twig", "start_line": 108}
Result
File: templates/ssma/occurrence/index.html.twig (Total lines: 135)
IS_TRUNCATED: false
LINE_RANGE: 108-135
108|
109| {# Modais no fim do section — evita espaço fantasma acima do .modern-header sticky #}
110| {% set _membersForModal = ssma_apply_team_event_scope|default(false) ? all_members_for_event_people|default([]) : allMembers|default([]) %}
111| {% set _gestoresForModal = gestores_for_event_modal|default(gestores|default([])) %}
112| {% set _teamsForModal = teams_for_event_modal|default(teams|default([])) %}
113| {% include 'ssma/occurrence/partials/_modal_classify.html.twig' %}
114| {% include 'ssma/occurrence/partials/_modal_event.html.twig' with {
115| allMembers: _membersForModal,
116| allMembersForMeta: allMembers|default([]),
117| gestores: _gestoresForModal,
118| teams: _teamsForModal,
119| occurrence_type_config: occurrence_type_config|default({ types: [] }),
120| ssma_event_form_defaults: ssma_event_form_defaults|default({}),
121| user_technical_types: user_technical_types|default([]),
122| ssmaCanManageOccurrences: ssmaCanManageOccurrences|default(false),
123| ssma_hide_event_title_status_on_create: ssma_hide_event_title_status_on_create|default(false),
124| ssmaCanRegisterNewOccurrence: ssmaCanRegisterNewOccurrence|default(false),
125| ssmaAllowedCreateTypes: ssmaAllowedCreateTypes|default([]),
126| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
127| } %}
128|</section>
129|{% endblock %}
130|
131|{% block javascripts %}
132|{{ parent() }}
133|{# Botões "+ Evento" / "+ ROS": handler em _tab_occurrences e _modal_event — abre offcanvas tipado #}
134|{% endblock %}
135|
file_read
Show Details
Arguments
{"end_line": 1330, "file_path": "templates/ssma/occurrence/occurrence_view.html.twig", "start_line": 1305}
Result
File: templates/ssma/occurrence/occurrence_view.html.twig (Total lines: 3226)
IS_TRUNCATED: false
LINE_RANGE: 1305-1330
1305| {% set _membersForModal = ssma_apply_team_event_scope|default(false) ? all_members_for_event_people|default([]) : allMembers|default([]) %}
1306| {% set _gestoresForModal = gestores_for_event_modal|default(gestores|default([])) %}
1307| {% set _teamsForModal = teams_for_event_modal|default(teams|default([])) %}
1308| {% include 'ssma/occurrence/partials/_modal_event.html.twig' with {
1309| allMembers: _membersForModal,
1310| allMembersForMeta: allMembers|default([]),
1311| gestores: _gestoresForModal,
1312| teams: _teamsForModal,
1313| occurrence_type_config: occurrence_type_config|default({ types: [] }),
1314| ssma_event_form_defaults: ssma_event_form_defaults|default({}),
1315| user_technical_types: user_technical_types|default([]),
1316| ssmaCanManageOccurrences: ssmaCanManageOccurrences|default(false),
1317| ssma_hide_event_title_status_on_create: ssma_hide_event_title_status_on_create|default(false),
1318| ssmaCanRegisterNewOccurrence: ssmaCanRegisterNewOccurrence|default(false),
1319| ssmaAllowedCreateTypes: ssmaAllowedCreateTypes|default([]),
1320| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
1321| } %}
1322| {% if can_edit_occurrence|default(false) %}
1323| {% include 'ssma/occurrence/partials/_modal_occurrence.html.twig' %}
1324| {% endif %}
1325|{% endif %}
1326|
1327|{# Modal: vincular ação a um plano de ação (detalhe da ocorrência). IDs com prefixo ssmaOccView* para não colidir com #ssmaLinkProjectModal da aba Plano de Ação. #}
1328|<div class="modal fade" id="ssmaOccViewLinkProjectModal" tabindex="-1" role="dialog" aria-labelledby="ssmaOccViewLinkProjectModalLabel" aria-hidden="true">
1329| <div class="modal-dialog modal-dialog-centered" role="document">
1330| <div class="modal-content">
Request #24
deepseek-v4-flash
P:76.41K C:1.15K CR:75.26K CW:0
11076ms
Reasoning
OK.
Now consider the default `ssmaCanDescharacterizeByType` when the user has no company/member context: `[]`. Then in the Twig `_ev_injured_person_box`, `ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']` with `default(false)` — careful: In Twig, accessing array key that doesn't exist with `['KEY']` then `default(false)` is fine: `ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']|default(false)`.
But there's a subtle Twig issue: for the `_ev_descaracter_suspect_block`, `{% if ssmaCanDescharacterizeByType[_type_key]|default(false) %}`. Fine.
Now, when map empty [] and the old code path used to treat admins as allowed. So the whole AP descaracter section hidden for admins. Also, SSMA_CAN_DESCARACTERIZE = false for them.
Let's identify real consequences precisely.
Actually one crucial consequence: `SSMA_CAN_DESCARACTERIZE` also controls the ability to click "Não" but ALSO when false the JS pre-selects `descaracterizado = '0'` in the aprofundamento mode for AP when field empty (as in `evSyncDescaracterUi` line 2986-2992). The AP flow still displays suspect check and per-card details for those without the flag but they cannot answer Não (button disabled). Now the whole block hidden for those without tag membership. But also the legacy description: "Sem permissão → não mostra S/N (mensagem de sem permissão)". Actually doc says without permission, show banner with "Sem permissão...". The old template had `ev-inj-descaracter-no-perm` (message shown when not canSn).
So the new behavior removes that whole section for anyone not on the type's tag descaracter list, including for people who can access the aprofundamento (tag members) but are not in the descaracter column. Previously, such a specialist could mark the suspicion checkbox, which triggers the red "SUSPEITA DE DESCARACTERIZAÇÃO" banner. Actually where's the banner logic? The user story "suspeita → texto vermelho". This whole behavior is gated now.
Is this per-type restriction intended? Possibly: for types ROS/QA/AM/AA it's new feature. For AP it reduces who can raise suspicion. Note the removed comment explicitly said "Suspeita editável por qualquer especialista AP; Sim/Não só quem tem permissão Descaracterizar." So yes — this is a behavior change: previously any specialist AP could raise suspicion (suspeita), regardless of descaracter permission; now only members flagged on the tag's Descaracterizar column can even raise suspicion. This is worth flagging as likely unintended/scope. Good — this is one of the review-plan issues #5.
But wait — is there any independent place where a specialist (not in the descaracter column) can still raise suspicion? `_ev_injured_person_box` is the only place for AP. So suspicion capture is removed for specialists not flagged in the column. For types ROS/QA/AM/AA, this is a new feature only for flagged.
Now think about the "suspeita" red banner for viewing: when a specialist is viewing occurrence read-only and the record has `descaracter_suspect = 1`, the UI would show red text based on saved data. That logic is elsewhere.
Now #6 of the review plan mentions that all roots share the global hidden field `ev_descaracterizado` and suspect flag mirrors. The observation about cross-type data corruption relies on multiple type blocks being present and switchable in the same modal. Let me check whether the modal is reused and type sections toggled when `type` changes. Since the type is chosen at creation from a list and the modal opens the proper technical section (only one). And editing an occurrence has fixed type. So the actual bug (payload contamination) probably doesn't manifest — unless the user changes the type of the occurrence via the type select in edit. Let me search `id="ev_spec_type"`? No matches. Search for 'selected type' in the modal: e.g., functions like `evTypeKey()`. Hmm search 'evSelectedType'.
Actually there's likely a field that stores the type at form load: `ev_type_key` hidden. Since the create flow opens directly with a chosen type and you can't change it mid-way (probably). Let me do a targeted search for '.ev-occ-type-section' or `data-ev-type-section`.
Tool Calls (2)
code_search
Show Details
Arguments
{"file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"], "search_text": "ev-type-spec-card"}
Result
No matches found
code_search
Show Details
Arguments
{"file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"], "search_text": "data-type-card"}
Result
No matches found
Request #25
deepseek-v4-flash
P:77.58K C:220 CR:77.44K CW:0
2693ms
Reasoning
Let me find how these per-type sections are shown. Look at the structure around line 300-540 of the modal to understand the sections and their visibility, and find JS that toggles them (evShowSpecType? evTechnicalSection). Let's search for `ev-spec-type` in this file.
Tool Calls (2)
code_search
Show Details
Arguments
{"file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"], "search_text": "ev-spec-type"}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 5
406| <div class="card app-card-surface p-3 mb-3 d-none" id="ev-spec-type-card">
407| <h5 class="ssma-form-section text-primary mb-3 d-none" id="ev-spec-type-card-title" aria-hidden="true">Campos do tipo</h5>
545| </div>{# /ev-spec-type-card #}
3351| '#ev-spec-type-card input, #ev-spec-type-card select, #ev-spec-type-card textarea,' +
5109| var specCard = document.getElementById('ev-spec-type-card');
code_search
Show Details
Arguments
{"file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"], "search_text": "function evShowTypeSections"}
Result
No matches found
Request #26
deepseek-v4-flash
P:77.98K C:139 CR:77.7K CW:0
1895ms
Reasoning
Let me look around 5100-5200 for how the spec card shows; and identify whether multiple type sub-sections are mutually exclusive and whether type can change. Read 5080-5260.
Tool Calls (1)
file_read
Show Details
Arguments
{"end_line": 5320, "file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 5080}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 5080-5320
5080| var locationCol = document.querySelector('#form-event-new .ev-location-stack-col');
5081| if (locationCol) {
5082| locationCol.classList.remove('ev-location-stack-col--gmr-beside-category');
5083| }
5084| }
5085|
5086| function applyTypeBlock(type) {
5087| // Hide all spec blocks
5088| Object.values(typeBlockMap).forEach(function (ids) {
5089| ids.forEach(function (id) {
5090| var el = document.getElementById(id);
5091| if (el) el.classList.add('d-none');
5092| });
5093| });
5094|
5095| // Show spec block for selected type
5096| var hasBlock = !!(typeBlockMap[type] && typeBlockMap[type].length);
5097| if (hasBlock) {
5098| typeBlockMap[type].forEach(function (id) {
5099| var el = document.getElementById(id);
5100| if (el) el.classList.remove('d-none');
5101| });
5102| }
5103|
5104| // AA: revelar Meio/Poluente/Volume/Contenção imediatamente (antes do restante do sync).
5105| evSyncAaIdentFields(type);
5106|
5107| // Mostrar card só quando algum bloco de especificação ficou visível (evita card vazio)
5108| // O card só deve aparecer para ROS e QUASE_ACIDENTE — acidentes têm seus campos no passo de aprofundamento
5109| var specCard = document.getElementById('ev-spec-type-card');
5110| if (specCard) {
5111| var specCardBlockIds = ['ev-block-ros', 'ev-block-qa'];
5112| var hasVisibleSpec = specCardBlockIds.some(function (id) {
5113| var el = document.getElementById(id);
5114| return el && !el.classList.contains('d-none');
5115| });
5116| specCard.classList.toggle('d-none', !hasVisibleSpec);
5117| }
5118|
5119| var techSection = document.getElementById('ev-technical-section');
5120| if (techSection) {
5121| techSection.classList.toggle('d-none', !evRequiresAccidentTechnical(type));
5122| }
5123| var corrSection = document.getElementById('ev-corrective-actions-section');
5124| if (corrSection) {
5125| corrSection.classList.toggle('d-none', !evRequiresAprofundamento(type));
5126| }
5127|
5128| // Filter consequence dropdown
5129| filterConsequenceByType(type);
5130| ensureClassificationDefaults(type);
5131| evUpdateAprofundamentoTitle(type);
5132| evUpdateStepsBarVisibility(type);
5133| evSyncGmrPosition(type);
5134|
5135| var generalCardsWrap = document.getElementById('ev-step-general-cards');
5136| if (generalCardsWrap) {
5137| generalCardsWrap.classList.toggle('ev-type-ros-layout', type === 'ROS');
5138| }
5139|
5140| // ROS (criação "Novo ROS"): o card Identificação fica vazio (tipo/título ocultos) — esconde o bloco.
5141| var identCard = document.getElementById('ev-card-identificacao');
5142| if (identCard) {
5143| var titleRow = document.getElementById('ev-title-status-row');
5144| var titleVisible = titleRow && !titleRow.classList.contains('d-none');
5145| var typeVisible = !(document.getElementById('ev_type_wrap') || { classList: { contains: function () { return true; } } }).classList.contains('d-none');
5146| var aaVisible = (function () {
5147| var aa = document.getElementById('ev-aa-ident-fields');
5148| return aa && !aa.classList.contains('d-none');
5149| })();
5150| var hideIdent = type === 'ROS' && !titleVisible && !typeVisible && !aaVisible;
5151| identCard.classList.toggle('d-none', hideIdent);
5152| identCard.classList.toggle('ev-ident-empty', hideIdent);
5153| }
5154|
5155| // QA: re-apply person row toggle + consequência potencial
5156| if (type === 'QUASE_ACIDENTE') {
5157| toggleQaPersonRow();
5158| if (typeof filterQaPotentialConsequence === 'function') {
5159| filterQaPotentialConsequence();
5160| }
5161| }
5162|
5163| // ROS: re-apply potential consequence filter
5164| if (type === 'ROS') {
5165| filterRosPotentialConsequence();
5166| }
5167|
5168| // Ao mudar tipo, sincroniza visibilidade do bloco de regiões
5169| if (type === 'ACIDENTE_PESSOAL') {
5170| syncBodyRegionVisibility();
5171| if (evHadInjuryForValidation()) {
5172| evEnsureBodyMapForCard(evGetActiveInjuredCardForBodyMap());
5173| }
5174| evSyncInjuredCardsFromInvolved();
5175| } else {
5176| var bmb = document.getElementById('ev-body-map-block');
5177| if (bmb) bmb.classList.add('d-none');
5178| }
5179|
5180| if (typeof window.renderEvCategorySelect === 'function') {
5181| window.renderEvCategorySelect(type, '');
5182| }
5183| evSyncReportedByFieldForType(type);
5184| evSyncCriticalityField(type);
5185| evSetAprofundamentoReadonly(!evRequiresAprofundamento(type) || !evCanEditAprofundamento(type));
5186| evSyncAccidentCostFields(type || '');
5187| evUpdateFooter();
5188| }
5189|
5190| /**
5191| * ROS — "Gestor responsável" passa a ser "Relatado por":
5192| * - Pessoa física comum (Membro): campo oculto (ela é a relatora).
5193| * - Gestor: pré-seleciona a si mesmo e pode trocar.
5194| * Para os demais tipos, mantém o comportamento original ("Gestor responsável").
5195| */
5196| function evSyncReportedByFieldForType(type) {
5197| var wrap = document.getElementById('ev-manager-field-wrap');
5198| var labelEl = document.getElementById('ev-manager-label-text');
5199| var sel = document.getElementById('ev_manager');
5200| if (!wrap || !sel) return;
5201|
5202| if (sel.dataset.origRequired === undefined) {
5203| sel.dataset.origRequired = sel.required ? '1' : '0';
5204| }
5205|
5206| if (type !== 'ROS') {
5207| if (labelEl) labelEl.textContent = 'Gestor responsável';
5208| wrap.classList.remove('d-none');
5209| sel.required = sel.dataset.origRequired === '1';
5210| return;
5211| }
5212|
5213| if (labelEl) labelEl.textContent = 'Relatado por';
5214|
5215| if (window.SSMA_IS_PESSOA_FISICA_COMUM_USER) {
5216| wrap.classList.add('d-none');
5217| sel.required = false;
5218| if (EV_LOGGED_MEMBER_ID) {
5219| // Garante reporter = usuário logado mesmo com campo oculto.
5220| var hasOpt = false;
5221| for (var i = 0; i < sel.options.length; i++) {
5222| if (String(sel.options[i].value) === String(EV_LOGGED_MEMBER_ID)) {
5223| hasOpt = true;
5224| break;
5225| }
5226| }
5227| if (!hasOpt) {
5228| var opt = document.createElement('option');
5229| opt.value = String(EV_LOGGED_MEMBER_ID);
5230| opt.textContent = 'Eu';
5231| sel.appendChild(opt);
5232| }
5233| sel.value = String(EV_LOGGED_MEMBER_ID);
5234| if (window.jQuery) { window.jQuery(sel).trigger('change'); }
5235| }
5236| return;
5237| }
5238|
5239| wrap.classList.remove('d-none');
5240| sel.required = sel.dataset.origRequired === '1';
5241|
5242| // Gestor: pré-seleciona a si mesmo (se ainda não houver seleção — não sobrescreve edição).
5243| if (window.SSMA_IS_GESTOR_USER && !window.SSMA_IS_TENANT_ADMIN_USER && !sel.value && EV_LOGGED_MEMBER_ID) {
5244| for (var j = 0; j < sel.options.length; j++) {
5245| if (String(sel.options[j].value) === String(EV_LOGGED_MEMBER_ID)) {
5246| sel.value = String(EV_LOGGED_MEMBER_ID);
5247| if (window.jQuery) { window.jQuery(sel).trigger('change'); }
5248| break;
5249| }
5250| }
5251| }
5252| }
5253|
5254| /** De-para 1:1 — 5 consequências pessoais ↔ 5 níveis de gravidade. */
5255| var EV_CONSEQUENCE_TO_CRITICALITY = {
5256| SEM_DANO: 'LEVE',
5257| LESAO_LEVE: 'BAIXO',
5258| LESAO_MODERADA: 'MEDIO',
5259| LESAO_GRAVE: 'ALTO',
5260| FATALIDADE: 'SEVERO',
5261| DANO_MATERIAL_LEVE: 'LEVE',
5262| DANO_MATERIAL_MODERADO: 'BAIXO',
5263| DANO_MATERIAL_GRAVE: 'ALTO',
5264| PARADA_OPERACIONAL: 'SEVERO',
5265| CONTAMINACAO_AGUA: 'ALTO',
5266| CONTAMINACAO_SOLO: 'ALTO',
5267| POLUICAO_AR: 'ALTO',
5268| AA1: 'LEVE',
5269| AA2: 'MEDIO',
5270| AA3: 'SEVERO',
5271| // Pessoal / Material: consequência = escala de gravidade
5272| LEVE: 'LEVE',
5273| BAIXO: 'BAIXO',
5274| MEDIO: 'MEDIO',
5275| ALTO: 'ALTO',
5276| SEVERO: 'SEVERO'
5277| };
5278| function evResolvePotentialSeverity() {
5279| for (var i = 0; i < arguments.length; i++) {
5280| var v = String(arguments[i] || '').toUpperCase();
5281| if (!v) continue;
5282| if (EV_CONSEQUENCE_TO_CRITICALITY[v]) return EV_CONSEQUENCE_TO_CRITICALITY[v];
5283| if (EV_CRITICALITY_LABELS[v]) return v;
5284| }
5285| return '';
5286| }
5287| var EV_CRITICALITY_LABELS = {
5288| LEVE: 'Leve', BAIXO: 'Baixo', MEDIO: 'Médio', ALTO: 'Alto', SEVERO: 'Severo',
5289| MODERADO: 'Moderado', CRITICO: 'Crítico'
5290| };
5291| var EV_CRITICALITY_COLORS = {
5292| LEVE: { bg: 'rgba(37,173,82,0.12)', color: '#25AD52', border: '#25AD52' },
5293| BAIXO: { bg: 'rgba(37,173,82,0.12)', color: '#25AD52', border: '#25AD52' },
5294| MEDIO: { bg: 'rgba(255,193,7,0.15)', color: '#B78103', border: '#FFC107' },
5295| MODERADO: { bg: 'rgba(255,193,7,0.15)', color: '#B78103', border: '#FFC107' },
5296| ALTO: { bg: 'rgba(253,126,20,0.14)', color: '#FD7E14', border: '#FD7E14' },
5297| SEVERO: { bg: 'rgba(234,21,28,0.12)', color: '#EA151C', border: '#EA151C' },
5298| CRITICO:{ bg: 'rgba(234,21,28,0.12)', color: '#EA151C', border: '#EA151C' }
5299| };
5300|
5301| /** Gravidade: acidentes, ROS e Quase Acidente derivam da consequência. */
5302| function evSyncCriticalityField(type) {
5303| var wrap = document.getElementById('ev-gravity-wrap');
5304| var sel = document.getElementById('ev_criticality');
5305| var derivedWrap = document.getElementById('ev-derived-severity-wrap');
5306| var rosDerivedWrap = document.getElementById('ev-ros-derived-severity-wrap');
5307| var qaDerivedWrap = document.getElementById('ev-qa-derived-severity-wrap');
5308| if (!sel) return;
5309| var isAccident = evRequiresAccidentTechnical(type);
5310| var isRos = type === 'ROS';
5311| var isQa = type === 'QUASE_ACIDENTE';
5312| if (wrap) {
5313| wrap.classList.add('d-none');
5314| }
5315| sel.required = false;
5316| if (derivedWrap) derivedWrap.classList.toggle('d-none', !isAccident);
5317| if (rosDerivedWrap) rosDerivedWrap.classList.toggle('d-none', !isRos);
5318| if (qaDerivedWrap) qaDerivedWrap.classList.toggle('d-none', !isQa);
5319| if (isAccident) {
5320| evSyncDerivedSeverityFromConsequence();
Request #27
deepseek-v4-flash
P:81.63K C:1.84K CR:78.08K CW:0
16901ms
Reasoning
`applyTypeBlock(type)` toggles visibility by type. It seems the type is fixed during a given modal session. There is probably a type select in general step, but once you choose the occurrence type, changing may require confirmation. I'll not pursue.
OK. Time to decide. I have enough concrete issues. Let me also spot-check that the new service methods may cause an N+1 style extra query per type key per page load. Five `findBy` queries per request even when not needed (e.g., config pages that call buildSsmaViewData too, because the new computation is in buildSsmaViewData used by ALL ssma views). Wait — does buildSsmaViewData run for the whole "ssma index"? buildSsmaViewData is the method for the occurrence hub & occurrence view; also possibly other pages call it? Only controller methods presumably for the occurrence hub and the detail view (both templates reviewed). It's a per-user page-load cost, small. I'll mention as low priority; may not warrant a comment due to "precision over recall" and performance comments only with evidence of meaningful scale. The extra cost is 5 tiny queries per occurrence page render — worth noting but not blocking. Possibly skip.
Actually wait — there's a subtle but important bug: the flags are computed based on `$currentMemberForExport` — the member of the *logged user*. But this action and buildSsmaViewData might be called with "viewing another member"? Probably the permission is for the logged-in user editing occurrences; the descaracter blocks in the modal are about the person editing. So the member check is correct per-user. OK.
There's another possible issue: When a company admin opens the modal to create/register on behalf of a company with no fixed tags created (never opened the permissions-tag page), then all blocks for ROS/QA/AM/AA hidden and AP block hidden (unless legacy config team/tag still matches). But wait AP block also requires `SsmaPermissionTag` rows with type ACIDENTE_PESSOAL AND member in the descaracter column. So for companies that only ever configured legacy team-level descaracter flags, the entire UI block disappears. But is it possible to config the descaracter column "tag:{id}" for a tag that doesn't exist? The column config for tag requires selecting a tag first, and tags exist only when created via ensureFixedTechnicalTagsForCompany in the permission-tag management page. So the legacy flow pre-required the tag to exist for tag-based config. So tags exist where tag-based grants were set. But if companies relied on team-level descaracter grants (which old memberCanDescharacterizeAccident honored), then these members lose UI ability to descaracterize now.
Wait, but is the "team" descaracter grant actually a separate per-type thing? In the config UI for team it may be just one flag "pode descaracterizar" across the whole team (not per-type). Actually descaracterizar was AP-only historically? Old doc: descaracterização only applies to AP. Now they've expanded to other types with per-type flags. The team-level descaracter flag in the team config may have been intended for AP only. Under the new scheme, for AP type, they need the tag. The legacy team-level config is simply no longer sufficient. Hmm, but was the "team" config used at all? The controller reads `getAprofundamentoDescaracterMemberIds($company, 'team', $teamId)` for a team view — yes. So team-based members could have can_descaracterize=1. With new logic, a team-based member (not in any tag) would lose UI access even for AP. So regression risk.
OK. I've spent enough; decide which comments to file. Let me weigh to keep the response concise and non-duplicative, and precise:
I'll file code_comment items:
1. **Controller** (line 12534-12540): Behaviour change/divergence — high. New per-type flag drops the role bypass (ROLE_SUPER_ADMIN/ROLE_MANAGER/gestor admin) and team-level grants that the old helper had; server-side write gate still uses the old helper, so UI (e.g., `SSMA_CAN_DESCARACTERIZE`, blocks de descaracterização) fica mais restrito que o backend para admins. Result: tenant/gestor admin perde UI descaracterizar no AP enquanto backend ainda autorizaria; os dois critérios divergem. Suggest centralize single source in service and decide (keep role bypass for all types or align gate). Might be medium/high.
2. **Service method `memberCanDescharacterizeForType`** (740-760): semantics narrowed vs `memberCanDescharacterizeAccident` — the new method only checks tag groups of the exact `occurrenceTypeKey` and requires the tag row to exist in DB. Two consequences: (a) grants via "team" group and legacy tags with null type key stop counting (silent permission removal for those users in UI); (b) if company never created fixed tags (`ensureFixedTechnicalTagsForCompany` only runs in specific page), map stays false for everyone. Needs review/decision/migration. Medium/high.
3. **Duplicated authorization logic across service (old memberCanDescharacterizeAccident vs new per-type)** — medium maintainability: multiple criteria for the same policy. Suggest the old method delegate to the new by-type map (e.g., any type true) so there is a single source of truth; avoids future divergence (like #1).
4. **`_ev_injured_person_box.html.twig`** (lines 191-192): For AP, previously any specialist in the aprofundamento could tick "Há suspeita..." even without permission to descaracterize (the S/N was gated separately by disabling the Não button). Now, the whole block is hidden unless the user is on the Descaracterizar column of the AP tag; a specialist not flagged loses the ability to register suspicion, and (worse) while viewing an AP occurrence that already has `descaracter_suspect` stored they'd no longer see the state. Confirm it's intentional: could regress legit "suspeita" flagging. Medium.
5. **JS `evApplyTypeDescaracterPayload` reads global hidden** (2940) - and root click writes to the global hidden; per-type visual active state isn't restored when editing a saved record (populate sets checkbox and comment but never restores Sim/Não button selection nor syncs `descaracterizado` per root). And if modal reused across types, stale global hidden could leak. But I need to be precise. Two sub-claims:
a. Loading an existing ROS/QA/AM/AA record: the saved `descaracterizado` is only set in the global hidden; the per-type Sim/Não button visuals aren't reflected. So the user sees suspect checked but neither Sim nor Não active though the record has an answer — and if they click only suspect then save, hidden retains old value... OK.
b. Cross-type contamination: the click handler on a type root writes global hidden and the payload assembly reads that same global for any type; with multiple roots present in the DOM this single global stores only the last value. If a user starts an AM occurrence and chooses Não, then the modal re-used for an AA occurrence without full reload (e.g., open "Nova ocorrência" twice within the same page session without re-init), hidden may leak. But openCreate probably clears the hidden. Let me check openCreate resets ev_descaracterizado. Let me search for openCreate / reset function of the modal to see whether the hidden is reset when creating new event.
Let me search for `ev_descaracterizado` value reset in openCreate.
Tool Calls (2)
code_search
Show Details
Arguments
{"file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"], "search_text": "function evOpenCreate"}
Result
No matches found
code_search
Show Details
Arguments
{"file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"], "search_text": "evResetTypeDescaracter|descaracterizado'"}
Result
No matches found
Request #28
deepseek-v4-flash
P:83.49K C:109 CR:83.46K CW:0
2213ms
Reasoning
Let me look for where the form is reset for create (form reset / evForm.reset). Search "reset()" in modal.
Tool Calls (1)
code_search
Show Details
Arguments
{"file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"], "search_text": "openCreate"}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 4
6650| window.EvModal.openCreate = function (opts) {
7739| if (window.EvModal && typeof window.EvModal.openCreate === 'function') {
7740| window.EvModal.openCreate(opts || {});
7743| console.error('[SSMA] EvModal.openCreate', err);
Request #29
deepseek-v4-flash
P:83.71K C:97 CR:83.58K CW:0
1905ms
Tool Calls (1)
file_read
Show Details
Arguments
{"end_line": 6700, "file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 6650}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 6650-6700
6650| window.EvModal.openCreate = function (opts) {
6651| opts = opts || {};
6652| window.__ssmaEvCreateMode = opts.createMode || null;
6653| evAprofundamentoOnlyMode = false;
6654| evAprofundamentoCanEditFromServer = null;
6655| evAprofundamentoFinalizeIntent = true;
6656| evAprofundamentoFinalized = false;
6657| // Nova ocorrência sempre começa limpa (não restaura draft de preenchimento anterior).
6658| var modeEl = document.getElementById('ev_form_mode');
6659| var idEl = document.getElementById('ev_id');
6660| if (modeEl) {
6661| modeEl.value = 'create';
6662| }
6663| if (idEl) {
6664| idEl.value = '';
6665| }
6666| var modalTitle = document.getElementById('ev-modal-title');
6667| if (modalTitle) {
6668| if (window.__ssmaEvCreateMode === 'ros') {
6669| modalTitle.textContent = 'Novo ROS';
6670| } else if (window.__ssmaEvCreateMode === 'event') {
6671| modalTitle.textContent = 'Novo evento';
6672| } else {
6673| modalTitle.textContent = 'Nova ocorrência';
6674| }
6675| }
6676| var generalPanelCreate = document.getElementById('ev-step-general');
6677| if (generalPanelCreate) generalPanelCreate.classList.remove('is-readonly');
6678|
6679| if (typeof initEvTagSelectsOnce === 'function') {
6680| initEvTagSelectsOnce();
6681| }
6682| evResetCreateUiState();
6683| if (typeof evInitTypeSelectFromConfig === 'function') {
6684| evInitTypeSelectFromConfig();
6685| }
6686| evApplyDatetimeMax();
6687| evApplyAuraTitleStatusVisibility('create');
6688| if (typeof window.renderEvCategorySelect === 'function') {
6689| window.renderEvCategorySelect('', '');
6690| }
6691|
6692| var typeEl = document.getElementById('ev_type');
6693| applyTypeBlock((typeEl && typeEl.value) ? typeEl.value : '');
6694| ensureClassificationDefaults('', true);
6695| evDefaultDatetimeToday();
6696|
6697| if (window.SSMA_IS_AURA_ADMIN) {
6698| evSetVal('ev_title', '');
6699| evSetVal('ev_status', 'ABERTO');
6700| }
Request #30
deepseek-v4-flash
P:84.48K C:123 CR:83.71K CW:0
2318ms
Reasoning
Let me check `evResetCreateUiState()` to see if it clears the global `ev_descaracterizado` and roots' checkbox/comment states. Search that function.
Tool Calls (1)
code_search
Show Details
Arguments
{"file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"], "search_text": "function evResetCreateUiState"}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 1
4892| function evResetCreateUiState() {
Request #31
deepseek-v4-flash
P:84.65K C:97 CR:84.48K CW:0
2045ms
Tool Calls (1)
file_read
Show Details
Arguments
{"end_line": 4980, "file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 4892}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 4892-4980
4892| function evResetCreateUiState() {
4893| if (evDraftTimer) {
4894| clearTimeout(evDraftTimer);
4895| evDraftTimer = null;
4896| }
4897| if (typeof evClearDraft === 'function') {
4898| evClearDraft();
4899| }
4900|
4901| var form = document.getElementById('form-event-new');
4902| if (form) {
4903| form.reset();
4904| }
4905|
4906| var shared = window.SsmaShared || {};
4907| var tc = (window.EvModal && window.EvModal._tagConfigs) ? window.EvModal._tagConfigs : {};
4908| if (typeof shared.resetTagSelect === 'function') {
4909| ['people', 'witnesses', 'responsible', 'body_region'].forEach(function (key) {
4910| if (tc[key]) {
4911| shared.resetTagSelect(tc[key]);
4912| }
4913| });
4914| }
4915|
4916| ['ev_people_ids', 'ev_witness_ids', 'ev_responsible_ids', 'ev_injured_person_details', 'ev_approach_custom'].forEach(function (id) {
4917| var el = document.getElementById(id);
4918| if (el) el.value = '';
4919| });
4920|
4921| var injBoxes = document.getElementById('ev_injured_person_boxes');
4922| if (typeof evParkBodyMapBlock === 'function') {
4923| evParkBodyMapBlock();
4924| }
4925| if (injBoxes) injBoxes.innerHTML = '';
4926| var personSelClear = document.getElementById('ev_person_id');
4927| if (personSelClear) personSelClear.removeAttribute('data-primary-injured-id');
4928|
4929| var hostReset = document.getElementById('ev-body-map-host');
4930| if (hostReset) {
4931| hostReset.innerHTML = '';
4932| delete hostReset.dataset.initialized;
4933| }
4934| var blkReset = document.getElementById('ev-body-map-block');
4935| if (blkReset) blkReset.classList.add('d-none');
4936|
4937| if (typeof window.__ssmaEvRestoreBodyParts === 'function') {
4938| window.__ssmaEvRestoreBodyParts([], shared, tc);
4939| }
4940|
4941| evEvidences = [];
4942| if (typeof evEvidenceRenderList === 'function') {
4943| evEvidenceRenderList();
4944| }
4945| evRosResolutionEvidences = [];
4946| if (typeof evRosResolutionEvidenceRenderList === 'function') {
4947| evRosResolutionEvidenceRenderList();
4948| }
4949| var rosResolvedFields = document.getElementById('ev-ros-resolved-fields');
4950| if (rosResolvedFields) rosResolvedFields.classList.add('d-none');
4951|
4952| var badge = document.getElementById('ev_activity_quality_badge');
4953| var feedback = document.getElementById('ev_activity_quality_feedback');
4954| if (badge) {
4955| badge.textContent = '';
4956| badge.classList.add('d-none');
4957| }
4958| if (feedback) {
4959| feedback.textContent = '';
4960| feedback.classList.add('d-none');
4961| }
4962|
4963| var $ = window.jQuery;
4964| if ($) {
4965| var $app = $('#ev_approach');
4966| if ($app.length) {
4967| var keep = {
4968| CORRECAO_OPERACIONAL: true,
4969| MEDIACAO: true,
4970| TREINAMENTO: true,
4971| MELHORIA_PROCESSO: true,
4972| ACAO_DISCIPLINAR: true
4973| };
4974| $app.find('option').each(function () {
4975| var v = String(this.value || '');
4976| if (v && !keep[v]) {
4977| $(this).remove();
4978| }
4979| });
4980| $app.val('CORRECAO_OPERACIONAL');
Request #32
deepseek-v4-flash
P:85.82K C:3.75K CR:84.74K CW:0
33981ms
Reasoning
The create reset does `form.reset()` which resets inputs including the per-type root checkbox and the global hidden to its default value (HTML value attribute = ''). But does `form.reset()` clear checkboxes? Yes, it sets them to default checked state (unchecked here). The per-type roots are inside `#form-event-new`? The block is in the modal card within the form? Probably inside `form-event-new`. So openCreate resets them to defaults, which is fine.
But the cross-contamination issue occurs when a user is on the same page and opens create, then picks a type (default selection maybe from ev_type). Hmm — during creation, `ev_type` select might allow switching between event types. If a user selects ROS, marks suspeita, clicks "Não", then changes type (via ev_type) to QUASE_ACIDENTE before saving: the QA branch calls evApplyTypeDescaracterPayload for QA, and descaracterizado = global hidden (which holds '1' from ROS). descaracter_suspect = QA root checkbox (which is unchecked, because only ROS root checked → 0). So the QA payload would include descaracterizado='1' without suspect. Weird but maybe validator requires suspect=1? Anyway it'd be inconsistent.
Also, does applyTypeBlock hide the ROS root but keep it checked. So yes, it's plausible. But the actual likely path: create modal initially shows type selector; user selects an event type and continues; the type selection is fixed? Actually there is ev_type; a select; maybe select value = event type, and when changed applyTypeBlock re-shows. So a user could change type mid-form. Whether they do is uncertain. This is a real design smell but uncertain severity.
Given the overall output guidance, I'll include a focused comment on this JS flaw with medium/low severity: shared global hidden field and single `ev_descaracterizado`/suspect mirror among multiple type roots can leak state between types in the same modal session, because `evApplyTypeDescaracterPayload` reads the global value not the root's; recommend per-type storage (e.g., store Sim/Não per root in data attributes) and set the payload from the root's own value.
Additionally, there's an issue at line 2940 in the payload: `payload.descaracterizado` is set whenever global hidden holds '0'/'1' — even when the user unchecked suspect (i.e., chk un-checked → descaracter_suspect = 0 but descaracterizado = previous hidden value) → the block will be shown? Actually if user unchecks suspect after having picked Não, then hidden retains '1' while suspect=0. In payload: descaracter_suspect=0 & descaracterizado=1. That could result in an occurrence being marked as descaracterizado (Não) even with no suspect flag, which might be inconsistent state & validation failure "comentário obrigatório". In the new block, the comment text is required ("Comentário *"), but evApplyTypeDescaracterPayload only sends comment if non-empty; if the user unchecked suspect then comment still there; value remains '1'. Hmm.
Actually, when the user unchecks the suspect checkbox, the yes-no area hides; but the hidden field remains. On save, descaracterizado still sent. That means an occurrence could be saved with descaracterizado=1 but suspect=0, i.e., "Não é acidente" without suspect flag. This seems inconsistent with the concept: descaracterizar should only be allowed after marking suspeita. But maybe data model expects suspect → then Sim/Não; descaracterizado without suspect could be a valid "definitively not accident"? Unclear.
These are plausible but speculative. Given the instruction "precision over recall, report only defects likely real," the most robust JS issue is the state leak among roots & global hidden + value not being reset when suspect unchecked.
Let me try to find where evSetChk('ev_descaracter_suspect', suspectOn) and per-card events reset when suspect is unchecked, to see whether the per-type hidden value gets cleared when suspect unchecked. It doesn't appear they reset `ev_descaracterizado` when suspect unchecked, even in the existing per-card AP handling. So probably acceptable in the domain: descaracterizado is independent? Actually the docs table shows separate semantics: descaracterizado = '1' Sim(descaracterizado), '0' Não (não descaracterizado), '' sem resposta. And the suspicion must be on to show S/N. If they uncheck, both could remain. In AP they mirror data-descaracterizado on cards; the hidden persists.
I need to choose which issues to file. Let me aim at the strongest:
A. Controller regression (semantic change + inconsistency with backend gate) - high.
B. Service narrows permission semantics: per-type tag-based check drops team-level grants & admin role bypass, new source of truth diverges from memberCanDescharacterizeAccident; plus new methods untested (existing tests don't cover descaracter methods).
C. Twig: `_ev_injured_person_box` now hides the whole AP descaracter/suspeita block when flag false - a specialist AP (com tag de aprofundamento, sem coluna Descaracterizar marcada) perde a capacidade de marcar suspeita, algo antes possível; comportamento da doc anterior dizia "Suspeita editável por qualquer especialista AP".
D. JS: cross-type state sharing (global hidden) - medium.
E. Twig modal `_modal_event.html.twig`: god-template growth? Given the strict user rule says god template is the top priority weight, with this file being 7800 lines (large) and this PR further adding JS in its <script> blocks; but the file is already huge; the rule says any PR increasing the mix should be flagged first. It's a template; however, code review comment on a god template is somewhat expected in this environment. The instruction says "God template — maior peso... Qualquer PR que aumente ainda mais essa mistura deve ser sinalizada antes de qualquer outro achado." Should I flag it? The template is indeed enormous (7801 lines), and the PR adds ~50 lines of JS inside it. Flag it as maintainability low/medium.
Wait, but actually code_comment tool needs an existing code anchor. For god template comment, anchor on one of the added JS lines.
Let me weigh whether to file so many. Better to file targeted comments. Let me also verify issue D, cross-type contamination, by confirming that payload assembly (in the JS function that includes evApplyTypeDescaracterPayload) runs only once per submit, for the selected type. Yes.
Now, precisely whether the event type can be changed after the fact in an open create modal. In a create flow, users can switch type before choosing (like the type card). After some entry, maybe type switch is disabled or may still be possible. Not fully verifiable; I'll phrase the JS comment mostly on per-type root storing and payload reads from a single shared global field, and lack of per-root restore of Sim/Não selection in edit mode — but tie to a concrete bug: **editing a saved occurrence**, all per-type roots receive the same suspect state; the Sim/Não selected state and the stored value are not bound per root; also if user unchecks suspect the hidden retains previous descaracterizado; value can be saved inconsistent. Also visual: on edit, yes-no buttons aren't shown as active even when descaracterizado stored. But visual issue severity is low.
Given the review burden, I'll file 5 comments total:
1. Controller high.
2. Service high (maybe merged with duplication low).
3. Twig `_ev_injured_person_box` medium.
4. JS `_modal_event` medium (state sharing).
5. JS `_modal_event`/twig god template maintainability low.
But wait, is #1 about the controller really high? Let me verify actual claim: `SSMA_CAN_DESCARACTERIZE` only affects button enablement in AP cards, and the block presence. If the tenant admin user (ROLE_MANAGER) previously could mark Não in AP, now block hidden → they can't. Could this be considered intended tightening? Possibly; however, dropping the explicit documented role bypass without updating server gate & without mention in PR description is risky. I will present it as a divergence risk. But note the `_ev_injured_person_box` conditional, which hides block, depends on the map; for ROLE_MANAGER with no member (member null → map empty), even the suspect check disappears for AP - i.e., the section disappears. So a tenant admin opening aprofundamento of AP (if admins fill aprofundamento) would not be able to do anything. Since SSMA_CAN_DESCARACTERIZE is also used at line 2986 to preselect '0' when empty. Without member, but evAprofundamentoOnlyMode? Admin is not only-mode. So they might still be able to fill other things. Fine.
Also #2 covers both the semantic narrowing and that the old controller helper that still holds the "authoritative" server rule diverges.
Let me double check that `memberCanDescharacterizeAccident` doesn't itself filter to AP only — it returns true if the member is in ANY group. So both team and tag groups count. Yes.
Let me confirm the tag's descaracter column is what feeds `descaracterIds` in permission-tag page (line 24503) which is the UI column "Descaracterizar" of that tag. So old flow allowed: mark Descaracterizar per tag member or per team member. Both kinds count in old method. New per-type logic only honors tag-based entries of a tag with exact occurrenceTypeKey.
Wait, is there something odd: for a tag of type X, if the company config has descaracter flag member M on tag; new UI true only for type X; old logic gives the ability to descaracterize AP for any flag. When M flagged on ROS tag (type ROS) they previously could descaracterize AP accidents (the old single rule applied to AP). Now with new per-type: ROS flag → only ROS; AP flag → only AP. This is precisely the desired feature: per-type restriction. OK. So the semantic narrowing to per-type is intended, presumably.
But the roles/team nuance: old memberCanDescharacterizeAccident grants via any group for AP. New: only through AP tag. So a member with descaracter flag only on ROS tag would previously descaracterize AP; now they can only descaracterize ROS. That might be exactly the point of this branch (restricting by type). If this is the intention, then #2 should focus on the role bypass and team-level config that got silently dropped for the AP view — those may be unintentional losses:
- Tenant/gestor admin bypass was documented in the old helper comment, and is independent of type. The new map drops it entirely (not just per type) — no flag type covers them, so admins can't use ANY descaracter UI block unless added to tag. That seems inconsistent because admins are allowed to edit everything else (isSsmaAprofundamentoAdmin) and the backend still grants the write gate to them.
- Team-level Descaracterizar config: team config may apply to AP. Under new per-type tags, teams aren't checked, so members flagged via team lose access to AP descaracter even though their team config may have been set. Unless company re-configures tags; possible data/config regression.
I'll fold these into the controller comment + service comment; being careful to say "confirme se foi intencional / alinhe com o backend."
Now regarding test coverage (#7 in plan): no tests exist for these methods; per the service rules, authorization policy change should have a test. I'll add one comment (low) on the service file.
Let me now decide anchors. The code_comment tool matches existing_code to the added lines in the diff. So anchors must be added lines.
For the controller comment, anchor lines:
```
+ $ssmaCanDescharacterizeByType = ($company instanceof Company && $currentMemberForExport)
+ ? $this->ssmaOccurrenceTypeConfig->getDescharacterizeFlagsByType(
...
+ $ssmaCanDescharacterizeAccident = (bool) ($ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false);
```
Use two lines.
For service: anchor lines 740-760 (new method). For duplication anchor at getDescharacterizeFlagsByType.
For Twig `_ev_injured_person_box`: anchor line `{% if ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']|default(false) %}`.
For JS comment: anchor `evApplyTypeDescaracterPayload` lines (newly added). Anchor e.g.:
```
+ function evApplyTypeDescaracterPayload(payload, type) {
...
+ var descVal = String((document.getElementById('ev_descaracterizado') || {}).value || '');
+ if (descVal === '0' || descVal === '1') payload.descaracterizado = descVal;
```
This is in `_modal_event.html.twig`.
For god template note - maybe include in same JS comment or skip; the review rules place high weight; I'll create a separate low maintainability comment with anchor on the same function. Hmm two comments on the same code is clutter. Better maybe to skip god template given file already large and this is only marginal growth. But the reviewer instructions strongly require flagging first any growth. I'll include a low-severity one anchored to `document.querySelectorAll('[data-descaracter-root]').forEach(...)` with note that logic on this screen continues in the 7.8k-line template inline <script>; suggest extracting to public/js like the rule says. Actually wait — the modal has inline script because it's within an included Twig partial; the rule says logic should be in public/js, never in a 100+ line <script> inside template. Since this file is already huge and the PR adds more JS, flag once.
Let me reduce to the most essential comments and avoid noise:
1. Controller (high) — role bypass dropped; divergence with backend gate.
2. Service (high) — tag-only per-type check: silently removes team-level/legacy-tag grants; no migration/test. Also duplicates memberCanDescharacterizeAccident.
3. Twig `_ev_injured_person_box` (medium) — suspection previously open to any AP specialist now hidden entirely.
4. JS `_modal_event.html.twig` (medium) — global hidden shared across roots & not restoring per-root Sim/Não, suspect state leak on type switch.
5. God template (low) — skip? Since it's clearly already massive and each change to such file has the rule priority. I'll merge god-template concern into comment 4's last sentence? No, better a separate short low comment anchored to a new JS block.
Actually the instructions prioritize god template as "maior peso" - but we shouldn't spam. I'll write the 4 core comments plus a short god-template comment.
Before finalizing, let me double-check the claim that the old AP behavior let any AP specialist flag suspeita (not only descaracter members). In the old template removed comment: "Descaracterização — só no aprofundamento. Suspeita editável por qualquer especialista AP; Sim/Não só quem tem permissão Descaracterizar." The partial's inner code then rendered `.ev-inj-suspect-chk` always and enabled/disabled the Não button based on permission. And `evSyncDescaracterStageUi()` hides the whole `.ev-inj-descaracter` section unless `isAp && isDoctorAprof`. So yes: previously any specialist AP in aprofundamento saw suspect checkbox; and could tick it (only Sim/Não and comment area shown; but comment required). Hmm wait: The yes/no + comment appear only when suspect checked, so suspect unchecked means no data. If the specialist is not flagged, the "Não" button disabled and comment section visible but disabled? Anyway yes, suspect could be marked.
The new behavior: only members who are flagged on the tag's Descaracterizar column see the section at all. For others the entire section hidden. This drops capability for AP specialists to raise suspicion. That is the concrete regression.
Now also a very concrete consequence: **what if the company never had any SsmaPermissionTag rows?** The `ensureFixedTechnicalTagsForCompany` likely runs only when the SSMA tags management page opens. For a company that has never opened it (most?), there are no tags, so no one has the per-type flag, and the entire descaracterização AP block disappears for everyone (all specialists & admins). Meanwhile, server write gate keeps old rules (and permits any group config). So the feature would silently vanish for many companies until they reconfigure tags — regression. That's a strong reason to tie comments 1/2.
Let me verify that fixed tags are created lazily only on the permission-tags page. Search for ensureFixedTechnicalTagsForCompany call sites.
Tool Calls (1)
code_search
Show Details
Arguments
{"search_text": "ensureFixedTechnicalTagsForCompany"}
Result
File: src/Controller/SsmaController.php
Match lines: 1
11800| foreach ($tagRepo->ensureFixedTechnicalTagsForCompany($company) as $tag) {
File: src/Repository/SsmaPermissionTagRepository.php
Match lines: 1
94| public function ensureFixedTechnicalTagsForCompany(Company $company): array
Request #33
deepseek-v4-flash
P:89.66K C:110 CR:89.47K CW:0
2151ms
Reasoning
Let me see the context at 11800 to see where ensureFixedTechnicalTags is called (which page).
Tool Calls (1)
file_read
Show Details
Arguments
{"end_line": 11830, "file_path": "src/Controller/SsmaController.php", "start_line": 11760}
Result
File: src/Controller/SsmaController.php (Total lines: 27765)
IS_TRUNCATED: false
LINE_RANGE: 11760-11830
11760| if ($this->isSsmaExcludedTenantAdminUser($m->getUser())) {
11761| continue;
11762| }
11763| $memberTeams = $m->getTeams() ?? '';
11764| if ($memberTeams !== '' && in_array($teamId, array_map('trim', explode(',', $memberTeams)), true)) {
11765| $teamMemberIds[] = $m->getId();
11766| }
11767| }
11768| $teams[] = [
11769| 'id' => $team->getId(),
11770| 'name' => $team->getName(),
11771| 'members' => $teamMemberIds,
11772| ];
11773| }
11774|
11775| $teamNameByMemberId = [];
11776| foreach ($teams as $teamRow) {
11777| foreach ($teamRow['members'] as $teamMemberId) {
11778| $teamMemberId = (int) $teamMemberId;
11779| if ($teamMemberId > 0 && !isset($teamNameByMemberId[$teamMemberId])) {
11780| $teamNameByMemberId[$teamMemberId] = (string) ($teamRow['name'] ?? '');
11781| }
11782| }
11783| }
11784| $allMembers = $this->enrichSsmaMemberRowsWithTeamMeta($allMembers, $teamNameByMemberId);
11785| }
11786| }
11787|
11788| // Permission tags: fixas por tipo (acidentes + ROS + Quase Acidente) — Figma / config SSMA
11789| $ssmaPermTags = [];
11790| if ($company) {
11791| /** @var SsmaPermissionTagRepository $tagRepo */
11792| $tagRepo = $this->entityManager->getRepository(SsmaPermissionTag::class);
11793| $fixedDisplay = [
11794| 'ACIDENTE_PESSOAL' => ['display_letter' => 'M', 'card_color' => '#186073'],
11795| 'ACIDENTE_AMBIENTAL' => ['display_letter' => 'E', 'card_color' => '#25AD52'],
11796| 'ACIDENTE_MATERIAL' => ['display_letter' => 'D', 'card_color' => '#EA151C'],
11797| 'ROS' => ['display_letter' => 'R', 'card_color' => '#186073'],
11798| 'QUASE_ACIDENTE' => ['display_letter' => 'Q', 'card_color' => '#F0AD4E'],
11799| ];
11800| foreach ($tagRepo->ensureFixedTechnicalTagsForCompany($company) as $tag) {
11801| $row = $tagRepo->toArray($tag, $allMembers);
11802| $key = (string) ($tag->getOccurrenceTypeKey() ?? '');
11803| $meta = $fixedDisplay[$key] ?? ['display_letter' => mb_strtoupper(mb_substr($tag->getName(), 0, 1)), 'card_color' => '#186073'];
11804| $row['display_letter'] = $meta['display_letter'];
11805| $row['card_color'] = $meta['card_color'];
11806| $ssmaPermTags[] = $row;
11807| }
11808| }
11809|
11810| $rosCallPriority = $company
11811| ? $this->ssmaOccurrenceTypeConfig->getRosCallPriority($company)
11812| : \App\Service\Ssma\SsmaOccurrenceTypeConfigService::ROS_CALL_PRIORITY_LOCATION_DIRECT;
11813|
11814| $actionTypeMetadata = $this->getActionTypeMetadata();
11815| $subsidiaryViewEarly = $company ? $this->buildSsmaSubsidiaryViewData($company) : [];
11816| $isNetworkHeadWithUnits = ($subsidiaryViewEarly['ssma_is_network_head'] ?? false)
11817| && ($subsidiaryViewEarly['ssma_has_network_units'] ?? false);
11818|
11819| if ($isOccurrenceDetailView && $company) {
11820| $occurrences = $this->loadOccurrenceListRowsForDetailView(
11821| $company,
11822| $detailOccurrenceId,
11823| $allMembers,
11824| $teams
11825| );
11826| $actionsTaken = $this->loadActionsForOccurrenceDetail($company, $detailOccurrenceId);
11827| $inspections = [];
11828| $abordagens = [];
11829| $horasData = [];
11830| // Fase B: SSR do detalhe só com membros referenciados (+ gestores do modal).
Request #34
deepseek-v4-flash
P:90.95K C:4.62K CR:89.73K CW:0
34071ms
Reasoning
The fixed tags are created in `buildSsmaViewData` for every page load with company, calling `ensureFixedTechnicalTagsForCompany`. Since buildSsmaViewData is where the new flags are computed, and this code runs before line 12532, the fixed tags exist by then (since line 11800 runs earlier in the same method). So the fixed tags always exist for the occurrence hub and detail. That weakens my "tags absent" scenario — for occurrence pages the tags exist.
But tags exist with no member links and no descaracter column config. So flags are false unless the admin configured the member into the type's "Descaracterizar" column.
Wait, but note buildSsmaViewData ensures fixed tags on every request that has a company, meaning any page building view data will write tags if missing (flush on GET). OK.
Now the critical thing: in old code, `memberCanDescharacterizeAccident` consulted the aprofundamento_descaracter config regardless of tags. Companies using the legacy config may still have grant lists under "team:{id}". The new by-type only reads "tag:{id}". Since tags get created on next occurrence page view (they may have already existed in legacy because there was a tag config page?), but the descaracter grant may be stored under a team key. So those grants are silently dropped for the UI.
Also now for admins (roles/gestor admin) with no explicit tag member grant: flag false, UI hidden. This is a concrete regression in UI for them, since the server write gate still permits them. I'm fairly confident to file this.
Let me re-read old `ssmaMemberCanDescharacterizeAccident` — the controller helper (lines 10198-10216) is still used only by `applySsmaDescaracterPermissionGate`. So yes, both mechanisms coexist.
Wait, could the UI "block hidden" still allow the admin to work because when they open the occurrence edit they're using different UI path (OccurrenceModal.openEdit → older modal `_modal_occurrence.html.twig`)? For admins `EV_IS_ADMIN_APROFUNDAMENTO` routes through openEdit which opens occurrence edit (maybe the legacy modal _modal_occurrence.html.twig) that does not have per-type descaracter? The AP aprofundamento uses the full edit form. Actually the AP type descaracterization block is in _ev_injured_person_box (which is in _modal_event). If admin uses the same EvModal (populateForEdit via OccurrenceModal.openEdit), then the injured person box descaracter area is the same.
I'll finalize comments now with the format required (PT-BR, simple-first). Also I'll include suggestions.
Let me make sure for the service methods, each flag computation might be okay on correctness except the semantic narrowing; also `getDescharacterizeFlagsByType` iterates FIXED_TECHNICAL_OCCURRENCE_KEYS — the set matches the template keys: yes, matches (AP, AA, AM, ROS, QA). Good.
Let me confirm that the `SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS` list doesn't include extra keys the template lacks. It has exactly the 5 used. Good.
Now consider company-isolation (# user asked: isolamento por empresa): each repository query filters company. Fine.
But there's a security check: `(int) $currentMemberForExport->getId()` and company from `$company` resolved from user session — fine. No injection.
Alright, finalize.
Let me reconsider whether comment #1 (controller) vs #2 (service) might overlap and the guidelines favor concise non-duplicated findings. I'll consolidate into:
- Service file comment: the new by-type authorization rule is a NEW authority that diverges from `memberCanDescharacterizeAccident`/controller helper; consequences: teams & role bypass not honored; UI stricter than backend; no backfill/test. This is the semantic root cause.
- Controller comment: how it manifests: for ROLE_SUPER_ADMIN/ROLE_MANAGER/gestor admin and team-flagged users the derived AP flag is false → the whole descaracterização UI (bloco suspeita + SSMA_CAN_DESCARACTERIZE) some users que antes viam no AP; backend still allows because applySsmaDescaracterPermissionGate uses old rule. Divergência UI/backend. Medium-high.
Since both cover overlapping content, I'll aim the service comment at the root semantics (drops group 'team' & tags with other/null key) and the controller comment at role bypass. And the Twig AP block comment about specialists losing "suspeita" capture.
Now let me draft PT-BR comments.
### Controller comment (high):
Anchored lines:
```
+ $ssmaCanDescharacterizeByType = ($company instanceof Company && $currentMemberForExport)
+ ? $this->ssmaOccurrenceTypeConfig->getDescharacterizeFlagsByType(
+ $company,
+ (int) $currentMemberForExport->getId()
+ )
+ : [];
+ $ssmaCanDescharacterizeAccident = (bool) ($ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false);
```
Content:
"Essa nova regra passa a liberar o bloco de descaracterização (e a flag `ssmaCanDescharacterizeAccident`/`SSMA_CAN_DESCARACTERIZE`) apenas para quem tem o membro marcado na tag do tipo correspondente, deixando de fora os casos que o helper antigo (`ssmaMemberCanDescharacterizeAccident`, ainda usado no salvamento via `applySsmaDescaracterPermissionGate`) liberava automaticamente: ROLE_SUPER_ADMIN/ROLE_MANAGER, tag Gestor Administrador e config por equipe. Na prática, gestor/tenant e quem foi configurado na coluna Descaracterizar de uma equipe perdem a UI (não veem mais Suspeita/Sim/Não no acidente pessoal), enquanto o backend ainda aceitaria a escrita — regra divergente entre front e back. Confirme se a restrição é intencional e alinhe o gate de gravação com a mesma fonte, senão usuários com permissão existente deixam de conseguir descaracterizar."
### Service comment (high):
Anchored lines for the new method:
```
+ public function memberCanDescharacterizeForType(Company $company, int $memberId, string $typeKey): bool
...
+ $tags = $this->em->getRepository(SsmaPermissionTag::class)->findBy([
+ 'company' => $company,
+ 'occurrenceTypeKey' => $typeKey,
+ ]);
```
Content about narrowed semantics vs memberCanDescharacterizeAccident (team groups + tag type null) plus untested.
### Twig `_ev_injured_person_box` comment (medium):
Anchor:
```
+ {% if ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']|default(false) %}
```
Content: hides block entirely for specialists not on the tag column; comment removed said suspect could be flagged by any AP specialist. Regression for those who should register suspicion; and on read-only view the state hidden. Suggest keep block render for specialists with access to aprofundamento and only gate Sim/Não (like before).
Hmm, but the whole purpose of the new flags might be to hide from those not allowed at all... but note the difference: a specialist with the tag (can fill aprofundamento) but no descaracter column previously could still flag suspeita (which triggers the red banner), i.e., the "suspeita" concept is separate from "descaracterizar". The UI tooltip also says "Sim/Não só quem tem permissão". So hiding everything likely regresses the ability to record suspicion for non-flagged users. Because if only flagged users can raise suspicion, then in a company where no member is flagged on the tag, NO ONE can register suspicion even for legitimately suspicious accidents, and validation may require description? I'll keep medium.
### JS comment (medium):
Anchor:
```
+ function evApplyTypeDescaracterPayload(payload, type) {
+ var root = evGetTypeDescaracterRoot(type);
+ if (!root) return;
+ var chk = root.querySelector('.ev-type-descaracter-suspect');
+ payload.descaracter_suspect = chk && chk.checked ? 1 : 0;
+ var descVal = String((document.getElementById('ev_descaracterizado') || {}).value || '');
+ if (descVal === '0' || descVal === '1') payload.descaracterizado = descVal;
```
Content: All 4 type roots share the same hidden `ev_descaracterizado`, and payload reads that global for whichever type is being saved. If the user changes type mid-creation or leaves a previous answer, state can bleed; suspect unchecked but value remains. Also on loading an existing record the Sim/Não isn't restored visually in the root, only global hidden, so save is based on a field not visible; recommend storing the answer per root and resetting on type switch.
### God template maintainability comment (low):
Maybe anchor on the new forEach binding lines:
```
+ document.querySelectorAll('[data-descaracter-root]').forEach(function (root) {
```
Content: This partial já é god template de 7.8k linhas (JS embutido). A PR acrescenta mais lógica de tela aqui em vez de public/js. Sugestão: levar para arquivo JS próprio, como a regra de componentes orienta. Prioridade baixa.
Hmm, but instructions: "Antes de chamar task_done, confirme que deu atenção a cada arquivo." Files: SsmaController (comment 1), SsmaOccurrenceTypeConfigService (comment 2), index.html.twig (no issue), occurrence_view.html.twig (no issue beyond the include; same var default), _ev_descaracter_suspect_block (no direct issue), _ev_injured_person_box (comment 3), _modal_event.html.twig (comments 4 & 5).
Let me double-check the `_ev_descaracter_suspect_block.html.twig` for the QUASE_ACIDENTE id and whether all attributes: fine.
One more check: In `_ev_descaracter_suspect_block`, buttons `data-descaracter-val="0"` labeled "Sim" and val "1" labeled "Não" — consistent with AP per-card semantics (val '1' descaracterizado). Good.
Also possible Twig precedence issue: `ssmaCanDescharacterizeByType[_type_key]|default(false)` - `default` filter triggers when the value is undefined, but `_type_key` used as array key expression is OK. Note if `_type_key` = 'QUASE_ACIDENTE' and variable is a map keyed with those constants, fine.
One thing: In index/occurrence_view the Twig passes `ssmaCanDescharacterizeByType` into `_modal_event.html.twig`, but the `_ev_descaracter_suspect_block` include inside `_modal_event.html.twig` refers to `ssmaCanDescharacterizeByType|default({})` - inside partial includes, variables passed via outer include context are available only if using `only`? In the outer include, without `only`, the context of the including template is exposed. `_modal_event` gets context from the include of `_modal_event` plus the explicit variables. The `ssmaCanDescharacterizeByType` var will be available within _modal_event and its nested includes. Good.
Now also `_ev_injured_person_box` include passes the map at line ~672. Good.
Let me consider severity of comment 1 vs 2 overlap. I'll reduce to avoid duplication: make the service comment about root semantic difference & source-of-truth divergence & test. The controller comment about role-bypass removal and UI/back-end inconsistency. Good.
Now, let me confirm whether `occurrence_view.html.twig` (detail page) is where the descaracter block previously appeared for AP aprofundamento, with specialist-only. In the previous modal openAprofundamento → for AP type uses `evAprofundamentoOnlyMode`; the descaracter blocks in `_ev_injured_person_box` shown only when `isAp && isDoctorAprof`. This is where the suspect would be flagged by the AP specialist. This is exactly the flow of rules "ocorrencia-07" etc.
Given the rules say "Fluxo de autorização sem teste é crítico," but we can mention tests in the service comment as low.
Actually the two rules sections (service and controller) ask the test comment requirement; plan item #7 suggests adding test comments. I'll mention tests in the service comment.
Let me finalize and call the code_comment tool.
Also, decide severity values:
1. Controller: high.
2. Service: high (silent permission change/divergence risk + no tests).
3. Twig injured person: medium.
4. JS payload: medium.
5. God template: low (maintainability).
For category field: bug / maintainability / test etc.
1. bug
2. bug (or security?) Authorization semantics → bug.
3. bug
4. bug
5. maintainability
Now craft the content in pt-BR following structure (1) o que mudou e impacto; (2) por que importa; (3) o que fazer. Keep technical names after explanation.
Let me write them.
Analisando a lógica antiga vs. nova de permissão e o fluxo dos templates/JS, encontrei divergências relevantes. Vou registrar os comentários.
Tool Calls (1)
code_comment
Show Details
Arguments
{"comments": [{"content": "Aqui a flag de descaracterização passou a ser derivada apenas do novo mapa por tipo (tag daquele tipo), abandonando os casos que o helper antigo `ssmaMemberCanDescharacterizeAccident` liberava automaticamente: ROLE_SUPER_ADMIN/ROLE_MANAGER, tag \"Gestor Administrador\" e config por equipe. Na prática, gestor/tenant e quem tem a coluna Descaracterizar marcada numa equipe deixam de ver o bloco de suspeita/Sim-Não no acidente pessoal, enquanto o salvamento (`applySsmaDescaracterPermissionGate`, que ainda usa o helper antigo) continua aceitando a escrita — critérios diferentes entre front e back na mesma autorização. Confirme se a restrição é intencional e, se for, alinhe o gate de gravação para a mesma fonte única; caso contrário, usuários com permissão existente perdem a capacidade de descaracterizar pela UI.", "existing_code": " $ssmaCanDescharacterizeByType = ($company instanceof Company && $currentMemberForExport)\n ? $this->ssmaOccurrenceTypeConfig->getDescharacterizeFlagsByType(\n $company,\n (int) $currentMemberForExport->getId()\n )\n : [];\n $ssmaCanDescharacterizeAccident = (bool) ($ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false);", "category": "bug", "severity": "high", "path": "src/Controller/SsmaController.php"}, {"content": "A nova checagem por tipo considera somente vínculos na chave `tag:{id}` de tags com `occurrenceTypeKey` exatamente igual ao tipo, enquanto `memberCanDescharacterizeAccident` (mesmo serviço) percorre toda a configuração `aprofundamento_descaracter`, incluindo vínculos do tipo `team:{id}`. Ou seja, quem foi liberado pela coluna Descaracterizar de uma equipe, ou por tag legada com chave nula/outra, sai silenciosamente da regra nova sem nenhum backfill/migração — e a mesma política de autorização passa a existir com dois critérios divergentes no mesmo arquivo, risco de um caminho liberar e o outro não. Reaproveite uma única base (por exemplo, `memberCanDescaracterizeForType` chamado por tipo) e decida explicitamente o destino das liberações por equipe/tag legada; a regra nova de autorização também ficou sem teste automatizado cobrindo a tag por tipo e o isolamento por empresa.", "existing_code": " public function memberCanDescharacterizeForType(Company $company, int $memberId, string $typeKey): bool\n {\n if ($memberId <= 0 || $typeKey === '') {\n return false;\n }\n $tags = $this->em->getRepository(SsmaPermissionTag::class)->findBy([\n 'company' => $company,\n 'occurrenceTypeKey' => $typeKey,\n ]);", "category": "bug", "severity": "high", "path": "src/Service/Ssma/SsmaOccurrenceTypeConfigService.php"}, {"content": "Com esse condicional, o bloco inteiro de suspeita do acidente pessoal some para quem não está marcado na coluna Descaracterizar da tag — incluindo especialistas de AP que preenchem o aprofundamento. Antes, qualquer especialista AP podia marcar a suspeita (que dispara o alerta vermelho) e apenas o Sim/Não era restrito à permissão de descaracterizar; agora, numa empresa sem ninguém marcado na coluna, nenhum especialista consegue registrar a suspeita e quem está só visualizando deixa de ver o estado já gravado. Se a restrição por tipo não for intencional para a etapa de suspeita, mantenha o bloco visível para quem tem acesso ao aprofundamento e gate apenas o Sim/Não, como era antes.", "existing_code": " {% if ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']|default(false) %}", "category": "bug", "severity": "medium", "path": "templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig"}, {"content": "Os quatro blocos por tipo (ROS, quase acidente, acidente material/ambiental) gravam o Sim/Não num único campo escondido global (`ev_descaracterizado`) e este payload lê esse campo global independentemente do tipo que está sendo salvo. Se o usuário trocar o tipo na criação ou alternar entre ocorrências no mesmo modal, a resposta escolhida num tipo pode vazar para o payload do outro; além disso, ao editar um registro salvo, o Sim/Não não é restaurado visualmente no bloco do tipo (só o campo oculto guarda o valor). Guarde o Sim/Não e o comentário por bloco (ex.: atributos `data-` no root) e monte o payload a partir do root do próprio tipo, limpando o estado ao trocar de tipo.", "existing_code": " function evApplyTypeDescaracterPayload(payload, type) {\n var root = evGetTypeDescaracterRoot(type);\n if (!root) return;\n var chk = root.querySelector('.ev-type-descaracter-suspect');\n payload.descaracter_suspect = chk && chk.checked ? 1 : 0;\n var descVal = String((document.getElementById('ev_descaracterizado') || {}).value || '');\n if (descVal === '0' || descVal === '1') payload.descaracterizado = descVal;", "category": "bug", "severity": "medium", "path": "templates/ssma/occurrence/partials/_modal_event.html.twig"}, {"content": "Este template já tem ~7,8 mil linhas concentrando markup e um bloco `<script>` enorme, e esta PR volta a adicionar lógica de tela nova (bind dos blocos por tipo) dentro dele. A orientação do projeto é manter esse tipo de comportamento em `public/js/`; considere extrair a lógica de descaracterização por tipo para um arquivo JS dedicado para não aprofundar o god template.", "existing_code": " document.querySelectorAll('[data-descaracter-root]').forEach(function (root) {\n var chk = root.querySelector('.ev-type-descaracter-suspect');\n var yesNo = root.querySelector('.ev-type-descaracter-yesno');", "category": "maintainability", "severity": "low", "path": "templates/ssma/occurrence/partials/_modal_event.html.twig"}]}
Result
(async)
Request #35
deepseek-v4-flash
P:95.59K C:985 CR:95.49K CW:0
8453ms
Reasoning
Now I should confirm each file got its pass. Let me also verify the two include files (index.html.twig and occurrence_view.html.twig) and _ev_descaracter_suspect_block got their review. They appear fine (variable passed, default {} present). The new partial `_ev_descaracter_suspect_block.html.twig` is self-contained.
Potential minor: the partial `_ev_descaracter_suspect_block` for QUASE_ACIDENTE renders an id `ev-qa-descaracter`. Check if other code references `ev-qa-descaracter` expecting something else — no.
One more consideration: the reviewer guideline says check for missing migration/test and scope. Good.
One more check on `SsmaController` view data: This is within `buildSsmaViewData`? The diff lines 12531-... hmm actually buildSsmaViewData begins at 11521 and continues to ~12690. The diff adds map to the controller's giant method. Also note the map passed to both index & detail templates. The comment about god-object responsibilities could be noted for controller too (huge method ~12500 lines). But I already made comments on the controller diff for a functional issue. Adding a god-object note might be more noise. Given instructions weighting god object heavily, I could add a low maintainability note on the controller as well. But the code_comment above on the controller already addresses divergence. Actually rule for controller review says god object is priority 1: "Se este controller já é grande... qualquer aumento dessa mesma responsabilidade na PR é o achado mais importante". The controller is 27,765 lines and this action mounts business rule in it. Hmm, but the change actually delegates to service. The derivation of the boolean from key is minimal. I think an extra maintainability note is not strictly needed given we found functional issues; but to honor the rule, let me keep it brief - or skip since we already flagged big issues and the guideline for templates says comments should be concise. I'll skip the controller god-object note to avoid noise.
I think we've completed the passes. Each file got consideration:
- SsmaController.php: comment (functional).
- SsmaOccurrenceTypeConfigService.php: comment (semantic divergence + test).
- index.html.twig: pass — includes variable; no issue.
- occurrence_view.html.twig: pass — same.
- _ev_descaracter_suspect_block.html.twig: pass — self-contained; guards variable.
- _ev_injured_person_box.html.twig: comment.
- _modal_event.html.twig: two comments.
Done. Call task_done.
Revisei todos os arquivos do grupo. Resumo do que foi reportado:
- **`SsmaController.php`** (alta): a flag de descaracterização de acidente pessoal passou a depender apenas da tag por tipo, abandonando o bypass de papéis (super admin/manager/gestor administrador) e a config por equipe do helper antigo — divergindo do gate de gravação que ainda usa a regra antiga.
- **`SsmaOccurrenceTypeConfigService.php`** (alta): a nova checagem por tipo ignora vínculos `team:{id}` e tags legadas sem `occurrenceTypeKey`, criando dois critérios divergentes no mesmo serviço e sem teste para a regra de autorização.
- **`_ev_injured_person_box.html.twig`** (média): o bloco inteiro de suspeita do AP fica oculto para especialistas sem a coluna Descaracterizar, quando antes a suspeita era aberta a qualquer especialista AP.
- **`_modal_event.html.twig`** (média): o payload por tipo lê um campo global único de Sim/Não compartilhado entre os quatro blocos, com risco de vazamento entre tipos e sem restaurar visualmente o valor salvo na edição; mais um apontamento de maintainability sobre o template de ~7,8 mil linhas concentrando JS embutido.
Os arquivos `index.html.twig`, `occurrence_view.html.twig` e o novo partial `_ev_descaracter_suspect_block.html.twig` repassam a variável com `default({})` de forma consistente e não apresentaram defeitos adicionais.
Tool Calls (1)
task_done
Show Details
Arguments
{"state": "DONE"}
Request #36
deepseek-v4-flash
P:16.89K C:2.13K CR:10.24K CW:0
16148ms
Reasoning
Let me start by reviewing the files in the review group. Let me look at each file carefully.
Let me read the actual files to understand context better. Let me start with the service file and controller.
The confirmed findings already cover:
1. SsmaController.php - flag regression from `ssmaMemberCanDescharacterizeAccident` to by-type only map (loses ROLE_SUPER_ADMIN/ROLE_MANAGER, "Gestor Administrador" tag, config per team)
2. SsmaOccurrenceTypeConfigService.php - new check only considers `tag:{id}` links, not `team:{id}`
3. _ev_injured_person_box.html.twig - block disappears for anyone not flagged on the tag column
4. _modal_event.html.twig evApplyTypeDescaracterPayload - global field reuse across types
5. _modal_event.html.twig - god template issue
I need to continue reviewing all files and find other issues not already reported.
Let me read the relevant files to understand more.
Let me look at the SsmaOccurrenceTypeConfigService file in the current state to examine `memberCanDescharacterizeAccident`, `getAprofundamentoDescaracterMemberIds`, `FIXED_TECHNICAL_OCCURRENCE_KEYS`, etc.
Let me investigate to confirm context. Let me look at key points.
First, in the service, `getDescharacterizeFlagsByType` loops over `SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS` and calls `memberCanDescharacterizeForType`. Each call does `findBy` queries - N+1 queries but bounded by the number of fixed keys (probably small like 4-5). Minor.
Let me examine the keys used: The controller uses `$ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']`. The service builds keys from `FIXED_TECHNICAL_OCCURRENCE_KEYS`. Need to verify that 'ACIDENTE_PESSOAL' is in that constant list. Let me search.
Also in the template `_ev_descaracter_suspect_block.html.twig`, type keys used: 'ROS', 'QUASE_ACIDENTE', 'ACIDENTE_MATERIAL', 'ACIDENTE_AMBIENTAL'. And `_ev_injured_person_box.html.twig` uses 'ACIDENTE_PESSOAL'.
Also, the newly included partial is inserted within the technical section for each type. But note that `ssmaCanDescharacterizeByType` in the controller is computed only when `$currentMemberForExport` is truthy — but `ssmaCanDescharacterizeAccident` uses it. In the controller, both index and view pass `ssmaCanDescharacterizeByType`. However, are there other places that render these templates with the old variable only? Let's check: `occurrence_view.html.twig` include and `index.html.twig` include. Those templates include the `_modal_event.html.twig` partial presumably. The `_ev_injured_person_box.html.twig` partial is included with `ssmaCanDescharacterizeByType` passed... Actually in `_modal_event.html.twig`, line ~672 the include of injured person box passes `ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})`. Good.
But other pages might include `_modal_event.html.twig` without passing `ssmaCanDescharacterizeByType`, in which case the default `{}` is used, hiding the whole descaracter UI even for authorized users. But given these are new features only in view/index, other callers could regress.
Now consider the partial `_ev_descaracter_suspect_block.html.twig`. It's included with `type_key` and `ssmaCanDescharacterizeByType`. It references `ssmaCanDescharacterizeByType[_type_key]|default(false)`. But wait, if the flag is not enabled... fine.
But there's an important behavior issue: the actual suspicion blocks for each type are now gated to render only if the specific type's tag has the "Descaracterizar" column checked. However the JS for save payload uses `evApplyTypeDescaracterPayload`. But note there's a legacy `ev_descaracter_suspect` element for ACIDENTE_PESSOAL (the global). The ROS/QA/AM/AA blocks now read global hidden fields `ev_descaracterizado`. Actually is there an `ev_descaracterizado` hidden input inside the modal? Let me check the templates. There's a global one presumably in the ACIDENTE_PESSOAL block `ev-inj-descaracter`. We should verify.
Consider `evIsDescaracterSuspectChecked` now returns true if any `.ev-type-descaracter-suspect:checked` exists. Then used to populate some global payload path? Possibly for the old flow. Hmm.
Let me look more closely at the details. Let me read `_modal_event.html.twig` relevant parts. It is a huge template; let me search for relevant ids and functions.
Let me look at what `ev_descaracterizado` is, `ev_descaracter_suspect`, `ev_descaracter_comment`, and how payload is stored/read on the backend. Also examine `det.descaracter_comment`.
Since it's a huge file (7k+ lines), let me search.
Potential issues to report (new, not already in confirmed):
- The partial block inserts a duplicate/global element possibly duplicated per type section. When the modal is used in the occurrence view (aprofundamento) as a read-only / aprofundamento mode for a particular type, and the create mode general step → each type section? We need to examine the JS that maps to specific types.
But careful: the confirmed findings already flagged global state issues #4. We should not repeat those.
Let me think of new issues:
1. In `evApplyTypeDescaracterPayload`, note when saving ROS with descaracter: sets `payload.descaracter_suspect`, `payload.descaracterizado` from the global hidden input `ev_descaracterizado`, and comment. But that global hidden input also is used for AP card. Confirmed #4 covers this.
2. Note the flow: In the "event registration" the type-specific blocks only render if tag col is marked; the "suspect" checkbox in per-card (AP) and per-type blocks share `ev_descaracter_suspect` element for ROS/QA etc.
Let's review the changes for additional bugs not overlapping with #1-5.
For the controller: `getDescharacterizeFlagsByType` is called only when `$company instanceof Company && $currentMemberForExport`. Note: current member's id is fetched from `$currentMemberForExport->getId()`. But wait, old code passed `$currentMemberForExport` (entity) to `ssmaMemberCanDescharacterizeAccident`; new code `(int) $currentMemberForExport->getId()` — same id? Let's check the original helper signature. Actually old helper `ssmaMemberCanDescharacterizeAccident($company, $currentMemberForExport)`. Is that method in the controller taking member entity? Let me search. Perhaps it's about the SsmaMember vs company member. Wait, but the service method `memberCanDescharacterizeAccident(Company $company, int $memberId)` takes a member ID.
Actually there's a subtlety: is the `currentMemberForExport` an `SsmaMember` or `CompanyMember`? `$currentMemberForExport?->getId()`. Hmm. The original controller had a method `ssmaMemberCanDescharacterizeAccident($company, $currentMemberForExport)` — perhaps its own logic. But anyway.
Let me focus on new issues in these diff files.
Potential issue: The list of FIXED_TECHNICAL_OCCURRENCE_KEYS might not include 'ACIDENTE_PESSOAL', 'ACIDENTE_MATERIAL', 'ACIDENTE_AMBIENTAL', 'ROS', 'QUASE_ACIDENTE' or the key names may differ (e.g., uses event type keys like 'AP', 'QA'?). The controller reads `$ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false`. If the constant list doesn't contain that key, the lookup returns false always — regression. Need to verify constant contents.
Let me search the repo for FIXED_TECHNICAL_OCCURRENCE_KEYS and occurrenceTypeKey values.
Also whether there could be N+1: `getDescharacterizeFlagsByType` runs one `findBy` per key (say ~5 queries), each returning tags, then for each tag calls `getAprofundamentoDescaracterMemberIds`, which presumably does queries. This could be several queries per page render. But bounded.
Now let's verify with actual code reading.
Let me examine `SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS` and what `occurrenceTypeKey` values look like in DB. Also, tags referenced by `findBy(['company' => ..., 'occurrenceTypeKey' => $typeKey])`. If tags can have occurrenceTypeKey stored as e.g., "QUASE_ACIDENTE"? Let me look at tag entity and its fixed list.
Let me search.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "FIXED_TECHNICAL_OCCURRENCE_KEYS"}
Result
File: src/Controller/SsmaController.php
Match lines: 1
10538| $fullTechnicalAccessTypes = SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS;
File: src/Repository/SsmaPermissionTagRepository.php
Match lines: 3
18| public const FIXED_TECHNICAL_OCCURRENCE_KEYS = [
37| return $key !== null && $key !== '' && in_array($key, self::FIXED_TECHNICAL_OCCURRENCE_KEYS, true);
99| foreach (self::FIXED_TECHNICAL_OCCURRENCE_KEYS as $typeKey) {
File: src/Service/Ssma/SsmaOccurrenceTypeConfigService.php
Match lines: 1
768| foreach (SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS as $typeKey) {
code_search
Show Details
Arguments
{"search_text": "occurrenceTypeKey"}
Result
File: docs/SSMA-REGRAS-POS-MERGE.md
Match lines: 4
37|| Tag SSMA por pessoa (`SsmaPermissionTagMember`) | Tabela SSMA — gestão, técnico por `occurrenceTypeKey` |
77|- Técnico com `occurrenceTypeKey` (diferente de Autorizações; árvore no menu é só gestão)
231|| Especialista técnico (`hasSsmaTechnicalCauseTreeAccess` — tag com `occurrenceTypeKey`) |
285|### Técnico especialista (`SsmaPermissionTagMember` com `occurrenceTypeKey`)
File: docs/ssma/CORRECOES-OCORRENCIA-FIGMA-PARTE-1.md
Match lines: 1
161|**Feito:** resolve destinos via `SsmaPermissionTag` + `SsmaPermissionTagMember` (`occurrenceTypeKey` = `ACIDENTE_*`); fallback para o mapa de equipe de aprofundamento (OTC) se a tag não tiver membros.
File: src/Command/TestSsmaCauseTreeNavigationCommand.php
Match lines: 1
118| $typeKey = (string) $tag->getOccurrenceTypeKey();
File: src/Controller/SsmaController.php
Match lines: 8
3176| $occurrenceTypeKey = (string) ($occurrence['type_value'] ?? '');
3182| if ((string) ($tagRow['occurrence_type_key'] ?? '') === $occurrenceTypeKey) {
9999| $key = $link->getTag()?->getOccurrenceTypeKey() ?? '';
10093| && (string) $tag->getOccurrenceTypeKey() !== '') {
10583| $key = (string) ($link->getTag()?->getOccurrenceTypeKey() ?? '');
11802| $key = (string) ($tag->getOccurrenceTypeKey() ?? '');
24443| if (SsmaPermissionTagRepository::isFixedTechnicalOccurrenceKey($tag->getOccurrenceTypeKey())) {
24549| 'occurrence_type_key' => $tag->getOccurrenceTypeKey(),
File: src/Entity/SsmaOccurrenceCreatePermission.php
Match lines: 5
36| private string $occurrenceTypeKey;
55| public function getOccurrenceTypeKey(): string
57| return $this->occurrenceTypeKey;
60| public function setOccurrenceTypeKey(string $occurrenceTypeKey): self
62| $this->occurrenceTypeKey = $occurrenceTypeKey;
File: src/Entity/SsmaPermissionTag.php
Match lines: 3
44| private ?string $occurrenceTypeKey = null;
83| public function getOccurrenceTypeKey(): ?string { return $this->occurrenceTypeKey; }
84| public function setOccurrenceTypeKey(?string $key): self { $this->occurrenceTypeKey = $key; return $this; }
File: src/EventListener/GlobalPermissionListener.php
Match lines: 1
1343| if ($tag->getCompany()->getId() === $company->getId() && (string) $tag->getOccurrenceTypeKey() !== '') {
File: src/Repository/SsmaOccurrenceCreatePermissionRepository.php
Match lines: 2
43| ->select('p.occurrenceTypeKey')
49| return array_values(array_map(static fn (array $row): string => (string) $row['occurrenceTypeKey'], $rows));
File: src/Repository/SsmaPermissionTagRepository.php
Match lines: 3
82| 'occurrence_type_key' => $tag->getOccurrenceTypeKey(),
103| 'occurrenceTypeKey' => $typeKey,
108| $tag->setOccurrenceTypeKey($typeKey);
File: src/Service/SafetyEnvironmentService.php
Match lines: 1
723| $typeKey = (string) ($tag->getOccurrenceTypeKey() ?? '');
File: src/Service/Ssma/SsmaAutomationService.php
Match lines: 2
1712| * Resolve destinatários via SsmaPermissionTag + SsmaPermissionTagMember (por occurrenceTypeKey).
1725| 'occurrenceTypeKey' => $typeKey,
File: src/Service/Ssma/SsmaOccurrenceCreatePermissionService.php
Match lines: 2
152| $typesByMember[$mid][$permission->getOccurrenceTypeKey()] = true;
402| $row->setOccurrenceTypeKey($typeKey);
File: src/Service/Ssma/SsmaOccurrenceTypeConfigService.php
Match lines: 2
637| * Mapa aprofundamento: occurrenceTypeKey → CompanyTeam.id
747| 'occurrenceTypeKey' => $typeKey,
File: src/Twig/MemberPermissionExtension.php
Match lines: 1
831| && (string) $tag->getOccurrenceTypeKey() !== ''
File: tests/Unit/Product/Ssma/SsmaOccurrenceCreatePermissionServiceTest.php
Match lines: 1
461| array_map(static fn (SsmaOccurrenceCreatePermission $row): string => $row->getOccurrenceTypeKey(), $persisted),
File: tests/Unit/Product/Ssma/SsmaPermissionTagRepositoryTest.php
Match lines: 1
56| $tag->setOccurrenceTypeKey('ACIDENTE_PESSOAL');
Request #37
deepseek-v4-flash
P:20.49K C:155 CR:18.94K CW:0
1906ms
Reasoning
Let me read the repository constant FIXED_TECHNICAL_OCCURRENCE_KEYS.
Tool Calls (2)
file_read
Show Details
Arguments
{"file_path": "src/Repository/SsmaPermissionTagRepository.php"}
Result
File: src/Repository/SsmaPermissionTagRepository.php (Total lines: 125)
IS_TRUNCATED: false
LINE_RANGE: 1-125
1|<?php
2|
3|declare(strict_types=1);
4|
5|namespace App\Repository;
6|
7|use App\Entity\Company;
8|use App\Entity\SsmaPermissionTag;
9|use Doctrine\Bundle\DoctrineBundle\Repository\ServiceEntityRepository;
10|use Doctrine\Persistence\ManagerRegistry;
11|
12|/**
13| * @extends ServiceEntityRepository<SsmaPermissionTag>
14| */
15|class SsmaPermissionTagRepository extends ServiceEntityRepository
16|{
17| /** Chaves de tipo — tags fixas de aprofundamento técnico (acidentes + ROS/Quase Acidente). */
18| public const FIXED_TECHNICAL_OCCURRENCE_KEYS = [
19| 'ACIDENTE_PESSOAL',
20| 'ACIDENTE_AMBIENTAL',
21| 'ACIDENTE_MATERIAL',
22| 'ROS',
23| 'QUASE_ACIDENTE',
24| ];
25|
26| /** @var array<string, array{name: string}> */
27| private const FIXED_TECHNICAL_TAG_DEFS = [
28| 'ACIDENTE_PESSOAL' => ['name' => 'Aprofundamento Acidente Pessoal'],
29| 'ACIDENTE_AMBIENTAL' => ['name' => 'Aprofundamento Acidente Ambiental'],
30| 'ACIDENTE_MATERIAL' => ['name' => 'Aprofundamento Acidente Material'],
31| 'ROS' => ['name' => 'Aprofundamento ROS'],
32| 'QUASE_ACIDENTE' => ['name' => 'Aprofundamento Quase Acidente'],
33| ];
34|
35| public static function isFixedTechnicalOccurrenceKey(?string $key): bool
36| {
37| return $key !== null && $key !== '' && in_array($key, self::FIXED_TECHNICAL_OCCURRENCE_KEYS, true);
38| }
39|
40| public function __construct(ManagerRegistry $registry)
41| {
42| parent::__construct($registry, SsmaPermissionTag::class);
43| }
44|
45| /**
46| * @return SsmaPermissionTag[]
47| */
48| public function findByCompanyOrdered(Company $company): array
49| {
50| return $this->createQueryBuilder('t')
51| ->where('t.company = :company')
52| ->setParameter('company', $company)
53| ->orderBy('t.createdAt', 'ASC')
54| ->getQuery()
55| ->getResult();
56| }
57|
58| public function toArray(SsmaPermissionTag $tag, array $allMembers = []): array
59| {
60| $memberIds = [];
61| $clinics = [];
62| foreach ($tag->getMemberLinks() as $link) {
63| $mid = $link->getCompanyMember()->getId();
64| $memberIds[] = $mid;
65| if ($link->getClinica() !== null && $link->getClinica() !== '') {
66| $clinics[(string) $mid] = $link->getClinica();
67| }
68| }
69|
70| $members = [];
71| if (!empty($allMembers)) {
72| foreach ($allMembers as $m) {
73| if (in_array($m['id'], $memberIds, true)) {
74| $members[] = $m;
75| }
76| }
77| }
78|
79| return [
80| 'id' => $tag->getId(),
81| 'name' => $tag->getName(),
82| 'occurrence_type_key' => $tag->getOccurrenceTypeKey(),
83| 'member_ids' => $memberIds,
84| 'members' => $members,
85| 'clinics' => $clinics,
86| ];
87| }
88|
89| /**
90| * Garante as tags fixas de aprofundamento técnico (acidentes + ROS/Quase Acidente), na ordem do Figma.
91| *
92| * @return SsmaPermissionTag[]
93| */
94| public function ensureFixedTechnicalTagsForCompany(Company $company): array
95| {
96| $em = $this->getEntityManager();
97| $out = [];
98| $needsFlush = false;
99| foreach (self::FIXED_TECHNICAL_OCCURRENCE_KEYS as $typeKey) {
100| $def = self::FIXED_TECHNICAL_TAG_DEFS[$typeKey] ?? ['name' => $typeKey];
101| $tag = $this->findOneBy([
102| 'company' => $company,
103| 'occurrenceTypeKey' => $typeKey,
104| ]);
105| if (!$tag instanceof SsmaPermissionTag) {
106| $tag = new SsmaPermissionTag();
107| $tag->setCompany($company);
108| $tag->setOccurrenceTypeKey($typeKey);
109| $tag->setName($def['name']);
110| $em->persist($tag);
111| $needsFlush = true;
112| } elseif ($tag->getName() !== $def['name']) {
113| $tag->setName($def['name']);
114| $needsFlush = true;
115| }
116| $out[] = $tag;
117| }
118| if ($needsFlush) {
119| $em->flush();
120| }
121|
122| return $out;
123| }
124|}
125|
file_read
Show Details
Arguments
{"file_path": "src/Service/Ssma/SsmaOccurrenceTypeConfigService.php", "start_line": 600, "end_line": 830}
Result
File: src/Service/Ssma/SsmaOccurrenceTypeConfigService.php (Total lines: 1479)
IS_TRUNCATED: false
LINE_RANGE: 600-830
600|
601| /** @param mixed $selected @param list<string> $locations @return list<string> */
602| private function normalizeSelectedLocations(mixed $selected, array $locations): array
603| {
604| if (!is_array($selected)) {
605| return [];
606| }
607|
608| $list = [];
609| foreach ($selected as $item) {
610| $value = is_string($item) || is_numeric($item)
611| ? trim((string) $item)
612| : (is_array($item) ? trim((string) ($item['label'] ?? $item['name'] ?? $item['value'] ?? '')) : '');
613| if ($value !== '' && in_array($value, $locations, true) && !in_array($value, $list, true)) {
614| $list[] = $value;
615| }
616| }
617|
618| return array_values($list);
619| }
620|
621| /**
622| * Locais que devem aparecer no select do registro (selected ∩ catálogo).
623| *
624| * @return list<string>
625| */
626| public function getVisibleLocations(Company $company): array
627| {
628| $cfg = $this->getTypesForFrontend($company);
629|
630| return array_values(array_filter(
631| is_array($cfg['selected_locations'] ?? null) ? $cfg['selected_locations'] : [],
632| static fn ($v): bool => is_string($v) && $v !== ''
633| ));
634| }
635|
636| /**
637| * Mapa aprofundamento: occurrenceTypeKey → CompanyTeam.id
638| *
639| * @return array<string, int> e.g. ['ACIDENTE_PESSOAL' => 5, 'ACIDENTE_AMBIENTAL' => 7]
640| */
641| public function getAprofundamentoMap(Company $company): array
642| {
643| $entity = $this->findOrCreateEntity($company);
644| $stored = $entity->getTypesData();
645| $raw = $stored['aprofundamento_map'] ?? [];
646| if (!is_array($raw)) {
647| return [];
648| }
649| $out = [];
650| foreach ($raw as $typeKey => $teamId) {
651| if (is_string($typeKey) && $typeKey !== '' && is_numeric($teamId) && (int) $teamId > 0) {
652| $out[$typeKey] = (int) $teamId;
653| }
654| }
655|
656| return $out;
657| }
658|
659| /**
660| * @param array<string, int> $map ['ACIDENTE_PESSOAL' => teamId, ...]
661| */
662| public function saveAprofundamentoMap(Company $company, array $map): void
663| {
664| $entity = $this->findOrCreateEntity($company);
665| $stored = $entity->getTypesData();
666|
667| $normalized = [];
668| foreach ($map as $typeKey => $teamId) {
669| if (is_string($typeKey) && $typeKey !== '' && is_numeric($teamId) && (int) $teamId > 0) {
670| $normalized[$typeKey] = (int) $teamId;
671| }
672| }
673|
674| $stored['aprofundamento_map'] = $normalized;
675| $entity->setTypesData($stored);
676| $this->em->flush();
677| }
678|
679| /**
680| * Flags "pode descaracterizar" por grupo de aprofundamento.
681| * Chave composta: "team:{id}" ou "tag:{id}" → lista de memberIds.
682| *
683| * @return list<int>
684| */
685| public function getAprofundamentoDescaracterMemberIds(Company $company, string $groupKind, int $groupId): array
686| {
687| $entity = $this->findOrCreateEntity($company);
688| $stored = $entity->getTypesData();
689| $raw = $stored['aprofundamento_descaracter'] ?? [];
690| if (!is_array($raw)) {
691| return [];
692| }
693| $key = $this->aprofundamentoDescaracterKey($groupKind, $groupId);
694| $ids = $raw[$key] ?? [];
695| if (!is_array($ids)) {
696| return [];
697| }
698|
699| return array_values(array_unique(array_filter(array_map('intval', $ids), static fn (int $id): bool => $id > 0)));
700| }
701|
702| public function setAprofundamentoDescaracterMember(
703| Company $company,
704| string $groupKind,
705| int $groupId,
706| int $memberId,
707| bool $enabled
708| ): void {
709| if ($memberId <= 0 || $groupId <= 0) {
710| return;
711| }
712| $entity = $this->findOrCreateEntity($company);
713| $stored = $entity->getTypesData();
714| $raw = is_array($stored['aprofundamento_descaracter'] ?? null) ? $stored['aprofundamento_descaracter'] : [];
715| $key = $this->aprofundamentoDescaracterKey($groupKind, $groupId);
716| $ids = isset($raw[$key]) && is_array($raw[$key]) ? array_map('intval', $raw[$key]) : [];
717| $ids = array_values(array_unique(array_filter($ids, static fn (int $id): bool => $id > 0)));
718|
719| if ($enabled) {
720| if (!in_array($memberId, $ids, true)) {
721| $ids[] = $memberId;
722| }
723| } else {
724| $ids = array_values(array_filter($ids, static fn (int $id): bool => $id !== $memberId));
725| }
726|
727| if ($ids === []) {
728| unset($raw[$key]);
729| } else {
730| $raw[$key] = $ids;
731| }
732| $stored['aprofundamento_descaracter'] = $raw;
733| $entity->setTypesData($stored);
734| $this->em->flush();
735| }
736|
737| /**
738| * Coluna Descaracterizar da tag de aprofundamento daquele tipo (ex.: tag 23 = QUASE_ACIDENTE).
739| */
740| public function memberCanDescharacterizeForType(Company $company, int $memberId, string $typeKey): bool
741| {
742| if ($memberId <= 0 || $typeKey === '') {
743| return false;
744| }
745| $tags = $this->em->getRepository(SsmaPermissionTag::class)->findBy([
746| 'company' => $company,
747| 'occurrenceTypeKey' => $typeKey,
748| ]);
749| foreach ($tags as $tag) {
750| $tagId = (int) $tag->getId();
751| if ($tagId <= 0) {
752| continue;
753| }
754| if (in_array($memberId, $this->getAprofundamentoDescaracterMemberIds($company, 'tag', $tagId), true)) {
755| return true;
756| }
757| }
758|
759| return false;
760| }
761|
762| /**
763| * @return array<string, bool>
764| */
765| public function getDescharacterizeFlagsByType(Company $company, int $memberId): array
766| {
767| $out = [];
768| foreach (SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS as $typeKey) {
769| $out[$typeKey] = $this->memberCanDescharacterizeForType($company, $memberId, $typeKey);
770| }
771|
772| return $out;
773| }
774|
775| /** True se o membro aparece em qualquer grupo com permissão de descaracterizar. */
776| public function memberCanDescharacterizeAccident(Company $company, int $memberId): bool
777| {
778| if ($memberId <= 0) {
779| return false;
780| }
781| $entity = $this->findOrCreateEntity($company);
782| $stored = $entity->getTypesData();
783| $raw = $stored['aprofundamento_descaracter'] ?? [];
784| if (!is_array($raw)) {
785| return false;
786| }
787| foreach ($raw as $ids) {
788| if (!is_array($ids)) {
789| continue;
790| }
791| foreach ($ids as $id) {
792| if ((int) $id === $memberId) {
793| return true;
794| }
795| }
796| }
797|
798| return false;
799| }
800|
801| /**
802| * Todos os memberIds com flag de descaracterização em qualquer grupo.
803| *
804| * @return list<int>
805| */
806| public function getAllDescaracterMemberIds(Company $company): array
807| {
808| $entity = $this->findOrCreateEntity($company);
809| $stored = $entity->getTypesData();
810| $raw = $stored['aprofundamento_descaracter'] ?? [];
811| if (!is_array($raw)) {
812| return [];
813| }
814| $out = [];
815| foreach ($raw as $ids) {
816| if (!is_array($ids)) {
817| continue;
818| }
819| foreach ($ids as $id) {
820| $mid = (int) $id;
821| if ($mid > 0) {
822| $out[$mid] = $mid;
823| }
824| }
825| }
826|
827| return array_values($out);
828| }
829|
830| /**
Request #38
deepseek-v4-flash
P:24.51K C:413 CR:20.61K CW:0
3650ms
Reasoning
Now, note the confirmed finding #2 concerns that new check `memberCanDescharacterizeForType` ignores `team:{id}` links. Given the controller in this diff now reads `$ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']` from the map. The old helper method `ssmaMemberCanDescharacterizeAccident` in the controller—what did it do? Let me look at it (already flagged #1).
Let me check the controller around line 12531 to see the context and other usages of `ssmaCanDescharacterizeAccident`. And confirm whether `getDescharacterizeFlagsByType` etc. are new. Let me also check other existing places that use the new partial include for `_modal_event.html.twig` with `ssmaCanDescharacterizeByType` variable — i.e., are there other controllers/endpoints that render the `_modal_event.html.twig`? If other routes call this template without providing the variable, the `|default({})` will hide the descaracter block for ACIDENTE_PESSOAL (confirming earlier issue 3 partially). Let me check where `_modal_event.html.twig` is included.
Let me search includes of `_modal_event.html.twig` and `_ev_injured_person_box.html.twig`.
Tool Calls (3)
code_search
Show Details
Arguments
{"search_text": "_modal_event.html.twig"}
Result
File: .opencodereview/rule.json
Match lines: 1
56| "path": "templates/ssma/occurrence/partials/_modal_event.html.twig",
File: .opencodereview/rules/ssma/occurrence-ros-aprofundamento-readonly.md
Match lines: 2
7|- `templates/ssma/occurrence/partials/_modal_event.html.twig` — `EvModal.openAprofundamento`, `evAprofundamentoCanEditFromServer`, `evCanEditAprofundamento`, `evSetAprofundamentoReadonly`
35|**Modal (`_modal_event.html.twig`):**
File: CONFLITOS_REAIS_DYNAMIC_COLOR_ICONS.md
Match lines: 1
152|- `templates/ssma/occurrence/partials/_modal_event.html.twig` ✅
File: docs/engineering/pr/feature-ssma-ocorrencia-correcoes-new-production/PR_descricao_feature-ssma-ocorrencia-correcoes-new-production.md
Match lines: 1
29|- `occurrence_view.html.twig`, `_tab_occurrences.html.twig`, `_modal_event.html.twig` — Readequação, validação, suspeita/caracterizar só para médico (`.is-doctor-aprof`), Reprovar com cor da plataforma
File: docs/engineering/pr/homolog/PR_arquivos_homolog.txt
Match lines: 1
71|M templates/ssma/occurrence/partials/_modal_event.html.twig
File: docs/engineering/pr/homolog/PR_impacto_homolog.txt
Match lines: 1
71| .../occurrence/partials/_modal_event.html.twig | 54 +++-
File: docs/engineering/pr/hotfix-ssma-ambiental-material-brenda-new-production/PR_descricao_hotfix-ssma-ambiental-material-brenda-new-production.md
Match lines: 2
41|- Formulário compartilhado `_modal_event.html.twig` — listagem e detalhe.
84|| `_modal_event.html.twig` | AA nativo, barreiras, consequências, AP, ROS/QA, exclusão envolvido/testemunha |
File: docs/engineering/pr/hotfix-ssma-ap-validacao-etapa1-new-production/PR_arquivos_hotfix-ssma-ap-validacao-etapa1-new-production.txt
Match lines: 1
225|M templates/ssma/occurrence/partials/_modal_event.html.twig
File: docs/engineering/pr/hotfix-ssma-ap-validacao-etapa1-new-production/PR_descricao_hotfix-ssma-ap-validacao-etapa1-new-production.md
Match lines: 1
45|| `_modal_event.html.twig` | Etapa 1 não envia campos técnicos para Membro; botão **Registrar**; validação só do passo ativo; labels humanizadas nos toasts |
File: docs/engineering/pr/hotfix-ssma-ap-validacao-etapa1-new-production/PR_impacto_hotfix-ssma-ap-validacao-etapa1-new-production.txt
Match lines: 1
225| .../occurrence/partials/_modal_event.html.twig | 1821 ++++++++----
File: docs/engineering/pr/hotfix-ssma-occ-type-perms-datatables-new-production/PR_arquivos_hotfix-ssma-occ-type-perms-datatables-new-production.txt
Match lines: 1
7|M templates/ssma/occurrence/partials/_modal_event.html.twig
File: docs/engineering/pr/hotfix-ssma-occ-type-perms-datatables-new-production/PR_descricao_hotfix-ssma-occ-type-perms-datatables-new-production.md
Match lines: 2
36|- Formulário compartilhado `_modal_event.html.twig` (create/update de ocorrências e aprofundamento).
93|| `templates/ssma/occurrence/partials/_modal_event.html.twig` | `EvModal.openAprofundamento`, botões rascunho/finalizar, payload `aprofundamento_only` |
File: docs/engineering/pr/hotfix-ssma-occ-type-perms-datatables-new-production/PR_impacto_hotfix-ssma-occ-type-perms-datatables-new-production.txt
Match lines: 1
7| .../occurrence/partials/_modal_event.html.twig | 146 ++++++-
File: docs/engineering/pr/hotfix-ssma-ros-barrier-type-422/PR_descricao_hotfix-ssma-ros-barrier-type-422.md
Match lines: 1
50|| Flash report | `occurrence_view.html.twig`, `_modal_event.html.twig`, `_tab_config.html.twig`, `new_automation.html.twig` |
File: docs/engineering/pr/hotfix-ssma-ux-pos-merge-231-new-production/PR_arquivos_hotfix-ssma-ux-pos-merge-231-new-production.txt
Match lines: 1
7|M templates/ssma/occurrence/partials/_modal_event.html.twig
File: docs/engineering/pr/hotfix-ssma-ux-pos-merge-231-new-production/PR_impacto_hotfix-ssma-ux-pos-merge-231-new-production.txt
Match lines: 1
7| .../occurrence/partials/_modal_event.html.twig | 35 +-
File: docs/engineering/pr/new_staging2/PR_arquivos_new_staging2.txt
Match lines: 1
1631|M templates/ssma/occurrence/partials/_modal_event.html.twig
File: docs/engineering/pr/new_staging2/PR_impacto_new_staging2.txt
Match lines: 1
1631| .../occurrence/partials/_modal_event.html.twig | 162 +-
File: docs/logs/engineering/frontend_console_inventory.md
Match lines: 1
794|| templates/ssma/occurrence/partials/_modal_event.html.twig | templates | nao | 2 | 0 | 2 | 0 | 0 | 0 | 0 |
File: docs/pr-hotfix-ssma-ap-parte-medica-new-production.md
Match lines: 1
25|| Alterado | `templates/ssma/occurrence/partials/_modal_event.html.twig` |
File: docs/ssma/ALINHAMENTO-TITULO-OPCIONAL-E-MEMBROS-SEM-ADMIN.md
Match lines: 2
229|- UI: `_modal_event.html.twig` — esconder `#ev-gravity-wrap` nos tipos com `#ev_consequence`; mostrar badge/read-only de gravidade no bloco de classificação técnica.
269|- UI: `_modal_event.html.twig` — opções de `#ev_work_leave` + filtro/auto-select do select de classificação ao mudar afastamento.
File: docs/ssma/CORRECOES-FECHAMENTO-FIGMA-PENDENTES.md
Match lines: 3
38|**Onde:** `templates/ssma/occurrence/partials/_modal_event.html.twig` (`ev_datetime`, `evDefaultDatetimeToday`).
95|| 3 | `_modal_event.html.twig` |
97|| 5 | `_modal_event.html.twig`, `SsmaController.php`, `SsmaEventValidator.php` |
File: docs/ssma/CORRECOES-OCORRENCIA-FIGMA-PARTE-2.md
Match lines: 1
46|- UI: `_modal_event.html.twig` / `_modal_occurrence.html.twig` (`SSMA_IS_AURA_ADMIN`, hide na criação).
File: docs/ssma/PAINEL-OCORRENCIAS-INDICADORES-PLANO.md
Match lines: 1
377|| Classificação FAC/LTI/RWC/MTC | `_modal_event.html.twig` → `#ev_injury_classification`; persistido em `SsmaEvent.details.injury_classification` |
File: docs/ssma/PRODUTO_SSMA_MAPA_COMPLETO.md
Match lines: 2
199|3. No offcanvas **Evento SSMA** (`_modal_event.html.twig`): escolher tipo (ROS, Quase acidente, Acidente pessoal/material/ambiental).
219|| Criar/editar evento | `_modal_event.html.twig` |
File: docs/ssma/ocorrencia-01-colab-acidentado-pessoas-envolvidas.md
Match lines: 1
21|| Filtro do select | `evFilterInjuredPersonSelect()` em `_modal_event.html.twig` |
File: templates/ssma/occurrence/index.html.twig
Match lines: 1
114| {% include 'ssma/occurrence/partials/_modal_event.html.twig' with {
File: templates/ssma/occurrence/occurrence_view.html.twig
Match lines: 1
1308| {% include 'ssma/occurrence/partials/_modal_event.html.twig' with {
File: templates/ssma/occurrence/partials/_modal_occurrence.html.twig
Match lines: 1
2|{# Modal legado (listagem/detalhe). Fluxo principal de registro: _modal_event.html.twig (offcanvas tipado). #}
File: templates/ssma/occurrence/tabs/_tab_occurrences.html.twig
Match lines: 1
1891| // ── Open "Nova ocorrência" offcanvas (implementação em _modal_event.html.twig) ──
File: templates/ssma/partials/_ssma_body_map_entry.html.twig
Match lines: 1
9| - occurrence/partials/_modal_event.html.twig → Novo evento / edição
File: tests/Ssma/ValidateLocalFixesTest.php
Match lines: 2
18| * 2. _modal_event.html.twig — todos os <option value> batem com EnvironmentalMediumEnum
87| // Exatamente as <option value="..."> de _modal_event.html.twig para ACIDENTE_AMBIENTAL
File: tests/Unit/Product/Ssma/SsmaBodyMapEntryRegressionTest.php
Match lines: 1
46| $modal = $this->read('templates/ssma/occurrence/partials/_modal_event.html.twig');
File: tests/Unit/Product/Ssma/assert_branch_ui_fixes.php
Match lines: 2
40|$modal = $root . '/templates/ssma/occurrence/partials/_modal_event.html.twig';
201|$modalEvent = $root . '/templates/ssma/occurrence/partials/_modal_event.html.twig';
File: tests/Unit/Product/Ssma/assert_flash_report_flow.php
Match lines: 1
140|$modalEvent = $root . '/templates/ssma/occurrence/partials/_modal_event.html.twig';
code_search
Show Details
Arguments
{"search_text": "_ev_injured_person_box.html.twig"}
Result
File: docs/engineering/pr/hotfix-ssma-ambiental-material-brenda-new-production/PR_descricao_hotfix-ssma-ambiental-material-brenda-new-production.md
Match lines: 1
87|| `_ev_injured_person_box.html.twig` | Consequências no card do acidentado |
File: docs/engineering/pr/hotfix-ssma-ap-validacao-etapa1-new-production/PR_arquivos_hotfix-ssma-ap-validacao-etapa1-new-production.txt
Match lines: 1
222|M templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig
File: docs/engineering/pr/hotfix-ssma-ap-validacao-etapa1-new-production/PR_impacto_hotfix-ssma-ap-validacao-etapa1-new-production.txt
Match lines: 1
222| .../partials/_ev_injured_person_box.html.twig | 106 +-
File: docs/ssma/ocorrencia-02-caixinha-por-acidentado.md
Match lines: 1
21|| Template da caixinha | `_ev_injured_person_box.html.twig` |
File: docs/ssma/ocorrencia-03-data-atendimento.md
Match lines: 1
21|| Input | `.ev-inj-attendance` em `_ev_injured_person_box.html.twig` |
File: docs/ssma/ocorrencia-04-breve-relato.md
Match lines: 1
22|| Textarea | `.ev-inj-relato` em `_ev_injured_person_box.html.twig` |
File: docs/ssma/ocorrencia-06-tudo-na-caixinha-descaracter.md
Match lines: 1
25|| Campos da pessoa | `_ev_injured_person_box.html.twig` |
File: docs/ssma/ocorrencia-07-suspeita-descaracterizacao-ui.md
Match lines: 1
31|| UI na caixinha | `_ev_injured_person_box.html.twig` |
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 1
671| {% include 'ssma/occurrence/partials/_ev_injured_person_box.html.twig' with {
File: tests/Unit/Product/Ssma/assert_branch_ui_fixes.php
Match lines: 1
43|$injured = $root . '/templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig';
code_search
Show Details
Arguments
{"search_text": "ssmaCanDescharacterizeByType"}
Result
File: src/Controller/SsmaController.php
Match lines: 3
12534| $ssmaCanDescharacterizeByType = ($company instanceof Company && $currentMemberForExport)
12540| $ssmaCanDescharacterizeAccident = (bool) ($ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false);
12658| 'ssmaCanDescharacterizeByType' => $ssmaCanDescharacterizeByType,
File: templates/ssma/occurrence/index.html.twig
Match lines: 1
126| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
File: templates/ssma/occurrence/occurrence_view.html.twig
Match lines: 1
1320| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
File: templates/ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig
Match lines: 1
3|{% if ssmaCanDescharacterizeByType[_type_key]|default(false) %}
File: templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig
Match lines: 1
192| {% if ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']|default(false) %}
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 5
467| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
541| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
676| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
889| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
909| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
Request #39
deepseek-v4-flash
P:28.53K C:375 CR:24.83K CW:0
4193ms
Reasoning
Interesting. There is a new partial `_ev_descaracter_suspect_block.html.twig` inserted into the modal for each type. There's an important UI bug possibility: The type-specific descaracter blocks render even in the case when user is creating occurrence. But the descaracter UI is supposed to be an "aprofundamento" phase item only. Yet if the user is registering a new occurrence (basic) without aprofundamento, they may see the descaracter suspect block. But before this, the block was probably shown/hidden in specific phases. Let me look at the surrounding context to understand where those blocks are inserted (in the `ev-spec-type-card` and `ev-technical-section`?). ROS block inserted inside the `ev-spec-type-card` — but that seems odd since descaracterização is only in aprofundamento, not spec type card.
Actually, wait. Let me read the context around these insertion lines to understand. Around lines 462-545, we have the sections for ROS and QUASE_ACIDENTE in the "spec type card"? and around 884-909 ACIDENTE_MATERIAL / ACIDENTE_AMBIENTAL within `ev-technical-section`.
Let me read lines 400-560 and 640-920 in the file to understand where the blocks are being included.
Tool Calls (1)
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 380, "end_line": 560}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 380-560
380| <div class="form-group">
381| <label>Evidências</label>
382| <div id="ev_evidence_area"
383| class="border rounded p-3 bg-light d-flex align-items-center flex-wrap text-muted occ-upload-area ssma-shared-upload-area">
384| <i class="fas fa-paperclip mr-2"></i>
385| <span>Arraste o(s) arquivo(s) até aqui ou </span>
386| <label for="ev_evidence_input" class="text-primary mb-0 ml-1 occ-upload-link ssma-shared-upload-link">selecione do computador</label>
387| <input type="file" id="ev_evidence_input" name="ev_evidence[]"
388| multiple class="d-none" accept="image/*,application/pdf,.doc,.docx,.xls,.xlsx">
389| </div>
390| <div id="ev_evidence_list" class="mt-2"></div>
391| </div>
392|
393| </div>
394|
395| </div>{# /ev-step-general-cards #}
396|
397| </div>{# /ev-step-general #}
398|
399| <div id="ev-step-aprofundamento" class="ev-step-panel d-none">
400|
401| <div id="ev-aprofundamento-denied-alert" class="alert alert-warning py-2 px-3 d-none" role="alert">
402| <i class="fas fa-exclamation-triangle mr-2"></i>O aprofundamento é preenchido pelo profissional responsável (gestor direto do colaborador ou equipe técnica SSMA).
403| </div>
404|
405| {# ROS / Quase Acidente: Aprofundamento Técnico (classificatório) #}
406| <div class="card app-card-surface p-3 mb-3 d-none" id="ev-spec-type-card">
407| <h5 class="ssma-form-section text-primary mb-3 d-none" id="ev-spec-type-card-title" aria-hidden="true">Campos do tipo</h5>
408|
409| {# ── ROS ──────────────────────────────── #}
410| {# Risco imediato, Sugestão de melhoria e Visto e resolvido na 1ª etapa (#ev-ros-step1-extra). #}
411| <div id="ev-block-ros" class="ev-type-block d-none">
412| <div class="form-row">
413| <div class="col-12">
414| <div class="form-group">
415| <label for="ev_deviation_type">Tipo de desvio <span class="text-danger">*</span></label>
416| <select class="form-control" id="ev_deviation_type" name="ev_deviation_type">
417| <option value="" disabled selected>–</option>
418| {# Valores alinhados a App\Enum\Ssma\DeviationTypeEnum #}
419| <option value="COMPORTAMENTO">Ato inseguro</option>
420| <option value="CONDICAO_INSEGURA">Condição insegura</option>
421| <option value="PROCEDIMENTO">Desvio de procedimento</option>
422| <option value="FALTA_EPP">Falta de EPI</option>
423| <option value="IMPROVISO">Improviso</option>
424| <option value="OUTRO">Outro</option>
425| </select>
426| </div>
427| </div>
428| </div>
429| <div class="form-row">
430| <div class="col-12">
431| <div class="form-group">
432| <label for="ev_involvement_type_ros">Envolvimento <span class="text-danger">*</span></label>
433| <select class="form-control" id="ev_involvement_type_ros" name="ev_involvement_type">
434| <option value="" disabled selected>–</option>
435| {# ROS: Saúde / Segurança / Meio Ambiente (App\Enum\Ssma\RosInvolvementTypeEnum) #}
436| <option value="SAUDE">Saúde</option>
437| <option value="SEGURANCA">Segurança</option>
438| <option value="MEIO_AMBIENTE">Meio Ambiente</option>
439| </select>
440| </div>
441| </div>
442| </div>
443| {% include 'ssma/occurrence/partials/_ev_shared_barrier.html.twig' with {
444| _barrier_suffix: '_ros',
445| _hide_failed_barrier: true,
446| _show_barrier_help: true
447| } %}
448| <div class="form-row mt-1" id="ev-ros-pc-row">
449| <div class="col-12">
450| <div class="form-group">
451| <label for="ev_ros_potential_consequence">Consequência potencial <span class="text-danger">*</span></label>
452| <select class="form-control" id="ev_ros_potential_consequence" name="ev_ros_potential_consequence">
453| <option value="" disabled selected>Selecione a consequência</option>
454| {% include 'ssma/occurrence/partials/_ev_consequence_options.html.twig' %}
455| </select>
456| </div>
457| {# Gravidade espelha a consequência potencial (mesmo valor) #}
458| <div id="ev-ros-derived-severity-wrap" class="mt-2">
459| <label class="text-muted small d-block mb-1">Gravidade da ocorrência (automática)</label>
460| <span id="ev-ros-derived-severity-badge" class="ssma-shared-tag"
461| style="background:rgba(108,117,125,0.10);color:#6c757d;border-color:#adb5bd;">—</span>
462| </div>
463| </div>
464| </div>
465| {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
466| type_key: 'ROS',
467| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
468| } %}
469| </div>
470|
471| {# ── QUASE ACIDENTE ───────────────────── #}
472| <div id="ev-block-qa" class="ev-type-block d-none">
473| <div class="form-row">
474| <div class="col-12">
475| <div class="form-group">
476| <label for="ev_involvement_type_qa">Envolvimento <span class="text-danger">*</span></label>
477| <select class="form-control" id="ev_involvement_type_qa" name="ev_involvement_type">
478| <option value="" disabled selected>–</option>
479| <option value="PERSON">Pessoa</option>
480| <option value="EQUIPMENT">Equipamento</option>
481| <option value="ENVIRONMENT">Ambiente</option>
482| <option value="PROCESS">Processo</option>
483| </select>
484| </div>
485| </div>
486| </div>
487|
488| <div id="ev-qa-person-row" class="form-row d-none">
489| <div class="col-6">
490| <div class="form-group">
491| <label for="ev_person_id_qa">Colaborador envolvido <span class="text-danger">*</span></label>
492| {% set ev_person_qa_options = [{'value': '', 'text': 'Selecione a pessoa'}] %}
493| {% for member in allMembers %}
494| {% set ev_person_qa_options = ev_person_qa_options|merge([{
495| 'value': member.id,
496| 'text': member.name
497| }]) %}
498| {% endfor %}
499| {% include 'components/ui/_custom_select.html.twig' with {
500| id: 'ev_person_id_qa',
501| name: 'ev_person_id_qa',
502| label: 'Selecione a pessoa',
503| options: ev_person_qa_options
504| } %}
505| </div>
506| </div>
507| <div class="col-6">
508| <div class="form-group">
509| <label for="ev_person_type_qa">Tipo de vínculo <span class="text-danger">*</span></label>
510| <select class="form-control" id="ev_person_type_qa" name="ev_person_type_qa">
511| <option value="COLABORADOR" selected>CLT</option>
512| <option value="PRESTADOR">PJ / Prestador</option>
513| <option value="TERCEIRO">Terceirizado</option>
514| </select>
515| </div>
516| </div>
517| </div>
518| {% include 'ssma/occurrence/partials/_ev_shared_barrier.html.twig' with {
519| _barrier_suffix: '_qa',
520| _hide_failed_barrier: true,
521| _show_barrier_help: true
522| } %}
523| <div class="form-row mt-1" id="ev-qa-pc-row">
524| <div class="col-12">
525| <div class="form-group">
526| <label for="ev_qa_potential_consequence">Consequência potencial <span class="text-danger">*</span></label>
527| <select class="form-control" id="ev_qa_potential_consequence" name="ev_qa_potential_consequence">
528| <option value="" disabled selected>Selecione a consequência</option>
529| {% include 'ssma/occurrence/partials/_ev_consequence_options.html.twig' %}
530| </select>
531| </div>
532| <div id="ev-qa-derived-severity-wrap" class="mt-2">
533| <label class="text-muted small d-block mb-1">Gravidade da ocorrência (automática)</label>
534| <span id="ev-qa-derived-severity-badge" class="ssma-shared-tag"
535| style="background:rgba(108,117,125,0.10);color:#6c757d;border-color:#adb5bd;">—</span>
536| </div>
537| </div>
538| </div>
539| {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
540| type_key: 'QUASE_ACIDENTE',
541| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
542| } %}
543| </div>
544|
545| </div>{# /ev-spec-type-card #}
546|
547| {# Gravidade manual legada — oculto quando ROS/QA usam TAG automática #}
548| <div class="card app-card-surface p-3 mb-3 d-none" id="ev-gravity-wrap">
549| <div class="form-group mb-0">
550| <label for="ev_criticality">Gravidade da Ocorrência <span class="text-danger">*</span></label>
551| <select class="form-control" id="ev_criticality" name="ev_criticality">
552| <option value="" disabled selected>Selecione</option>
553| <option value="LEVE">Leve</option>
554| <option value="BAIXO">Baixo</option>
555| <option value="MEDIO">Médio</option>
556| <option value="ALTO">Alto</option>
557| <option value="SEVERO">Severo</option>
558| </select>
559| </div>
560| </div>
Request #40
deepseek-v4-flash
P:31.81K C:1.43K CR:28.8K CW:0
12293ms
Reasoning
Now let me understand which context renders these blocks. These blocks are inside `ev-step-aprofundamento` (approved section). For ROS/QA and accidents. Now let me consider what happens with `ev-type-descaracter` block: It's rendered within the "type block" areas, meaning in aprofundamento mode. In these descaracter blocks, the JS handles user selection; they are only useful in `aprofundamento` step for ROS/QA/AM/AA types. But wait — was descaracterização ever shown in aprofundamento for ROS/QA? Actually originally, the description says "Descaracterização — só no aprofundamento." The AP descaracterização is inside the injured person's box (card) which is in the aprofundamento area.
Now one interesting question: In the aprofundamento flow (EvModal.openAprofundamento), the view only shows ONE type (the occurrence's type). For new occurrence create mode, the general step then aprofundamento for that type. The type block is shown for the currently-selected type. So the new partial gets rendered in the DOM of the currently shown type's block.
But there could be a functional mismatch: the newly added UI gives a suspicion checkbox per type that enables only if the specific tag column is checked. But the same data (`descaracter_suspect`, `descaracterizado`, `descaracter_comment`) is written into a single global storage key in the event payload. Wait — but the payload uses same field names for all types. So storing descaracter fields is global to the event regardless of type. Actually that may be by design since an occurrence has a single type. The old global `ev_descaracter_suspect`/`ev_descaracterizado` also per event.
Actually, the concern in confirmed finding #4 was that the blocks read/write global hidden input shared across types—if user switches types during creation or toggles, the check may persist into the wrong type. That's already reported.
Now what new issues might remain?
1. The new block renders only for the type being edited. Fine.
2. The `_ev_descaracter_suspect_block.html.twig` partial receives a `_type_key` via `type_key|default('')`. But for the `ACIDENTE_PESSOAL` (AP), the descaracter block is handled inside the injured person card in `_ev_injured_person_box.html.twig` (per-person), which is separate. In the AP injured card, the block shows per-person and uses classes `.ev-inj-suspect-chk` etc. There's still the `ev-inj-descaracter-toggle` and comments, and it has id `ev-inj-descaracter`. But the AP block at line 192 is now gated on flag `ACIDENTE_PESSOAL` — the same as the by-type permission. That is issue #3.
Now, look at data reading: in the JS that reads details to populate, line 6545+ reads `det.descaracter_suspect`, `data.descaracter_suspect`, and `det.descaracter_comment`, then sets each per-type root. In the read-only view, root checkbox state toggled. OK.
Another potential new issue: The JS for payload building—When saving the ROS type, `evApplyTypeDescaracterPayload(payload, 'ROS')` reads root block. But this is applied on all saves, including the general step "save draft/registrar" in which the aprofundamento step hasn't happened (ev-step-aprofundamento not active). But the `evGetTypeDescaracterRoot(type)` returns an element that exists in the DOM (always rendered if permission), regardless of whether the aprofundamento step is active or completed. The checkbox is unchecked by default, so it would set `payload.descaracter_suspect = 0`. Hmm, but payload would then always include `descaracter_suspect: 0` on creating even if not previously. Not harmful probably.
Actually more subtle: In `evApplyTypeDescaracterPayload`, if `chk` is checked, sets `payload.descaracter_suspect=1`; sets `descaracterizado` only when the global hidden has value '0' or '1'. If comment filled without suspect checked, comment stored. OK.
But consider when the aprofundamento previously had descaracter_suspect = 1 and user opens the event in general step (not aprofundamento) and saves? The `ev_descaracter_suspect` global checkbox may be outside the current step? Need to look.
Actually, `evApplyTypeDescaracterPayload` is called within the type branch of the "save payload" function. That function probably runs on general step too (for draft on create). But per-type fields only get included when the type is the selected one. Yet root for the selected type always exists in DOM (rendered if permission). However, if the occurrence is of type ROS, then in the general step (step 1, when creating an event) the aprofundamento blocks are inside `ev-step-aprofundamento` (d-none) but still in DOM. So payload.descaracter_suspect defaults to 0 for a new occurrence when saving step 1. Would that break anything? Possibly setting descaracter_suspect = 0 for step-1 events where field not applicable... this is speculative. Data stored as JSON `details`; no strict schema, not necessarily an issue.
But there's something more concrete: `evIsDescaracterSuspectChecked()` now returns true when any `.ev-type-descaracter-suspect:checked` exists. Where is `evIsDescaracterSuspectChecked` used? Let me search.
Also look for usage of `descaracter_suspect` to understand backend semantics and whether per-type root affects the rendering of the AP global block etc.
Let me search the file for `evIsDescaracterSuspectChecked`, `descaracter_suspect`, `ev_descaracterizado`, `descaracter_comment`.
Tool Calls (3)
code_search
Show Details
Arguments
{"search_text": "evIsDescaracterSuspectChecked"}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 4
2216| descaracter_suspect: evIsDescaracterSuspectChecked() ? 1 : 0,
2925| function evIsDescaracterSuspectChecked() {
5815| // Espelha no campo global usado pelo payload (evIsDescaracterSuspectChecked).
7200| payload.descaracter_suspect = evIsDescaracterSuspectChecked() ? 1 : 0;
code_search
Show Details
Arguments
{"search_text": "descaracter_suspect"}
Result
File: GUIA_MERGE_TAB_OCCURRENCES.md
Match lines: 2
232| data-descaracter-suspect="{{ occ.descaracter_suspect|default(0) }}"
252| data-descaracter-suspect="{{ occ.descaracter_suspect|default(0) }}"
File: RESUMO_MAURICIO_MARCOS.md
Match lines: 1
136| data-descaracter-suspect="{{ occ.descaracter_suspect|default(0) }}"
File: docs/ssma/CORRECOES-FECHAMENTO-FIGMA-PENDENTES.md
Match lines: 1
81|| Há suspeita de descaracterização | `suspeita_sim` | `descaracter_suspect = 1` |
File: docs/ssma/ocorrencia-06-tudo-na-caixinha-descaracter.md
Match lines: 1
27|| Persistência ocorrência | `#ev_descaracter_suspect` + `#ev_descaracterizado` (hiddens sincronizados) |
File: docs/ssma/ocorrencia-07-suspeita-descaracterizacao-ui.md
Match lines: 1
20|| Suspeita marcada | `descaracter_suspect` | `1` |
File: docs/ssma/ocorrencia-08-filtro-aprofundamento-descaracter.md
Match lines: 1
14|| Há suspeita de descaracterização | `suspeita_sim` | `descaracter_suspect = 1` |
File: src/Controller/SsmaController.php
Match lines: 6
14433| 'descaracter_suspect' => !empty($details['descaracter_suspect']) ? 1 : 0,
26988| 'injured_person_details', 'descaracter_suspect', 'descaracterizado', 'descaracter_comment', 'witness_ids',
27084| foreach (['descaracter_suspect', 'descaracterizado', 'descaracter_comment'] as $descKey) {
27096| if (isset($details['descaracter_suspect'])) {
27097| $details['descaracter_suspect'] = !empty($details['descaracter_suspect']) && $details['descaracter_suspect'] !== '0' ? 1 : 0;
27332| 'descaracter_suspect',
File: src/Service/Ssma/Export/SsmaOccurrenceExportRowMapper.php
Match lines: 1
156| 'ap_descaracter_suspect' => SsmaOccurrenceExportLabels::boolLabel($d['descaracter_suspect'] ?? null),
File: src/Service/Ssma/Export/SsmaOccurrenceExportSchema.php
Match lines: 1
76| 'ap_descaracter_suspect' => 'Suspeita de descaracterização?',
File: src/Service/Ssma/SsmaAutomationService.php
Match lines: 2
647| $suspect = ($payload['descaracter_suspect'] ?? '0') === '1';
2030| $payload['descaracter_suspect'] = !empty($details['descaracter_suspect']) ? '1' : '0';
File: src/Service/Ssma/SsmaEventService.php
Match lines: 5
161| 'descaracter_suspect', 'descaracterizado', 'descaracter_comment',
186| if (!empty($card['descaracter_suspect'])) {
187| $details['descaracter_suspect'] = 1;
188| } elseif (array_key_exists('descaracter_suspect', $card)) {
189| $details['descaracter_suspect'] = 0;
File: src/Service/Ssma/SsmaEventValidator.php
Match lines: 1
719| $hasSuspect = !empty($d['descaracter_suspect']) && $d['descaracter_suspect'] !== '0';
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 17
291| <input class="form-check-input" type="checkbox" id="ev_descaracter_suspect" name="ev_descaracter_suspect" value="1">
292| <label class="form-check-label" for="ev_descaracter_suspect">Há suspeita de descaracterização do acidente?</label>
465| {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
539| {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
887| {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
907| {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
2216| descaracter_suspect: evIsDescaracterSuspectChecked() ? 1 : 0,
2926| var el = document.getElementById('ev_descaracter_suspect');
2939| payload.descaracter_suspect = chk && chk.checked ? 1 : 0;
5774| var suspectChk = document.getElementById('ev_descaracter_suspect');
5788| var globalChk = document.getElementById('ev_descaracter_suspect');
5816| var globalChk = document.getElementById('ev_descaracter_suspect');
6545| var suspectRaw = det.descaracter_suspect != null ? det.descaracter_suspect : data.descaracter_suspect;
6547| evSetChk('ev_descaracter_suspect', suspectOn);
7184| var suspectEl = document.getElementById('ev_descaracter_suspect');
7200| payload.descaracter_suspect = evIsDescaracterSuspectChecked() ? 1 : 0;
7217| suspectEl.checked = !!payload.descaracter_suspect;
File: templates/ssma/occurrence/tabs/_tab_occurrences.html.twig
Match lines: 3
458| data-descaracter-suspect="{{ occ.descaracter_suspect|default(0) }}"
1667| ' data-descaracter-suspect="' + escapeHtml(String(occurrenceData.descaracter_suspect ? 1 : 0)) + '"' +
1745| rowNode.setAttribute('data-descaracter-suspect', occurrenceData.descaracter_suspect ? '1' : '0');
code_search
Show Details
Arguments
{"search_text": "ev_descaracterizado"}
Result
File: docs/ssma/ocorrencia-06-tudo-na-caixinha-descaracter.md
Match lines: 1
27|| Persistência ocorrência | `#ev_descaracter_suspect` + `#ev_descaracterizado` (hiddens sincronizados) |
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 7
828| <input type="hidden" id="ev_descaracterizado" name="ev_descaracterizado" value="">
2648| var hidden = document.getElementById('ev_descaracterizado');
2940| var descVal = String((document.getElementById('ev_descaracterizado') || {}).value || '');
2977| var hidden = document.getElementById('ev_descaracterizado');
5796| var hidden = document.getElementById('ev_descaracterizado');
6567| evSetVal('ev_descaracterizado', descVal == null ? '' : String(descVal));
7192| descFromCard = String((document.getElementById('ev_descaracterizado') || {}).value || '');
Request #41
deepseek-v4-flash
P:35.18K C:213 CR:33.15K CW:0
2553ms
Reasoning
Let me read some of these key sections to understand the new flow in detail: around line 260-330 (general step's global suspect), 2190-2230, 2900-2990, 5770-5830, 6530-6600, 7170-7230.
I want to see the newly inserted code more fully and see potential bugs like:
- In AP injured card, only those with permission can check suspect and also the card toggling to hidden.
- The new partial blocks and interactions.
Let me read these ranges.
Tool Calls (1)
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 640, "end_line": 920}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 640-920
640| <label class="mb-1">Colaborador(es) acidentado(s) <span class="text-danger">*</span></label>
641| </div>
642| {# Select oculto — só compatibilidade JS (primary id / legado). UI = cards (Brenda). #}
643| <div class="d-none" id="ev-person-id-select-wrap" aria-hidden="true">
644| {% set ev_person_options = [{'value': '', 'text': 'Selecione a pessoa (entre as envolvidas)'}] %}
645| {% for member in allMembers %}
646| {% set ev_person_options = ev_person_options|merge([{
647| 'value': member.id,
648| 'text': member.name
649| }]) %}
650| {% endfor %}
651| {% include 'components/ui/_custom_select.html.twig' with {
652| id: 'ev_person_id',
653| name: 'ev_person_id',
654| label: 'Selecione a pessoa (entre as envolvidas)',
655| options: ev_person_options
656| } %}
657| </div>
658| </div>
659| <input type="hidden" id="ev_person_type" name="ev_person_type" value="COLABORADOR">
660| </div>
661| <p id="ev-injured-person-empty" class="small text-muted mb-2">
662| Nenhuma pessoa em <strong>Pessoas envolvidas</strong>. Adicione quem participou do evento para registrar os acidentados.
663| </p>
664| <p id="ev-injured-person-summary" class="small text-muted mb-2 d-none">
665| <i class="fas fa-info-circle mr-1"></i><span id="ev-injured-person-summary-text"></span>
666| </p>
667| <div id="ev_injured_person_boxes" class="mb-3"></div>
668| <input type="hidden" id="ev_injured_person_details" name="ev_injured_person_details" value="">
669| {# Fonte para clone (div oculta — mais confiável que <template> no offcanvas) #}
670| <div id="ev-injured-person-box-tpl" class="d-none" aria-hidden="true">
671| {% include 'ssma/occurrence/partials/_ev_injured_person_box.html.twig' with {
672| person_id: '',
673| person_name: '',
674| attendance_date: '',
675| breve_relato: '',
676| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
677| } %}
678| </div>
679|
680| {# Body map fica estacionado aqui e é movido para dentro da caixinha do acidentado #}
681| <div id="ev-body-map-park" class="d-none" aria-hidden="true">
682| <div id="ev-body-map-block" class="d-none mt-2 ev-ap-body-map-field">
683| <p class="mb-1 ev-ap-body-map-title">Partes do corpo</p>
684| <div id="ev-body-map-wrap" class="w-100">
685| <div id="ev-body-map-host" class="ssma-ev-body-map-host d-flex justify-content-center mb-3"></div>
686| {# Um float por lado (mão esq/dir, pé esq/dir) — posição via JS (data-region no SVG) #}
687| <div id="ev_extremity_hand_float_esq" class="ev-extremity-float d-none" aria-hidden="true">
688| <div class="ev-ef-label">Mão esq. <span class="ev-ef-subtitle">dedo(s)</span></div>
689| <div class="ev-ef-checks">
690| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="POLEGAR"> Polegar</label>
691| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="INDICADOR"> Indicador</label>
692| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="MEDIO"> Dedo médio</label>
693| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="ANULAR"> Anelar</label>
694| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="MINIMO"> Mínimo</label>
695| </div>
696| <input type="hidden" id="ev_hand_finger_esq" name="ev_hand_finger_esq" value="">
697| </div>
698| <div id="ev_extremity_hand_float_dir" class="ev-extremity-float d-none" aria-hidden="true">
699| <div class="ev-ef-label">Mão dir. <span class="ev-ef-subtitle">dedo(s)</span></div>
700| <div class="ev-ef-checks">
701| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="POLEGAR"> Polegar</label>
702| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="INDICADOR"> Indicador</label>
703| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="MEDIO"> Dedo médio</label>
704| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="ANULAR"> Anelar</label>
705| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="MINIMO"> Mínimo</label>
706| </div>
707| <input type="hidden" id="ev_hand_finger_dir" name="ev_hand_finger_dir" value="">
708| </div>
709| <div id="ev_extremity_foot_float_esq" class="ev-extremity-float d-none" aria-hidden="true">
710| <div class="ev-ef-label">Pé esq. <span class="ev-ef-subtitle">dedo(s)</span></div>
711| <div class="ev-ef-checks">
712| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="HALUX"> Hálux</label>
713| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="SEGUNDO_DEDO"> 2º dedo</label>
714| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="TERCEIRO_DEDO"> 3º dedo</label>
715| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="QUARTO_DEDO"> 4º dedo</label>
716| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="MINIMO_PE"> Mínimo</label>
717| </div>
718| <input type="hidden" id="ev_foot_toe_esq" name="ev_foot_toe_esq" value="">
719| </div>
720| <div id="ev_extremity_foot_float_dir" class="ev-extremity-float d-none" aria-hidden="true">
721| <div class="ev-ef-label">Pé dir. <span class="ev-ef-subtitle">dedo(s)</span></div>
722| <div class="ev-ef-checks">
723| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="HALUX"> Hálux</label>
724| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="SEGUNDO_DEDO"> 2º dedo</label>
725| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="TERCEIRO_DEDO"> 3º dedo</label>
726| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="QUARTO_DEDO"> 4º dedo</label>
727| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="MINIMO_PE"> Mínimo</label>
728| </div>
729| <input type="hidden" id="ev_foot_toe_dir" name="ev_foot_toe_dir" value="">
730| </div>
731| <div id="ev_zone_cabeca_float" class="ev-extremity-float ev-zone-float d-none" aria-hidden="true">
732| <div class="ev-ef-label">Cabeça <span class="ev-ef-subtitle">detalhe</span></div>
733| <div class="ev-ef-checks ev-ef-checks--grid">
734| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="OLHO_ESQ"> Olho esq.</label>
735| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="OLHO_DIR"> Olho dir.</label>
736| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="BOCA"> Boca</label>
737| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="NARIZ"> Nariz</label>
738| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="ORELHA_ESQ"> Orelha esq.</label>
739| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="ORELHA_DIR"> Orelha dir.</label>
740| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="TESTA"> Testa</label>
741| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="MENTO"> Queixo</label>
742| </div>
743| <input type="hidden" id="ev_cabeca_zones" name="ev_cabeca_zones" value="">
744| </div>
745| <div id="ev_zone_pescoco_float" class="ev-extremity-float ev-zone-float d-none" aria-hidden="true">
746| <div class="ev-ef-label">Pescoço <span class="ev-ef-subtitle">detalhe</span></div>
747| <div class="ev-ef-checks">
748| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="PESCOCO_ANT"> À frente</label>
749| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="PESCOCO_POST"> Nuca</label>
750| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="PESCOCO_LAT_ESQ"> Lado esq.</label>
751| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="PESCOCO_LAT_DIR"> Lado dir.</label>
752| </div>
753| <input type="hidden" id="ev_pescoco_zones" name="ev_pescoco_zones" value="">
754| </div>
755| <div id="ev_zone_face_float" class="ev-extremity-float ev-zone-float d-none" aria-hidden="true">
756| <div class="ev-ef-label">Face <span class="ev-ef-subtitle">detalhe</span></div>
757| <div class="ev-ef-checks ev-ef-checks--grid">
758| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="FACE_BOCA"> Boca</label>
759| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="FACE_NARIZ"> Nariz</label>
760| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="FACE_BOCHE_ESQ"> Bochecha esq.</label>
761| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="FACE_BOCHE_DIR"> Bochecha dir.</label>
762| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="FACE_MENTO"> Mento</label>
763| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="FACE_MAXILAR"> Maxilar</label>
764| </div>
765| <input type="hidden" id="ev_face_zones" name="ev_face_zones" value="">
766| </div>
767| <div id="ev_zone_olhos_float" class="ev-extremity-float ev-zone-float d-none" aria-hidden="true">
768| <div class="ev-ef-label">Olhos <span class="ev-ef-subtitle">detalhe</span></div>
769| <div class="ev-ef-checks">
770| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="OLHO_ESQ"> Olho esq.</label>
771| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="OLHO_DIR"> Olho dir.</label>
772| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="SOBRANCELHA_ESQ"> Sobrancelha esq.</label>
773| <label class="ev-ef-check-item"><input type="checkbox" class="ev-ef-cb" value="SOBRANCELHA_DIR"> Sobrancelha dir.</label>
774| </div>
775| <input type="hidden" id="ev_olhos_zones" name="ev_olhos_zones" value="">
776| </div>
777| </div>
778| <div class="form-group mb-0">
779| <select id="ev_body_region_select" class="d-none ssma-tag-engine-select" tabindex="-1" aria-hidden="true">
780| <option value="">Selecione a região</option>
781| <option value="CABECA">Cabeça</option>
782| <option value="OLHOS">Olhos</option>
783| <option value="FACE">Face</option>
784| <option value="PESCOCO">Pescoço</option>
785| <option value="OMBRO_ESQ">Ombro esquerdo</option>
786| <option value="OMBRO_DIR">Ombro direito</option>
787| <option value="OMBRO">Ombro (ambos — legado)</option>
788| <option value="BRACO_ESQ">Braço esquerdo</option>
789| <option value="BRACO_DIR">Braço direito</option>
790| <option value="BRACO">Braço (ambos — legado)</option>
791| <option value="ANTEBRACO_ESQ">Antebraço esquerdo</option>
792| <option value="ANTEBRACO_DIR">Antebraço direito</option>
793| <option value="ANTEBRACO">Antebraço (ambos — legado)</option>
794| <option value="MAO_ESQ">Mão esquerda</option>
795| <option value="MAO_DIR">Mão direita</option>
796| <option value="MAO">Mão (ambas — legado)</option>
797| <option value="TORAX">Tórax</option>
798| <option value="ABDOMEN">Abdômen</option>
799| <option value="COSTAS">Costas</option>
800| <option value="QUADRIL_ESQ">Quadril esquerdo</option>
801| <option value="QUADRIL_DIR">Quadril direito</option>
802| <option value="QUADRIL">Quadril (ambos — legado)</option>
803| <option value="COXA_ESQ">Coxa esquerda</option>
804| <option value="COXA_DIR">Coxa direita</option>
805| <option value="COXA">Coxa (ambas — legado)</option>
806| <option value="JOELHO_ESQ">Joelho esquerdo</option>
807| <option value="JOELHO_DIR">Joelho direito</option>
808| <option value="JOELHO">Joelho (ambos — legado)</option>
809| <option value="PERNA_ESQ">Perna esquerda</option>
810| <option value="PERNA_DIR">Perna direita</option>
811| <option value="PERNA">Perna (ambas — legado)</option>
812| <option value="PE_ESQ">Pé esquerdo</option>
813| <option value="PE_DIR">Pé direito</option>
814| <option value="PE">Pé (ambos — legado)</option>
815| <option value="MULTIPLO">Múltiplo</option>
816| </select>
817| <p class="mb-1 small text-muted d-none" id="ev-body-region-tags-label">Regiões selecionadas</p>
818| <div id="ev_body_region_tags" class="d-none" role="list" aria-labelledby="ev-body-region-tags-label"></div>
819| </div>
820| <div class="form-group mb-0 mt-3 d-none">
821| <label for="ev_body_location_detail">Detalhamento da localização <span class="text-muted font-weight-normal">(opcional)</span></label>
822| <textarea class="form-control" id="ev_body_location_detail" name="ev_body_location_detail" rows="2" maxlength="2000" placeholder="Ex.: face lateral do joelho, próximo ao cotovelo…"></textarea>
823| </div>
824| </div>
825| </div>{# /#ev-body-map-park #}
826|
827| {# Caracterizado: valor sincronizado a partir da caixinha do acidentado. Suspeita fica na 1ª etapa. #}
828| <input type="hidden" id="ev_descaracterizado" name="ev_descaracterizado" value="">
829| </div>{# /#ev-ap-pessoa-caixinha #}
830| {# Regra de produto: custo removido de AP — só AM possui custo.
831| ROS e Quase acidente são comunicativos — sem custo; Ambiental não usa este campo. #}
832| <p class="small text-muted mb-0">Após a análise, você ainda pode adicionar novas evidências.</p>
833| </div>
834|
835| {# ── ACIDENTE MATERIAL ────────────────── #}
836| <div id="ev-block-am" class="ev-type-block d-none">
837| <div class="form-row">
838| <div class="col-6">
839| <div class="form-group">
840| <label for="ev_asset_type">Tipo do ativo afetado <span class="text-danger">*</span></label>
841| <select class="form-control" id="ev_asset_type" name="ev_asset_type">
842| <option value="" disabled selected>–</option>
843| <option value="MAQUINA">Máquina</option>
844| <option value="VEICULO">Veículo</option>
845| <option value="ESTRUTURA">Estrutura</option>
846| <option value="INSTALACAO_ELETRICA">Instalação elétrica</option>
847| <option value="TUBULACAO">Tubulação</option>
848| <option value="OUTRO">Outro</option>
849| </select>
850| </div>
851| </div>
852| {# Custo do acidente — só Acidente Material (removido de Acidente Pessoal). #}
853| <div class="col-6">
854| <div class="form-group">
855| <label for="ev_estimated_loss">Custo do acidente</label>
856| <div class="input-group">
857| <div class="input-group-prepend">
858| <span class="input-group-text">R$</span>
859| </div>
860| <input type="number" class="form-control" id="ev_estimated_loss" name="ev_estimated_loss"
861| min="0" step="0.01" placeholder="0,00">
862| </div>
863| </div>
864| </div>
865| </div>
866| <div class="form-row">
867| <div class="col-6">
868| <div class="form-group">
869| <label for="ev_downtime">Parada (horas)</label>
870| <input type="number" class="form-control" id="ev_downtime" name="ev_downtime"
871| min="0" step="0.5" placeholder="0">
872| </div>
873| </div>
874| </div>
875| <div class="form-group">
876| <div class="form-check">
877| <input class="form-check-input" type="checkbox" id="ev_operational_impact" name="ev_operational_impact" value="1">
878| <label class="form-check-label" for="ev_operational_impact">Impacto operacional?</label>
879| </div>
880| </div>
881| {# Brenda: só Tipo de barreira (sem Dimensão / Barreira que falhou). #}
882| {% include 'ssma/occurrence/partials/_ev_shared_barrier.html.twig' with {
883| _barrier_suffix: '_am',
884| _hide_failed_barrier: true,
885| _show_barrier_help: true
886| } %}
887| {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
888| type_key: 'ACIDENTE_MATERIAL',
889| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
890| } %}
891| </div>
892|
893| {# ── ACIDENTE AMBIENTAL ───────────────── #}
894| <div id="ev-block-aa" class="ev-type-block d-none">
895| {# Meio/poluente/volume/contenção → Identificação (ev-aa-ident-fields). Impacto externo removido. #}
896| <div class="form-group">
897| <label for="ev_affected_area">Área afetada</label>
898| <input type="text" class="form-control" id="ev_affected_area" name="ev_affected_area"
899| placeholder="Descreva a área afetada (opcional)">
900| </div>
901| {# Brenda: só Tipo de barreira (sem Dimensão / Barreira que falhou). #}
902| {% include 'ssma/occurrence/partials/_ev_shared_barrier.html.twig' with {
903| _barrier_suffix: '_aa',
904| _hide_failed_barrier: true,
905| _show_barrier_help: true
906| } %}
907| {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
908| type_key: 'ACIDENTE_AMBIENTAL',
909| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
910| } %}
911| </div>
912|
913| </div>{# /ev-technical-section #}
914|
915| {# Ação imediata — Aprofundamento (lista repetível) #}
916| <div class="card app-card-surface p-3 mb-0" id="ev-corrective-actions-section">
917| <div class="d-flex align-items-center justify-content-between mb-2">
918| <h5 class="ssma-form-section text-primary mb-0">Ação imediata</h5>
919| </div>
920| <div id="ev-corrective-actions-list"></div>
Request #42
deepseek-v4-flash
P:41.4K C:218 CR:35.33K CW:0
2243ms
Reasoning
Now let me look at lines around 2190-2240 to understand the general step's descaracter_suspect global element that appears in first step and the payload building in general step.
Tool Calls (2)
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 260, "end_line": 330}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 260-330
260| <label for="ev_people_select">Pessoa(s) envolvida(s) <span class="text-danger">*</span></label>
261| <select class="form-control" id="ev_people_select" name="ev_people_select">
262| <option value="" selected disabled>Selecione quem estava envolvido</option>
263| {% for member in allMembers %}
264| <option value="{{ member.id }}"
265| data-name="{{ member.name }}"
266| data-registration="{{ member.registration|default('%07d'|format(member.id)) }}"
267| data-position="{{ member.position|default('') }}"
268| data-supervisor="{{ member.supervisor_name|default('') }}"
269| data-gerencia="{{ member.gerencia|default(member.area|default('')) }}"
270| data-shift="{{ member.work_shift_label|default('') }}">{{ member.name }}</option>
271| {% endfor %}
272| </select>
273| <div id="ev_people_tags" class="d-flex flex-wrap mt-2"></div>
274| </div>
275|
276| <div class="form-group">
277| <label for="ev_witnesses_select">Testemunhas</label>
278| <select class="form-control" id="ev_witnesses_select" name="ev_witnesses_select">
279| <option value="" selected disabled>Selecione testemunhas (opcional)</option>
280| {% for member in allMembers %}
281| <option value="{{ member.id }}" data-name="{{ member.name }}">{{ member.name }}</option>
282| {% endfor %}
283| </select>
284| <div id="ev_witnesses_tags" class="d-flex flex-wrap mt-2"></div>
285| <input type="hidden" id="ev_witness_ids" name="ev_witness_ids" value="">
286| </div>
287|
288| {# AP etapa 1: suspeita. Caracterizado só aparece no aprofundamento (médico). #}
289| <div class="form-group d-none" id="ev-suspeita-wrap">
290| <div class="form-check">
291| <input class="form-check-input" type="checkbox" id="ev_descaracter_suspect" name="ev_descaracter_suspect" value="1">
292| <label class="form-check-label" for="ev_descaracter_suspect">Há suspeita de descaracterização do acidente?</label>
293| </div>
294| </div>
295|
296| {# ROS: Risco imediato (SIM/NÃO — gatilho de automação), Sugestão de melhoria, Visto e resolvido. #}
297| <div class="d-none ev-type-block" id="ev-ros-step1-extra">
298| <div class="form-group">
299| <label class="mb-1">É risco imediato? <span class="text-danger">*</span></label>
300| <div class="d-flex" style="gap:8px;" role="group" aria-label="É risco imediato?">
301| <button type="button" class="mhs-btn-cancel js-ev-immediate-risk-opt" data-value="1" style="min-width:84px;">Sim</button>
302| <button type="button" class="mhs-btn-cancel js-ev-immediate-risk-opt active" data-value="0" style="min-width:84px;">Não</button>
303| </div>
304| <input class="d-none" type="checkbox" id="ev_immediate_risk" name="ev_immediate_risk" value="1">
305| </div>
306|
307| <div class="form-group">
308| <label for="ev_improvement_suggestions">Sugestão de melhoria</label>
309| <textarea class="form-control" id="ev_improvement_suggestions" name="ev_improvement_suggestions"
310| rows="3" placeholder="Descreva sugestões de melhoria para evitar recorrência"></textarea>
311| <div class="d-flex align-items-center mt-1" style="gap:8px;">
312| <button type="button" id="ev_improvement_ai_btn"
313| class="mhs-btn-primary d-flex align-items-center"
314| style="font-size:12px; padding:4px 12px; min-height:auto;"
315| title="Melhorar a descrição com IA">
316| <i class="fa-regular fa-sparkles mr-1" style="font-size:11px;"></i>
317| Melhore com IA
318| </button>
319| </div>
320| </div>
321|
322| <div class="form-check mt-2">
323| <input class="form-check-input" type="checkbox" id="ev_ros_resolved" name="ev_ros_resolved" value="1">
324| <label class="form-check-label" for="ev_ros_resolved">Visto e resolvido</label>
325| </div>
326| <div id="ev-ros-resolved-fields" class="d-none mt-2">
327| <div class="form-group">
328| <label for="ev_ros_resolution_notes">O que foi feito para resolver</label>
329| <textarea class="form-control" id="ev_ros_resolution_notes" name="ev_ros_resolution_notes"
330| rows="2" placeholder="Descreva a ação tomada (opcional)"></textarea>
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 2180, "end_line": 2240}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 2180-2240
2180| function evAssignCanonicalInjuryIds(card) {
2181| if (!card) return;
2182| evClearCanonicalInjuryIds();
2183| var map = [
2184| ['.ev-inj-had-injury', EV_INJ_CANONICAL_IDS.had],
2185| ['.ev-inj-injury-type', EV_INJ_CANONICAL_IDS.type],
2186| ['.ev-inj-injury-severity', EV_INJ_CANONICAL_IDS.severity],
2187| ['.ev-inj-work-leave', EV_INJ_CANONICAL_IDS.leave],
2188| ['.ev-inj-injury-classification', EV_INJ_CANONICAL_IDS.classification]
2189| ];
2190| map.forEach(function (pair) {
2191| var el = card.querySelector(pair[0]);
2192| if (el) el.id = pair[1];
2193| });
2194| var had = card.querySelector('.ev-inj-had-injury');
2195| var hadLabel = had && had.closest('.form-check') ? had.closest('.form-check').querySelector('label') : null;
2196| if (had) {
2197| had.name = 'ev_had_injury';
2198| if (!had.id) had.id = EV_INJ_CANONICAL_IDS.had;
2199| if (hadLabel) hadLabel.setAttribute('for', had.id);
2200| }
2201| }
2202|
2203| function evReadCardInjuryData(card) {
2204| if (!card) return {};
2205| var isActive = card.classList.contains('is-expanded');
2206| var data = {
2207| attendance_date: (card.querySelector('.ev-inj-attendance') || {}).value || '',
2208| breve_relato: (card.querySelector('.ev-inj-relato') || {}).value || '',
2209| had_injury: !!(card.querySelector('.ev-inj-had-injury') || {}).checked,
2210| injury_type: (card.querySelector('.ev-inj-injury-type') || {}).value || '',
2211| injury_severity: (card.querySelector('.ev-inj-injury-severity') || {}).value || '',
2212| work_leave: (card.querySelector('.ev-inj-work-leave') || {}).value || '',
2213| injury_classification: (card.querySelector('.ev-inj-injury-classification') || {}).value || '',
2214| consequence: (card.querySelector('.ev-inj-consequence') || {}).value || '',
2215| potential_consequence: (card.querySelector('.ev-inj-potential-consequence') || {}).value || '',
2216| descaracter_suspect: evIsDescaracterSuspectChecked() ? 1 : 0,
2217| descaracterizado: '',
2218| descaracter_comment: (card.querySelector('.ev-inj-descaracter-comment') || {}).value || '',
2219| body_parts: []
2220| };
2221| var cardDescHidden = card.getAttribute('data-descaracterizado');
2222| if (cardDescHidden !== null && cardDescHidden !== '') {
2223| data.descaracterizado = cardDescHidden;
2224| } else {
2225| var cardBtns = card.querySelectorAll('.ev-inj-descaracter-btn.active');
2226| if (cardBtns.length) {
2227| data.descaracterizado = cardBtns[0].getAttribute('data-descaracter-val') || '';
2228| }
2229| }
2230| if (isActive) {
2231| data.body_parts = evCollectActiveBodyParts();
2232| var bld = document.getElementById('ev_body_location_detail');
2233| data.body_location_detail = bld && bld.value ? String(bld.value).trim() : '';
2234| } else {
2235| var prev = evGetInjuredDetailsObj()[card.getAttribute('data-person-id')] || {};
2236| data.body_parts = Array.isArray(prev.body_parts) ? prev.body_parts : [];
2237| data.body_location_detail = prev.body_location_detail || '';
2238| }
2239| return data;
2240| }
Request #43
deepseek-v4-flash
P:44.02K C:224 CR:41.6K CW:0
2336ms
Reasoning
Now let's examine lines 5760-5830, and 6530-6600, 7160-7230. This will show how the per-type roots sync with the global checkbox and payload building.
Tool Calls (2)
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 5760, "end_line": 5850}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 5760-5850
5760| if (potEl) {
5761| potEl.addEventListener('change', evPersistDraftSoon);
5762| }
5763| var derivedSel = document.getElementById('ev_derived_criticality_select');
5764| if (derivedSel) {
5765| derivedSel.addEventListener('change', function () {
5766| var hidden = document.getElementById('ev_derived_criticality');
5767| var critSel = document.getElementById('ev_criticality');
5768| if (hidden) hidden.value = this.value || '';
5769| if (critSel && this.value) critSel.value = this.value;
5770| evPersistDraftSoon();
5771| });
5772| }
5773| // Descaracterização: suspeita na 1ª etapa; caracterizado na caixinha (aprofundamento).
5774| var suspectChk = document.getElementById('ev_descaracter_suspect');
5775| if (suspectChk) {
5776| suspectChk.addEventListener('change', function () {
5777| evSyncDescaracterStageUi();
5778| evSyncInjuredPersonDetailsHidden();
5779| evPersistDraftSoon();
5780| });
5781| }
5782| document.querySelectorAll('[data-descaracter-root]').forEach(function (root) {
5783| var chk = root.querySelector('.ev-type-descaracter-suspect');
5784| var yesNo = root.querySelector('.ev-type-descaracter-yesno');
5785| if (chk && yesNo) {
5786| chk.addEventListener('change', function () {
5787| yesNo.classList.toggle('d-none', !chk.checked);
5788| var globalChk = document.getElementById('ev_descaracter_suspect');
5789| if (globalChk) globalChk.checked = chk.checked;
5790| evPersistDraftSoon();
5791| });
5792| }
5793| root.addEventListener('click', function (e) {
5794| var btn = e.target && e.target.closest ? e.target.closest('.ev-type-desc-btn') : null;
5795| if (!btn) return;
5796| var hidden = document.getElementById('ev_descaracterizado');
5797| if (hidden) hidden.value = btn.getAttribute('data-descaracter-val') || '';
5798| if (window.SsmaShared && typeof window.SsmaShared.toggleYesNo === 'function') {
5799| window.SsmaShared.toggleYesNo(root.querySelectorAll('.ev-type-desc-btn'), hidden ? hidden.value : null, {
5800| valueAttr: 'data-descaracter-val'
5801| });
5802| }
5803| evPersistDraftSoon();
5804| });
5805| });
5806| // Checkbox de suspeita por card (aprofundamento): mostra/oculta Sim/Não do próprio card.
5807| document.addEventListener('change', function (e) {
5808| if (!e.target || !e.target.classList.contains('ev-inj-suspect-chk')) return;
5809| var card = e.target.closest('.ev-injured-person-box');
5810| if (!card) return;
5811| var yesNoWrap = card.querySelector('.ev-inj-descaracter-yesno-wrap');
5812| if (yesNoWrap) yesNoWrap.classList.toggle('d-none', !e.target.checked);
5813| // Atualiza o data-descaracter-suspect do card para serialização.
5814| card.setAttribute('data-descaracter-suspect', e.target.checked ? '1' : '0');
5815| // Espelha no campo global usado pelo payload (evIsDescaracterSuspectChecked).
5816| var globalChk = document.getElementById('ev_descaracter_suspect');
5817| if (globalChk) globalChk.checked = e.target.checked;
5818| evSyncInjuredPersonDetailsHidden();
5819| evPersistDraftSoon();
5820| });
5821| var contDone = document.getElementById('ev_containment_done');
5822| if (contDone) {
5823| contDone.addEventListener('change', function () {
5824| evSyncContainmentTimeEnabled();
5825| evPersistDraftSoon();
5826| });
5827| }
5828| var form = document.getElementById('form-event-new');
5829| if (form) {
5830| form.addEventListener('change', evPersistDraftSoon);
5831| form.addEventListener('input', evPersistDraftSoon);
5832| }
5833| document.addEventListener('ev:formLoaded', function () {
5834| evSyncCriticalityField(evSelectedType());
5835| evSyncDerivedSeverityFromConsequence();
5836| evSyncInjuryTypeByConsequence();
5837| evSyncInjuryClassificationByLeave();
5838| if (typeof window.initAllCustomSelectWrappers === 'function') {
5839| window.initAllCustomSelectWrappers();
5840| }
5841| evFilterInjuredPersonSelect();
5842| evSyncDescaracterUi();
5843| evSyncContainmentTimeEnabled();
5844| });
5845| document.addEventListener('ev:peopleTagsChanged', function () {
5846| evFilterInjuredPersonSelect();
5847| evSyncInjuredCardsFromInvolved();
5848| });
5849| // jQuery .on: o _custom_select dispara change via $.trigger (não chega em addEventListener nativo em alguns casos).
5850| if (window.jQuery) {
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 6525, "end_line": 6600}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 6525-6600
6525| if (type === 'ACIDENTE_PESSOAL') {
6526| // Re-sync depois das tags + details: garante caixinhas médicas mesmo se
6527| // setTagSelectValues rodou antes do hidden ou membro não estava no select.
6528| syncBodyRegionVisibility();
6529| evSyncInjuryFieldsByConsequence();
6530| if (typeof window.evSyncLtiAvailability === 'function') { window.evSyncLtiAvailability(); }
6531| evSyncInjuredCardsFromInvolved();
6532| // Se sync ainda não viu pessoas nas tags, remonta a partir dos details salvos.
6533| var wrapAfter = document.getElementById('ev_injured_person_boxes');
6534| var hasMedCards = !!(wrapAfter && wrapAfter.querySelector('.ev-injured-person-box[data-person-id]'));
6535| if (!hasMedCards && Object.keys(evGetInjuredDetailsObj() || {}).length) {
6536| evRenderInjuredPersonBoxes();
6537| }
6538| if (evCurrentStep === 'aprofundamento' && typeof evEnsurePrimaryInjuredCardExpanded === 'function') {
6539| evEnsurePrimaryInjuredCardExpanded();
6540| }
6541| }
6542|
6543| // ── Descaracterização ────────────────────────────────
6544| // Restaura suspeita por card a partir do det ou do injured_person_details do card primário.
6545| var suspectRaw = det.descaracter_suspect != null ? det.descaracter_suspect : data.descaracter_suspect;
6546| var suspectOn = suspectRaw === true || suspectRaw === 1 || suspectRaw === '1';
6547| evSetChk('ev_descaracter_suspect', suspectOn);
6548| document.querySelectorAll('[data-descaracter-root]').forEach(function (root) {
6549| var chk = root.querySelector('.ev-type-descaracter-suspect');
6550| if (chk) chk.checked = suspectOn;
6551| var yesNo = root.querySelector('.ev-type-descaracter-yesno');
6552| if (yesNo) yesNo.classList.toggle('d-none', !suspectOn);
6553| var comm = root.querySelector('.ev-type-descaracter-comment');
6554| if (comm) comm.value = det.descaracter_comment || data.descaracter_comment || '';
6555| });
6556| // Propaga suspeita para cada card (checkbox editável no aprofundamento).
6557| document.querySelectorAll('.ev-injured-person-box').forEach(function (card) {
6558| var chk = card.querySelector('.ev-inj-suspect-chk');
6559| if (chk) chk.checked = suspectOn;
6560| card.setAttribute('data-descaracter-suspect', suspectOn ? '1' : '0');
6561| var yesNoWrap = card.querySelector('.ev-inj-descaracter-yesno-wrap');
6562| if (yesNoWrap) yesNoWrap.classList.toggle('d-none', !suspectOn);
6563| });
6564| var descVal = det.descaracterizado != null ? det.descaracterizado : data.descaracterizado;
6565| if (descVal === true || descVal === 1) descVal = '1';
6566| if (descVal === false || descVal === 0) descVal = '0';
6567| evSetVal('ev_descaracterizado', descVal == null ? '' : String(descVal));
6568| evSyncDescaracterUi();
6569|
6570| // ── Evidências já anexadas ──────────────────────────
6571| var evidences = Array.isArray(det.evidences) ? det.evidences : (Array.isArray(data.evidences) ? data.evidences : []);
6572| evEvidences = evidences.map(function (e) {
6573| return {
6574| name: e.name || e.filename || '',
6575| path: e.path || '',
6576| persisted: true
6577| };
6578| });
6579| evEvidenceRenderList();
6580|
6581| // ── Labels do modal ─────────────────────────────────
6582| var btnLbl = document.getElementById('ev-btn-label');
6583| var modalTitle = document.getElementById('ev-modal-title');
6584| if (modalTitle) modalTitle.textContent = 'Editar ocorrência';
6585| evApplyAuraTitleStatusVisibility('edit');
6586| evSetStep('general');
6587| $('#ev_manager').trigger('change');
6588| };
6589|
6590| /**
6591| * Abre o offcanvas no aprofundamento (especialista).
6592| * Admin/gestor administrador edita tudo desde informações gerais — não trava o 1º passo.
6593| */
6594| window.EvModal.openAprofundamento = function (data) {
6595| data = data || {};
6596| var serverCanEditAprofundamento = (data._can_edit_aprofundamento === true || data._can_edit_aprofundamento === false)
6597| ? data._can_edit_aprofundamento
6598| : null;
6599| if (EV_IS_ADMIN_APROFUNDAMENTO && window.OccurrenceModal && typeof window.OccurrenceModal.openEdit === 'function') {
6600| window.OccurrenceModal.openEdit(data);
Request #44
deepseek-v4-flash
P:46.97K C:1.03K CR:44.16K CW:0
8235ms
Reasoning
Now, let's check where `ev_descaracter_suspect` global checkbox is shown/hidden. `#ev-suspeita-wrap` has class `d-none` and is presumably only shown for AP in step 1 (when can descharacterize). Also there's a whole read-only mode consideration (evSetAprofundamentoReadonly). Let me look at how the descaracter block relates to aprofundamento readonly mode: If a user is in "readonly" (view) mode with `evSetAprofundamentoReadonly(true)`, do the newly added `.ev-type-descaracter-suspect` and buttons become disabled? If not, this could be an issue: someone with view-only access could toggle these checkboxes... but they can't save since the form is readonly/denied. But check.
Actually, focus. The context given: "Esta PR é sobre permissão de descaracterização por tipo". There might be one more important regression: Previously (before this PR) descaracterização UI block in ROS/QA/AM/AA did not exist at all? Actually the prior ROS/QA/AM/AA blocks didn't have descaracterization UI? Wait — prior to this PR, in the "spec-type-card" there was no descaracter block at all for ROS/QA/AM/AA. The descaracterization was only an AP flow? Hmm, no. Actually there was prior global `#ev_descaracter_suspect` + Sim/Não within AP only? It seems descaracterização is an AP-only flow historically but they've extended to all types now per "coluna Descaracterizar da tag".
Let me not overcomplicate. Let me look for missing template include in `_modal_occurrence.html.twig` legacy modal that includes injured person box partial perhaps without the new context var. Actually search shows `_modal_occurrence.html.twig` only used for listagem. Let me check whether it uses the `_ev_injured_person_box.html.twig` include. The partial `_ev_injured_person_box.html.twig` is only included in `_modal_event.html.twig` at line 671.
OK.
Now let's review the potential runtime bug: In `_ev_descaracter_suspect_block.html.twig` (new partial), the text says "Há suspeita de descaracterização do acidente?" and Sim/Não toggling. But there's a data attribute `data-descaracter-root` used to scope clicks. It's used to read and write only when a permission exists.
Now potential bug: The new block includes an `<input>` checkbox `.ev-type-descaracter-suspect` type=checkbox, value=1, no `name`. That's fine.
Wait, but there's a real bug: For ACIDENTE_PESSOAL, the newly gated block within the injured card is per-card. But `evGetTypeDescaracterRoot('ACIDENTE_PESSOAL')` returns the element with data-descaracter-type='ACIDENTE_PESSOAL'? None of the newly added blocks include ACIDENTE_PESSOAL. So `evApplyTypeDescaracterPayload(payload, ...)` is called only for ROS, QUASE_ACIDENTE, ACIDENTE_MATERIAL, ACIDENTE_AMBIENTAL — not for ACIDENTE_PESSOAL. Indeed the diff didn't call for AP. Good.
Now check that the `.ev-type-descaracter-suspect:checked` may cause `evIsDescaracterSuspectChecked()` to return true when any type root checked. But in the general-step payload (line 7200), when saving an AP occurrence in the general step, the function may check AP-type `ev_descaracter_suspect` element. Since roots exist for ALL types (rendered always when permissions allow). E.g., the modal is open for editing an ROS event, and the type block root for ROS exists. If the user has descaracter permission for ROS, root is rendered. But for step-1 general save (not aprofundamento)? evApplyTypeDescaracterPayload is called per type-branch only (in aprofundamento payload). Let me look at the broader save flow at 7100-7230 to confirm.
Let me read the whole 7090-7230.
Tool Calls (1)
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 7090, "end_line": 7240}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 7090-7240
7090|
7091| if (type === 'ROS') {
7092| payload.deviation_type = document.getElementById('ev_deviation_type').value;
7093| payload.involvement_type = document.getElementById('ev_involvement_type_ros').value;
7094| // Consequência potencial = escala de gravidade; gravamos em potential_severity.
7095| // Mantém potential_consequence vazio para não conflitar com EventConsequenceEnum.
7096| payload.potential_consequence = '';
7097| payload.immediate_risk = document.getElementById('ev_immediate_risk').checked ? 1 : 0;
7098| payload.barrier_type = (document.getElementById('ev_barrier_type_ros') || { value: '' }).value;
7099| delete payload.failed_barrier;
7100| delete payload.failed_barrier_other;
7101| payload.improvement_suggestions = (document.getElementById('ev_improvement_suggestions') || { value: '' }).value;
7102| payload.ros_resolved = (document.getElementById('ev_ros_resolved') || {}).checked ? 1 : 0;
7103| payload.ros_resolution_notes = payload.ros_resolved
7104| ? ((document.getElementById('ev_ros_resolution_notes') || { value: '' }).value || '')
7105| : '';
7106| payload.ros_resolution_evidences = payload.ros_resolved ? (evRosResolutionEvidences || []).slice() : [];
7107| payload.people_ids = '';
7108| evApplyTypeDescaracterPayload(payload, 'ROS');
7109| } else if (type === 'QUASE_ACIDENTE') {
7110| payload.involvement_type = document.getElementById('ev_involvement_type_qa').value;
7111| payload.barrier_type = (document.getElementById('ev_barrier_type_qa') || { value: '' }).value;
7112| delete payload.failed_barrier;
7113| payload.potential_consequence = (document.getElementById('ev_qa_potential_consequence') || { value: '' }).value;
7114| if (payload.involvement_type === 'PERSON') {
7115| payload.person_id = (document.getElementById('ev_person_id_qa') || { value: '' }).value;
7116| payload.person_type = (document.getElementById('ev_person_type_qa') || { value: '' }).value;
7117| }
7118| evApplyTypeDescaracterPayload(payload, 'QUASE_ACIDENTE');
7119| } else if (type === 'ACIDENTE_PESSOAL') {
7120| if (typeof evSyncInjuredCardsFromInvolved === 'function') {
7121| evSyncInjuredCardsFromInvolved();
7122| }
7123| evSyncInjuredPersonDetailsHidden();
7124| var primaryId = (typeof evGetPrimaryInjuredPersonId === 'function')
7125| ? evGetPrimaryInjuredPersonId()
7126| : '';
7127| if (!primaryId) {
7128| primaryId = evFirstPeopleInvolvedId(peopleIds);
7129| }
7130| payload.person_id = primaryId || (document.getElementById('ev_person_id') || { value: '' }).value;
7131| payload.person_type = (document.getElementById('ev_person_type') || { value: '' }).value || 'COLABORADOR';
7132| var detailsObj = (typeof evGetInjuredDetailsObj === 'function') ? evGetInjuredDetailsObj() : {};
7133| var primaryData = (primaryId && detailsObj[primaryId]) ? detailsObj[primaryId] : null;
7134| var primaryCard = (typeof evGetPrimaryInjuredCard === 'function') ? evGetPrimaryInjuredCard() : null;
7135| payload.consequence = primaryCard
7136| ? ((primaryCard.querySelector('.ev-inj-consequence') || {}).value || '')
7137| : ((primaryData && primaryData.consequence) || '');
7138| payload.potential_consequence = primaryCard
7139| ? ((primaryCard.querySelector('.ev-inj-potential-consequence') || {}).value || '')
7140| : ((primaryData && primaryData.potential_consequence) || '');
7141| var consequenceReal = payload.consequence;
7142| var apDerivedCrit = evResolvePotentialSeverity(
7143| consequenceReal,
7144| payload.potential_consequence,
7145| payload.potential_severity
7146| );
7147| if (apDerivedCrit) {
7148| payload.potential_severity = apDerivedCrit;
7149| }
7150| if (consequenceReal === 'SEM_DANO') {
7151| payload.had_injury = 0;
7152| payload.injury_type = '';
7153| payload.injury_severity = '';
7154| } else {
7155| var hadEl = primaryCard
7156| ? primaryCard.querySelector('.ev-inj-had-injury')
7157| : document.getElementById('ev_had_injury');
7158| payload.had_injury = hadEl
7159| ? (hadEl.checked ? 1 : 0)
7160| : (primaryData && primaryData.had_injury ? 1 : 0);
7161| if (payload.had_injury) {
7162| var typeFromCard = primaryCard
7163| ? ((primaryCard.querySelector('.ev-inj-injury-type') || {}).value || '')
7164| : '';
7165| var sevFromCard = primaryCard
7166| ? ((primaryCard.querySelector('.ev-inj-injury-severity') || {}).value || '')
7167| : '';
7168| payload.injury_type = (document.getElementById('ev_injury_type') || { value: '' }).value
7169| || typeFromCard
7170| || (primaryData && primaryData.injury_type) || '';
7171| payload.injury_severity = (document.getElementById('ev_injury_severity') || { value: '' }).value
7172| || sevFromCard
7173| || (primaryData && primaryData.injury_severity) || '';
7174| } else {
7175| payload.injury_type = '';
7176| payload.injury_severity = '';
7177| }
7178| }
7179| payload.injury_classification = (document.getElementById('ev_injury_classification') || { value: '' }).value
7180| || (primaryData && primaryData.injury_classification) || '';
7181| payload.work_leave = (document.getElementById('ev_work_leave') || { value: '' }).value
7182| || (primaryData && primaryData.work_leave) || '';
7183| payload.injured_person_details = (document.getElementById('ev_injured_person_details') || { value: '' }).value;
7184| var suspectEl = document.getElementById('ev_descaracter_suspect');
7185| var descFromCard = (primaryData && primaryData.descaracterizado !== undefined && primaryData.descaracterizado !== '')
7186| ? String(primaryData.descaracterizado)
7187| : '';
7188| if (!descFromCard && primaryCard) {
7189| descFromCard = String(primaryCard.getAttribute('data-descaracterizado') || '');
7190| }
7191| if (!descFromCard) {
7192| descFromCard = String((document.getElementById('ev_descaracterizado') || {}).value || '');
7193| }
7194| // Fallback: médico sem permissão de descaracterizar nunca pode marcar "Não",
7195| // então se todas as fontes estiverem vazias, assume "Sim" (é acidente = '0').
7196| if (!descFromCard && evAprofundamentoOnlyMode && !evCanDescharacterizeAccident()) {
7197| descFromCard = '0';
7198| }
7199| var descAnswered = descFromCard === '0' || descFromCard === '1';
7200| payload.descaracter_suspect = evIsDescaracterSuspectChecked() ? 1 : 0;
7201| // Caracterizar só o médico no aprofundamento dedicado.
7202| if (descAnswered && evAprofundamentoOnlyMode) {
7203| payload.descaracterizado = descFromCard;
7204| } else {
7205| delete payload.descaracterizado;
7206| }
7207| var descCommentFromCard = primaryCard
7208| ? String((primaryCard.querySelector('.ev-inj-descaracter-comment') || {}).value || '').trim()
7209| : '';
7210| payload.descaracter_comment = descCommentFromCard
7211| || (primaryData && primaryData.descaracter_comment ? String(primaryData.descaracter_comment).trim() : '')
7212| || '';
7213| if (!evAprofundamentoOnlyMode) {
7214| delete payload.descaracter_comment;
7215| }
7216| if (suspectEl) {
7217| suspectEl.checked = !!payload.descaracter_suspect;
7218| }
7219| if (payload.had_injury) {
7220| var bodyParts = (typeof evCollectActiveBodyParts === 'function')
7221| ? evCollectActiveBodyParts()
7222| : [];
7223| if (!bodyParts.length && primaryData && Array.isArray(primaryData.body_parts)) {
7224| bodyParts = primaryData.body_parts;
7225| }
7226| if (bodyParts.length) payload.body_parts = bodyParts;
7227| var bldEl = document.getElementById('ev_body_location_detail');
7228| var bld = bldEl && bldEl.value ? String(bldEl.value).trim() : '';
7229| if (!bld && primaryData && primaryData.body_location_detail) bld = primaryData.body_location_detail;
7230| if (bld) payload.body_location_detail = bld;
7231| }
7232| // Campo custo removido de AP (só AM possui custo)
7233| // payload.estimated_loss = (document.getElementById('ev_estimated_loss_ap') || { value: '' }).value;
7234| payload.barrier_type = (document.getElementById('ev_barrier_type_ap') || { value: '' }).value;
7235| delete payload.failed_barrier;
7236| delete payload.strategic_nature;
7237| var apSev = evResolvePotentialSeverity(
7238| payload.consequence,
7239| payload.potential_consequence,
7240| payload.potential_severity
Request #45
deepseek-v4-flash
P:50.59K C:915 CR:48K CW:0
8644ms
Reasoning
OK. I now need to see the function that calls this payload builder; this is a big function. Note: For ROS, `evApplyTypeDescaracterPayload(payload, 'ROS')` is invoked unconditionally on save of that type. This function reads root, sets suspect and comment; reads global hidden desc. This is probably meant to be run in aprofundamento only but if general step (creating a ROS and saving at step 1), root element exists in DOM (if permission to descharacterize type ROS) and this payload may be built for step 1 general save as well, adding descaracter fields on a ROS general step where they previously didn't exist. But wait, evPayload building for step1 save probably also includes these type branches. So ROS draft saved at step 1 would now persist `descaracter_suspect=0` (and no `descaracterizado` because descVal not in 0/1? Actually it sets `payload.descaracterizado` only when global hidden value is '0' or '1'. Global hidden `ev_descaracterizado` could retain value from previous data. But if it's empty, no).
This might matter only marginally.
Now let me focus on new, distinct issues that are not yet reported, and are defensible:
Potential issue A: When the modal opens for a ROS/QA/AM/AA event in a mode where the user only views (readonly aprofundamento via `evSetAprofundamentoReadonly`), the new `.ev-type-descaracter-suspect` checkbox is still interactive? Possibly the readonly mode disables all inputs. Need to check `evSetAprofundamentoReadonly`. But this may also apply to other fields within those blocks. Given the scope says author doesn't need to alter that... maybe.
Potential issue B: The descaracter suspect block for AM/AA is inside `ev-technical-section`, but that's only aprofundamento.
Wait, there might be a real "duplicate id" issue? The new partial for ROS/QA/AM/AA adds no id except for QUASE_ACIDENTE an `id="ev-qa-descaracter"`. OK, unique.
Let's examine the risk when a user CANNOT descharacterize for a type but CAN for another. Then `_ev_injured_person_box.html.twig` (per AP card) is entirely hidden unless AP tag flag is set. This is confirmed issue #3.
Now what about the template partial passed into `_modal_event.html.twig`: index and occurrence_view pass `ssmaCanDescharacterizeByType` to `_modal_event.html.twig`, but are there other callers who include `_modal_event.html.twig` with only a subset of context (e.g., ajax-render)? From search, only the two includes. Good.
Now other possible issues:
1. `getDescharacterizeFlagsByType` and `memberCanDescharacterizeForType` run a lot of queries (N+1): For each of the 5 type keys, one `findBy` query; then for each tag (usually 1 per key = 5 queries) calls `getAprofundamentoDescaracterMemberIds`, which calls `findOrCreateEntity($company)` — reading config entity — plus entity getTypesData. That's ~10 queries per page render each time an occurrence index or view is opened. And this code is now executed on EVERY page load of the occurrences list (SSR route) and occurrence view. Reasonable performance issue? Each request: 5 tags queries + 5 config loads + possibly writes? `findOrCreateEntity` might create+flush an entity if missing — that would be a mutation on GET! Let's check `findOrCreateEntity`.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "private function findOrCreateEntity"}
Result
File: src/Service/Ssma/SsmaActionTypeConfigService.php Match lines: 1 190| private function findOrCreateEntity(Company $company): SsmaActionTypeConfig File: src/Service/Ssma/SsmaInspectionTypeConfigService.php Match lines: 1 98| private function findOrCreateEntity(Company $company): SsmaOccurrenceTypeConfig File: src/Service/Ssma/SsmaOccurrenceTypeConfigService.php Match lines: 1 1058| private function findOrCreateEntity(Company $company): SsmaOccurrenceTypeConfig
code_search
Show Details
Arguments
{"search_text": "function findOrCreateEntity", "file_patterns": ["src/Service/Ssma/SsmaOccurrenceTypeConfigService.php"]}
Result
File: src/Service/Ssma/SsmaOccurrenceTypeConfigService.php Match lines: 1 1058| private function findOrCreateEntity(Company $company): SsmaOccurrenceTypeConfig
Request #46
deepseek-v4-flash
P:51.71K C:96 CR:51.46K CW:0
1847ms
Tool Calls (1)
file_read
Show Details
Arguments
{"file_path": "src/Service/Ssma/SsmaOccurrenceTypeConfigService.php", "start_line": 1040, "end_line": 1120}
Result
File: src/Service/Ssma/SsmaOccurrenceTypeConfigService.php (Total lines: 1479)
IS_TRUNCATED: false
LINE_RANGE: 1040-1120
1040| foreach ($memberIds as $id) {
1041| $id = (int) $id;
1042| if ($id > 0) {
1043| $ids[$id] = $id;
1044| }
1045| }
1046| $stored['abordagem_coach_ids'] = array_values($ids);
1047| $entity->setTypesData($stored);
1048| $this->em->flush();
1049| }
1050|
1051| private function aprofundamentoDescaracterKey(string $groupKind, int $groupId): string
1052| {
1053| $kind = strtolower(trim($groupKind)) === 'tag' ? 'tag' : 'team';
1054|
1055| return $kind . ':' . $groupId;
1056| }
1057|
1058| private function findOrCreateEntity(Company $company): SsmaOccurrenceTypeConfig
1059| {
1060| $repo = $this->em->getRepository(SsmaOccurrenceTypeConfig::class);
1061| $e = $repo->findOneBy(['company' => $company]);
1062| if ($e instanceof SsmaOccurrenceTypeConfig) {
1063| return $e;
1064| }
1065|
1066| $e = new SsmaOccurrenceTypeConfig();
1067| $e->setCompany($company);
1068| $e->setTypesData(['types' => []]);
1069| $this->em->persist($e);
1070| $this->em->flush();
1071|
1072| return $e;
1073| }
1074|
1075| /** Catálogo completo de categorias (lista mestre SSMA). */
1076| public const MASTER_CATEGORIES = [
1077| 'Ameaça à Fauna/Flora',
1078| 'Animais Peçonhentos',
1079| 'Área de Vivência',
1080| 'Armazenamento Inadequado',
1081| 'Arranjo Físico Inadequado',
1082| 'Bacilos',
1083| 'Bactéria',
1084| 'Bloqueio de Energia',
1085| 'Calor',
1086| 'Caminho Inseguro',
1087| 'Contaminação de Curso Hídrico',
1088| 'Contaminação do Ar',
1089| 'Contaminação do Solo',
1090| 'Controle Rígido de Produtividade',
1091| 'Desvio de Trânsito',
1092| 'Desvios Relacionados à Falta de AST/APR/PT/Check List',
1093| 'Eletricidade',
1094| 'Escavação Irregular',
1095| 'Esforço Físico Intenso',
1096| 'Espaço Confinado',
1097| 'Falha em Isolamento',
1098| 'Frio',
1099| 'Fumos Metálicos',
1100| 'Fungos',
1101| 'Gases',
1102| 'Geotecnia',
1103| 'Içamento e Movimentação de Carga',
1104| 'Iluminação Inadequada',
1105| 'Imposição de Ritmo Excessivo',
1106| 'Jornadas de Trabalho Prolongadas',
1107| 'Levantamento e Transporte Manual de Peso',
1108| 'Máquinas e Equipamentos Sem Proteção',
1109| 'Monotonia e Repetitividade',
1110| 'Neblina',
1111| 'Organização e Limpeza',
1112| 'Outras Situações Causadoras de Estresse Físico e/ou Psíquico',
1113| 'Outras Situações de Risco',
1114| 'Parasitas',
1115| 'Pessoal sem Treinamento e/ou Habilitação',
1116| 'Poeira',
1117| 'Pressões Anormais',
1118| 'Probabilidade de Incêndio e Explosão',
1119| 'Queda de Material',
1120| 'Queda de Pessoas',
Request #47
deepseek-v4-flash
P:52.86K C:1.02K CR:51.71K CW:0
9532ms
Reasoning
Performance: Every invocation of `getDescharacterizeFlagsByType` does for 5 type keys: a `findBy` on SsmaPermissionTag (cached via identity map? Actually per request, each query is fresh unless same results cached). Plus per tag `getAprofundamentoDescaracterMemberIds` loads entity from repo (config per company, cached after first query via identity map) and parses stored JSON. So roughly 10 queries per request page load. That's a fixed small number; not huge. Possibly flag as a performance nit but probably not high value. The rule says report performance issues only with evidence of meaningful scale/hot path. Occurrence list pages are paged at 50 but this flag computation is once per request. Not severe.
But note `findOrCreateEntity` has side effect: on GET page load for a company with no `SsmaOccurrenceTypeConfig` record yet, it will CREATE and FLUSH a row. But that existed pre-PR already (used by `getAprofundamentoMap` etc.). Not new.
Now important conceptual check: the new `memberCanDescharacterizeForType` only considers `aprofundamento_descaracter` for tags, but what about "coluna Descaracterizar" actually being a per-tag UI config column? Wait—the doc comment says "Coluna Descaracterizar da tag de aprofundamento daquele tipo". But `aprofundamento_descaracter` in config is keyed `tag:{id}`/`team:{id}` => memberIds, stored in `SsmaOccurrenceTypeConfig.typesData['aprofundamento_descaracter']`. So "coluna Descaracterizar" per tag refers to groups of members marked to descharacterize under that tag.
Hmm wait, but from doc CORRECOES-OCORRENCIA-FIGMA-PARTE-1.md line 161: "resolve destinatários via SsmaPermissionTag + SsmaPermissionTagMember (por occurrenceTypeKey)". Not descaracterização.
Confirmed finding #2 already covers that the tag-based mapping ignores `team:{id}` config entries, and old behavior traversed all config including team.
Now new aspects not covered:
1. In `SsmaController`, `ssmaCanDescharacterizeAccident` is now only `ACIDENTE_PESSOAL` flag. But `ssmaCanDescharacterizeAccident` variable is used elsewhere in the same template section for the AP card in the index and in the AJAX view (the "suspeita editável por qualquer especialista AP; Sim/Não só quem tem permissão" comment). Confirmed finding #3 covers injured card regression. Confirmed finding #1 covers super admin/manager removal.
2. Another possible issue: For the `_modal_event.html.twig`, `_ev_injured_person_box.html.twig` include at line 671 is inside `#ev-injured-person-box-tpl` hidden template. That partial now includes the entire AP descaracter block gated on `ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']`. But because it's a template clone source, if the current user lacks the AP permission, the cloned card omits the descaracter block; but if user HAS permission, card includes it. And confirmed finding #3 flagged it.
But there is more subtlety: `_ev_descaracter_suspect_block.html.twig` renders only when the flag for that type is present. So for the current user in the index where `ssmaCanDescharacterizeByType` computed from the CURRENT member. OK.
Potential other bug: **Missing context variable in Twig `|default({})` doesn't cover nested index**: `ssmaCanDescharacterizeByType[_type_key]` — if `_type_key` not defined? type_key is passed. It's fine.
Let me look at the SsmaController in the diff more precisely, around the area. Check where `ssmaCanDescharacterizeAccident` is passed and if templates still reference `ssmaCanDescharacterizeAccident`. Also verify that the controller renders both index and occurrence_view with same computed flag; but the earlier search shows this single compute at 12531-12540. Let's read surrounding code for lines ~12500-12680 to understand the route(s).
Tool Calls (1)
file_read
Show Details
Arguments
{"file_path": "src/Controller/SsmaController.php", "start_line": 12480, "end_line": 12680}
Result
File: src/Controller/SsmaController.php (Total lines: 27765)
IS_TRUNCATED: false
LINE_RANGE: 12480-12680
12480| // O filtro por equipe nas ocorrências não deve listar inspeções da equipe inteira para esses perfis.
12481| if ($company && $user instanceof User
12482| && in_array($ssmaProductTagName, ['Membro', 'Inspetor', 'Membro (default)'], true)) {
12483| $plainMemberId = (int) ($this->getCurrentCompanyMember($company, $user)?->getId() ?? 0);
12484| $plainUserId = (int) $user->getId();
12485| $inspections = array_values(array_filter(
12486| $inspections,
12487| fn (array $row): bool => $this->preventionArrayOwnedByMember($row, $plainMemberId, $plainUserId)
12488| ));
12489| $abordagens = array_values(array_filter(
12490| $abordagens,
12491| fn (array $row): bool => $this->preventionArrayOwnedByMember($row, $plainMemberId, $plainUserId)
12492| ));
12493| }
12494|
12495| if ($needsPreventionCollections) {
12496| [$metaFromStr, $metaToStr] = $this->getPrevencaoPeriodDateBounds($metasPeriod);
12497| [$inspectionsForMetas, $abordagensForMetas] = $this->filterCollectionsForMetasRealizado(
12498| $inspections,
12499| $abordagens,
12500| $metaFromStr,
12501| $metaToStr
12502| );
12503|
12504| // Cobertura KPI (abas Inspeção/Abordagem): mesma base da aba Metas (membro + período de referência).
12505| $inspCoverage = $company
12506| ? $this->computeInspectionMetaCoverage($company, $inspectionsForMetas, $teams, '', $metaFromStr, $metaToStr)
12507| : ['pct' => null, 'meta_total' => 0, 'real_total' => 0];
12508|
12509| $abCoverage = $company
12510| ? $this->computeAbordagemMetaCoverage($company, $abordagensForMetas, $teams, '', $metaFromStr, $metaToStr)
12511| : ['pct' => null, 'meta_total' => 0, 'real_total' => 0];
12512|
12513| // Metas: usa membros filtrados por equipe para Sup/G. de Equipe (não mostrar toda a empresa).
12514| // Para G. Admin/Tenant usa a lista completa.
12515| $membersForMetas = ($occurrenceTeamFilterIds !== null && $allMembersForEventPeople !== [])
12516| ? $allMembersForEventPeople
12517| : $allMembers;
12518| $prevencaoMetasPessoa = $company
12519| ? $this->buildPrevencaoPessoaMetasData(
12520| $company,
12521| $membersForMetas,
12522| $teams,
12523| $inspectionsForMetas,
12524| $abordagensForMetas,
12525| $this->buildSupervisorGestorMemberIdSet(),
12526| $metaFromStr,
12527| $metaToStr
12528| )
12529| : ['inspecao' => [], 'abordagem' => []];
12530| }
12531|
12532| $currentMemberForExport = $this->getCurrentCompanyMember($company, $user);
12533| $ssmaExportMatricula = $currentMemberForExport?->getId() ?? '';
12534| $ssmaCanDescharacterizeByType = ($company instanceof Company && $currentMemberForExport)
12535| ? $this->ssmaOccurrenceTypeConfig->getDescharacterizeFlagsByType(
12536| $company,
12537| (int) $currentMemberForExport->getId()
12538| )
12539| : [];
12540| $ssmaCanDescharacterizeAccident = (bool) ($ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false);
12541|
12542| // Hub Ocorrências: SSR/AJAX por página (50). Se já hidratou via SQL, não fatia de novo.
12543| if (!$occurrenceListAlreadyPaged) {
12544| $occurrencesListTotal = count($occurrences);
12545| $occurrencesListPage = $paginateOccurrenceList ? $scope->listPage : 1;
12546| $occurrencesListHasMore = false;
12547| if ($paginateOccurrenceList) {
12548| $pageSize = SsmaViewDataScope::OCCURRENCE_LIST_PAGE_SIZE;
12549| $offset = ($occurrencesListPage - 1) * $pageSize;
12550| $occurrencesListHasMore = $occurrencesListTotal > ($offset + $pageSize);
12551| $occurrences = array_slice($occurrences, $offset, $pageSize);
12552| }
12553| }
12554|
12555| // Hub: não dumpa 3k–5k membros no HTML — só referenciados da página + gestores (busca via API).
12556| if (
12557| !$isOccurrenceDetailView
12558| && $this->ssmaMemberSelectDataProvider->shouldFilterToReferencedMembers($scope)
12559| && !$ssmaCanManagePermissions
12560| ) {
12561| $allMembers = $this->filterSsmaMembersToReferencedForDetail(
12562| $allMembers,
12563| $occurrences,
12564| [],
12565| $gestores
12566| );
12567| $allMembersForEventPeople = $this->filterSsmaMembersToReferencedForDetail(
12568| $allMembersForEventPeople,
12569| $occurrences,
12570| [],
12571| $gestoresForEventModal
12572| );
12573| }
12574|
12575| $allMembers = $this->sortSsmaMemberRowsByName($allMembers);
12576| $allMembersForEventPeople = $this->sortSsmaMemberRowsByName($allMembersForEventPeople);
12577| $gestores = $this->sortSsmaMemberRowsByName($gestores);
12578| $gestoresForEventModal = $this->sortSsmaMemberRowsByName($gestoresForEventModal);
12579|
12580| $this->ssmaViewDataBuildTelemetry->logBuild(
12581| $buildStartedAt,
12582| $scope,
12583| $company instanceof Company ? (int) $company->getId() : null
12584| );
12585|
12586| return array_merge(
12587| [
12588| 'user' => $user,
12589| 'role' => $role,
12590| 'ssmaIsTenant' => in_array('ROLE_SUPER_ADMIN', $roles, true) || in_array('ROLE_MANAGER', $roles, true),
12591| 'ssmaIsViewer' => $this->isSsmaViewer(),
12592| 'ssmaIsTeamViewer' => $ssmaIsTeamViewerFlag,
12593| 'ssmaCanManageOccurrences' => $ssmaCanManageOccurrences,
12594| 'ssma_hide_event_title_status_on_create' => $ssmaHideEventTitleStatusOnCreate,
12595| 'ssmaCanRegisterNewOccurrence' => $ssmaCanRegisterNewOccurrence,
12596| 'ssmaAllowedCreateTypes' => $ssmaAllowedCreateTypes,
12597| 'ssmaOccurrenceTypeColumns' => SsmaOccurrenceCreatePermissionService::TYPE_COLUMNS,
12598| 'ssmaPreventionInspectionEnabled' => $ssmaPreventionInspectionEnabled,
12599| 'ssmaPreventionAbordagemEnabled' => $ssmaPreventionAbordagemEnabled,
12600| 'ssmaCanCreatePreventionItems' => $ssmaCanCreatePreventionItems,
12601| 'ssmaCanAccessSupervisorSurface' => $ssmaCanAccessSupervisorSurface,
12602| 'ssmaCanAccessPreventionPanelAndMetas' => $ssmaCanAccessPreventionPanelAndMetas,
12603| 'ssmaCanAccessOccurrencePanel' => $ssmaCanAccessOccurrencePanel,
12604| 'ssmaCanPublishCulturalFeed' => $company instanceof Company
12605| && $user instanceof User
12606| && $this->ssmaFeedImprovementBridge->canManageFeedImprovements($user, $company),
12607| 'ssmaCanAccessOccurrenceAutomations' => $ssmaCanAccessOccurrenceAutomations,
12608| 'ssmaCanManageConfig' => $ssmaCanManageConfig,
12609| 'ssmaCanManagePermissions' => $ssmaCanManagePermissions,
12610| 'ssmaCanCreateLinkedActions' => $ssmaCanCreateLinkedActions,
12611| 'ssmaPreventionCanCreateLinkedActions' => $ssmaPreventionCanCreateLinkedActions,
12612| 'ssmaCanEditPreventionContent' => $ssmaCanEditPreventionContent,
12613| 'ssmaCanEditPreventionMetasTable' => $ssmaCanEditPreventionMetasTable,
12614| 'ssmaCanCreateCauseTree' => $ssmaCanCreateCauseTree,
12615| 'ssmaCanViewCauseTree' => $ssmaCanViewCauseTree,
12616| 'ssmaCanCreateAuthorization' => $ssmaCanCreateAuthorization,
12617| 'ssmaCanEditHorasTrabalhadas' => $ssmaCanEditHorasTrabalhadas,
12618| 'ssmaCanViewAccidentVictimName' => $this->isGranted('ROLE_SUPER_ADMIN')
12619| || $this->isGranted('ROLE_MANAGER')
12620| || $this->isGranted('ROLE_MANAGER_GESTOR')
12621| || $ssmaProductTagName === 'Gestor Administrador'
12622| || $ssmaIsTagTeamSupervisor
12623| || $ssmaIsTagTeamGestor
12624| || $this->isSsmaViewer(),
12625| 'gestores' => $gestores,
12626| 'teams' => $teams,
12627| 'gestores_for_event_modal' => $gestoresForEventModal,
12628| 'teams_for_event_modal' => $teamsForEventModal,
12629| 'teams_for_inspection_modal' => $teamsForInspectionModal,
12630| 'default_inspection_team_id' => $defaultInspectionTeamId,
12631| 'all_members_for_event_people' => $allMembersForEventPeople,
12632| /** true = usar listas filtradas nos modais; false = admin/tenant vê lista completa */
12633| 'ssma_apply_team_event_scope' => $applyTeamEventScope,
12634| 'ssma_event_form_defaults' => $ssmaEventFormDefaults,
12635| 'ssma_logged_member_id' => (int) ($loggedMemberForOccurrence?->getId() ?? 0),
12636| 'ssma_is_admin_aprofundamento' => $this->isSsmaAprofundamentoAdmin($company, $user instanceof User ? $user : null),
12637| // Resolve pela tag SSMA real (mesmo com ROLE_MANAGER de plataforma).
12638| 'ssma_is_pessoa_fisica_comum' => $this->isSsmaPlainProductMember($company, $user instanceof User ? $user : null),
12639| 'ssma_is_gestor_user' => $ssmaIsTagTeamGestor
12640| || $ssmaProductTagName === 'Gestor Administrador'
12641| || $this->isSsmaAprofundamentoAdmin($company, $user instanceof User ? $user : null)
12642| || $this->isGranted('ROLE_MANAGER_GESTOR'),
12643| 'ssma_perm_tags' => $ssmaPermTags,
12644| 'ros_call_priority' => $rosCallPriority,
12645| 'allMembers' => $allMembers,
12646| 'abordagem_turno_options' => ($isOccurrenceDetailView || $module === 'occurrence')
12647| ? []
12648| : $this->buildSsmaAbordagemTurnoOptions($company),
12649| 'default_abordagem_observador_id' => $defaultAbordagemObservadorId,
12650| 'default_insp_responsible_id' => $defaultAbordagemObservadorId,
12651| 'inspection_types' => $company instanceof Company
12652| ? $this->ssmaInspectionTypeConfig->getTypesForFrontend($company)
12653| : [],
12654| /** Contexto de tenant para cache de listas no front (ex.: questionários PE) */
12655| 'ssma_company_id' => $company?->getId(),
12656| 'ssma_export_matricula' => $ssmaExportMatricula,
12657| 'ssmaCanDescharacterizeAccident' => $ssmaCanDescharacterizeAccident,
12658| 'ssmaCanDescharacterizeByType' => $ssmaCanDescharacterizeByType,
12659| 'ssma_esocial_cat_integration' => false,
12660| 'occurrences' => $occurrences,
12661| 'inspections' => $inspections,
12662| 'prevencao_panel_charts' => [],
12663| 'prevencao_overview_kpi_cards' => [],
12664| 'actions_taken' => $actionsTaken,
12665| 'action_type_metadata' => $actionTypeMetadata,
12666| 'action_type_labels' => array_column($actionTypeMetadata, 'label', 'value'),
12667| 'action_plan_data' => $deferOccurrenceHubHeavyData
12668| ? $this->buildActionPlanData([], [], $actionTypeMetadata)
12669| : $this->buildActionPlanData($actionsTaken, $occurrences, $actionTypeMetadata),
12670| 'dashboard_data' => $scope->shouldSkipHeavyDashboard()
12671| ? $this->buildDashboardDataForPeriod([], [], [], 'last_6_months', [])
12672| : ($company instanceof Company
12673| ? (($subsidiaryViewEarly['ssma_has_network_units'] ?? false)
12674| ? $this->attachComparativoFiliaisToDashboardData(
12675| $this->buildDashboardDataForPeriod($occurrences, $actionsTaken, $inspections, 'last_6_months', $horasData),
12676| $company,
12677| 'last_6_months',
12678| [],
12679| [],
12680| 0
Request #48
deepseek-v4-flash
P:57.46K C:398 CR:53.76K CW:0
4044ms
Reasoning
This code block is within the "view data" builder that merges into a response used both for index SSR and occurrence view render. So `ssmaCanDescharacterizeByType` passed to both templates.
Now let me check where the templates `index.html.twig` and `occurrence_view.html.twig` actually include `_modal_event.html.twig` and whether there is any other context from AJAX. That's handled.
Let me also verify `getCurrentCompanyMember($company, $user)` returns a SsmaMember or CompanyMember. If `$company` is null but user has... not relevant since no permission flags then.
Now cross-cutting issue candidates that might remain:
- The controller's use of `(int) $currentMemberForExport->getId()` while old path passed the entity to `ssmaMemberCanDescharacterizeAccident`; we should check what `ssmaMemberCanDescharacterizeAccident` did (maybe entity id differs from export id?). Let me look at the old method signature. But confirmed #1 covered semantic change. Let me check for differences to see if there's an additional bug — e.g. maybe `getCurrentCompanyMember` returns a `CompanyMember`; the old helper may have used member id as well. Let's look for the controller private method `ssmaMemberCanDescharacterizeAccident`.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "function ssmaMemberCanDescharacterizeAccident"}
Result
File: src/Controller/SsmaController.php Match lines: 1 10198| private function ssmaMemberCanDescharacterizeAccident(Company $company, ?CompanyMembers $member): bool File: tests/Unit/Product/Ssma/assert_branch_ui_fixes.php Match lines: 1 496| && fileContains($ssmaCtrl, 'function ssmaMemberCanDescharacterizeAccident')
code_search
Show Details
Arguments
{"search_text": "getCurrentCompanyMember", "file_patterns": ["src/Controller/SsmaController.php"]}
Result
File: src/Controller/SsmaController.php Match lines: 68 436| $member = $this->getCurrentCompanyMember($company, $user instanceof User ? $user : null); 498| $member = $this->getCurrentCompanyMember($company, $user instanceof User ? $user : null); 549| $member = $this->getCurrentCompanyMember($company, $user instanceof User ? $user : null); 986| $member = $this->getCurrentCompanyMember($company, $user); 1032| $member = $this->getCurrentCompanyMember($company, $user); 1062| $member = $this->getCurrentCompanyMember($company, $user); 1079| $member = $this->getCurrentCompanyMember($company, $user); 1168| $member = $this->getCurrentCompanyMember($company, $user); 1211| $member = $this->getCurrentCompanyMember($company, $user); 1274| $member = $this->getCurrentCompanyMember($company, $user); 1310| $member = $this->getCurrentCompanyMember($company, $user); 1336| $member = $this->getCurrentCompanyMember($company, $user); 6794| $creatorMember = $this->getCurrentCompanyMember($company, $user); 9136| $currentMember = $this->getCurrentCompanyMember($company, $user); 9545| $viewCurrentMember = $this->getCurrentCompanyMember($company, $user); 9662| $member = $company instanceof Company ? $this->getCurrentCompanyMember($company, $user) : null; 9797| $member = $this->getCurrentCompanyMember($company, $user); 9888| $member = $this->getCurrentCompanyMember($company, $user); 9992| $member = $this->getCurrentCompanyMember($company, $user); 10634| $member = $this->getCurrentCompanyMember($company, $user); 10784| $member = $this->getCurrentCompanyMember($company, $user); 10852| return $this->getCurrentCompanyMember($company, $user) !== null; 10864| $member = $this->getCurrentCompanyMember($company, $user); 10927| $memberPm = $this->getCurrentCompanyMember($company, $user); 10945| $memberScoped = $this->getCurrentCompanyMember($company, $user); 10963| private function getCurrentCompanyMember(?Company $company, ?User $user): ?CompanyMembers 11250| $member = $company ? $this->getCurrentCompanyMember($company, $user) : null; 11301| $member = $this->getCurrentCompanyMember($company, $user); 11330| $member = $this->getCurrentCompanyMember($company, $user); 11376| $loggedMember = $this->getCurrentCompanyMember($company, $user); 11929| $selfMWin = $user instanceof User ? $this->getCurrentCompanyMember($company, $user) : null; 12026| $memberForTagCheck = $this->getCurrentCompanyMember($company, $user); 12062| ? $this->getCurrentCompanyMember($company, $user) 12084| ? $this->getCurrentCompanyMember($company, $user) 12209| $currentMemberForDefaults = $this->getCurrentCompanyMember($company, $user); 12247| $plainMemberRow = $this->getCurrentCompanyMember($company, $user); 12298| $selfMember = $this->getCurrentCompanyMember($company, $user); 12370| $memberForPreventionTabs = $this->getCurrentCompanyMember($company, $user); 12439| ? (int) ($this->getCurrentCompanyMember($company, $user)?->getId() ?? 0) 12461| && !$this->memberIsSsmaGestorAdministrador($company && $user instanceof User ? $this->getCurrentCompanyMember($company, $user) : null) 12464| $currentMember = $this->getCurrentCompanyMember($company, $user); 12483| $plainMemberId = (int) ($this->getCurrentCompanyMember($company, $user)?->getId() ?? 0); 12532| $currentMemberForExport = $this->getCurrentCompanyMember($company, $user); 15488| $member = $user ? $this->getCurrentCompanyMember($company, $user) : null; 15495| $member = $user ? $this->getCurrentCompanyMember($company, $user) : null; 15539| $member = $this->getCurrentCompanyMember($company, $user); 15628| $member = $user ? $this->getCurrentCompanyMember($company, $user) : null; 18120| $memberTagCheck = $this->getCurrentCompanyMember($company, $user); 18174| $this->getCurrentCompanyMember($company, $user) 18180| $this->getCurrentCompanyMember($company, $user) 18206| $currentMember = $this->getCurrentCompanyMember($company, $user); 18263| $member = $this->getCurrentCompanyMember($company, $user); 18345| $member = $this->getCurrentCompanyMember($company, $user); 18382| $member = $this->getCurrentCompanyMember($company, $user); 18425| $member = $this->getCurrentCompanyMember($company, $user); 18458| $member = $this->getCurrentCompanyMember($company, $user); 18494| $reviewer = $this->getCurrentCompanyMember($company, $user); 19010| $currentMember = $this->getCurrentCompanyMember($company, $this->getUser()); 19390| $member = $this->getCurrentCompanyMember($company, $user); 19423| $member = $this->getCurrentCompanyMember($company, $user); 19449| $member = $this->getCurrentCompanyMember($company, $user); 19475| $member = $this->getCurrentCompanyMember($company, $user); 19508| $member = $this->getCurrentCompanyMember($company, $user); 22285| $member = $this->getCurrentCompanyMember($currentCompany, $user); 23834| $currentMember = $this->getCurrentCompanyMember($company, $user); 24082| $currentMember = $this->getCurrentCompanyMember($company, $user); 27266| $member = $this->getCurrentCompanyMember($company, $user); 27414| $member = $this->getCurrentCompanyMember($company, $user);
Request #49
deepseek-v4-flash
P:59.48K C:151 CR:57.86K CW:0
2473ms
Reasoning
Let me read the old private method `ssmaMemberCanDescharacterizeAccident` at line 10198 to fully understand its behavior, which is already partly reported in #1. But maybe there's a separate nuance not covered, e.g. the new map path differs in which member entity is passed.
Tool Calls (1)
file_read
Show Details
Arguments
{"file_path": "src/Controller/SsmaController.php", "start_line": 10180, "end_line": 10240}
Result
File: src/Controller/SsmaController.php (Total lines: 27765)
IS_TRUNCATED: false
LINE_RANGE: 10180-10240
10180| return $member->getGlobalPermissionTag();
10181| }
10182|
10183| // Delega ao serviço centralizado que resolve herança, tags obsoletas e tag global actual
10184| $resolved = $this->permissionTagByMemberService->getPermissionTag($member, $product);
10185|
10186| return $resolved;
10187| } catch (\Throwable $e) {
10188| }
10189|
10190| return $member->getGlobalPermissionTag();
10191| }
10192|
10193| /**
10194| * S/N de descaracterização: liberado automaticamente para Gestor Administrador/Tenant
10195| * (ROLE_SUPER_ADMIN, ROLE_MANAGER ou tag "Gestor Administrador"), sem precisar de
10196| * configuração explícita em "Profissionais de Saúde". Demais perfis seguem a config.
10197| */
10198| private function ssmaMemberCanDescharacterizeAccident(Company $company, ?CompanyMembers $member): bool
10199| {
10200| if ($this->isGranted('ROLE_SUPER_ADMIN') || $this->isGranted('ROLE_MANAGER')) {
10201| return true;
10202| }
10203|
10204| if (!$member instanceof CompanyMembers) {
10205| return false;
10206| }
10207|
10208| if ($this->memberIsSsmaGestorAdministrador($member)) {
10209| return true;
10210| }
10211|
10212| return $this->ssmaOccurrenceTypeConfig->memberCanDescharacterizeAccident(
10213| $company,
10214| (int) $member->getId()
10215| );
10216| }
10217|
10218| private function getCurrentSsmaPermissionProductSlug(): string
10219| {
10220| $request = $this->requestStack->getCurrentRequest();
10221| $product = $request ? $request->attributes->get('current_product') : null;
10222|
10223| if ($product instanceof \App\Entity\Product) {
10224| $slug = (string) $product->getSlug();
10225| if ($slug !== '') {
10226| return $slug;
10227| }
10228| }
10229|
10230| return $this->ssmaParentProductSlug;
10231| }
10232|
10233| /**
10234| * Admin da tenant/plataforma — não entra em NENHUM select/lista de membros SSMA.
10235| * ROLE_MANAGER_GESTOR (colaborador gestor de equipe) NÃO é excluído aqui.
10236| * Alinhado a SsmaOccurrenceCreatePermissionService::isAdminRoleExcludedFromMatrix.
10237| */
10238| private function isSsmaExcludedTenantAdminUser(?User $user): bool
10239| {
10240| if (!$user instanceof User) {
Request #50
deepseek-v4-flash
P:60.4K C:590 CR:59.52K CW:0
6211ms
Reasoning
Confirmed #1 covers this regression.
Now let me think of genuinely NEW issues not yet reported:
Potential issue: In the controller there might be a company-mismatch concern: The map is computed per current member and company. That's fine, isolated by company.
Potential issue in `SsmaOccurrenceTypeConfigService::memberCanDescharacterizeForType` - Tags found via `findBy(['company' => $company, 'occurrenceTypeKey' => $typeKey])`. Because tags are now ensured fixed per company. But the memberIds stored in `aprofundamento_descaracter['tag:{id}']` use tag ID per company. If there are multiple tags with same occurrenceTypeKey in the same company (should be unique per type), fine. If multiple companies — isolated by company. OK.
Also, `getDescharacterizeFlagsByType` output includes keys `ROS`, etc. The map array is passed to Twig. Since Twig renders key accesses with brackets like `ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']|default(false)` — is `|default` applied AFTER the array access? If key missing, the access returns null/undefined and default false applies. Actually Twig: `ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']` on empty array returns null? In Twig 3, accessing undefined attribute on array yields null (with strict_variables disabled) and the default filter returns false. OK.
Now, what about the new partial uses `_type_key`; index not an issue.
Let's now read the `_ev_injured_person_box.html.twig` file in full relevant section to check the AP block and to see if per-card Suspect checkbox is used by any JS for per-card serialization (`evReadCardInjuryData` reads `.ev-inj-descaracter-comment` textarea and `evIsDescaracterSuspectChecked` global). After this change, if the AP tag flag missing, the whole `.ev-inj-descaracter` block hidden — meaning cards won't have `.ev-inj-suspect-chk` and `.ev-inj-descaracter-comment`. Then `evReadCardInjuryData` at 2216 sets `descaracter_suspect: evIsDescaracterSuspectChecked() ? 1 : 0` (from global). If global unchecked then 0. OK.
Let me read the file around the AP block.
Tool Calls (1)
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig"}
Result
File: templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig (Total lines: 227)
IS_TRUNCATED: false
LINE_RANGE: 1-227
1|{#
2| Caixinha completa por colaborador acidentado (Figma / padrão Desvios em Inspeções).
3| Campos usam classes; IDs canônicos (ev_had_injury, etc.) são atribuídos via JS
4| só no card expandido ativo, para reaproveitar mapa corporal e validadores.
5|#}
6|<div class="ev-inj-card ev-injured-person-box" data-person-id="{{ person_id|default('') }}">
7| {# Resumo (colapsado) #}
8| <div class="ev-inj-card-summary d-none js-ev-inj-summary">
9| <button type="button"
10| class="ev-inj-pick-circle js-ev-inj-pick"
11| title="Marcar como colaborador acidentado principal"
12| aria-label="Marcar como colaborador acidentado principal"
13| aria-pressed="false"></button>
14| <div class="ev-inj-card-summary-main">
15| <span class="ev-inj-card-summary-name js-ev-inj-summary-name">{{ person_name|default('Nome do Colaborador') }}</span>
16| <div class="ev-inj-card-summary-person small text-muted js-ev-inj-summary-person">
17| <span><span class="text-muted">Matrícula:</span> <span class="js-ev-inj-sum-collapsed-registration">—</span></span>
18| <span class="mx-1">·</span>
19| <span><span class="text-muted">Cargo:</span> <span class="js-ev-inj-sum-collapsed-position">—</span></span>
20| <span class="mx-1">·</span>
21| <span><span class="text-muted">Turno:</span> <span class="js-ev-inj-sum-collapsed-shift">—</span></span>
22| </div>
23| <span class="ev-inj-card-summary-meta js-ev-inj-summary-meta text-muted small d-block">—</span>
24| </div>
25| <div class="ev-inj-card-summary-actions">
26| <button type="button" class="js-ev-inj-toggle" title="Editar">
27| <i class="fas fa-pencil-alt"></i>
28| </button>
29| </div>
30| </div>
31|
32| {# Formulário expandido #}
33| <div class="ev-inj-card-form js-ev-inj-form">
34| <div class="d-flex align-items-center justify-content-between mb-2">
35| <h6 class="mb-0 font-weight-bold ev-inj-person-name">{{ person_name|default('') }}</h6>
36| <button type="button"
37| class="js-ev-inj-toggle ssma-config-tipo-action-btn"
38| aria-expanded="true"
39| title="Recolher"
40| aria-label="Recolher">
41| <i class="fas fa-chevron-up text-muted ssma-section-chevron" style="font-size:12px;"></i>
42| </button>
43| </div>
44|
45| {# Resumo cadastral do acidentado #}
46| <div class="ev-inj-person-summary js-ev-inj-person-summary">
47| <div class="ev-inj-sum-title">Resumo do acidentado</div>
48| <dl class="ev-inj-sum-grid mb-0">
49| <div class="ev-inj-sum-item">
50| <dt>Matrícula</dt>
51| <dd class="js-ev-inj-sum-registration">—</dd>
52| </div>
53| <div class="ev-inj-sum-item ev-inj-sum-item--wide">
54| <dt>Cargo</dt>
55| <dd class="js-ev-inj-sum-position">—</dd>
56| </div>
57| <div class="ev-inj-sum-item ev-inj-sum-item--wide">
58| <dt>Turno</dt>
59| <dd class="js-ev-inj-sum-shift">—</dd>
60| </div>
61| <div class="ev-inj-sum-item">
62| <dt>Superior</dt>
63| <dd class="js-ev-inj-sum-supervisor">—</dd>
64| </div>
65| <div class="ev-inj-sum-item ev-inj-sum-item--wide">
66| <dt>Gerência</dt>
67| <dd class="js-ev-inj-sum-gerencia">—</dd>
68| </div>
69| </dl>
70| </div>
71|
72| <div class="form-group mb-2">
73| <label class="small mb-0">Data de atendimento</label>
74| <input type="date"
75| class="form-control form-control-sm ev-inj-attendance"
76| value="{{ attendance_date|default('') }}">
77| </div>
78|
79| <div class="form-group mb-2">
80| <label class="small mb-0">Breve relato <span class="text-muted">(opcional)</span></label>
81| <textarea class="form-control form-control-sm ev-inj-relato"
82| rows="2"
83| placeholder="Breve relato">{{ breve_relato|default('') }}</textarea>
84| </div>
85|
86| <div class="form-group mb-2">
87| <div class="form-check">
88| <input class="form-check-input ev-inj-had-injury" type="checkbox" value="1" checked>
89| <label class="form-check-label">Houve lesão</label>
90| </div>
91| </div>
92|
93| <div class="ev-inj-injury-fields">
94| <div class="form-row ev-inj-type-severity-row ev-inj-type-row">
95| <div class="col-6">
96| <div class="form-group">
97| <label>Tipo da Lesão <span class="text-danger ev-inj-injury-required-mark">*</span></label>
98| <select class="form-control ev-inj-injury-type">
99| <option value="" disabled selected>Selecione o tipo de lesão</option>
100| <option value="CORTE">Corte</option>
101| <option value="ESMAGAMENTO">Esmagamento</option>
102| <option value="FRATURA">Fratura</option>
103| <option value="LUXACAO">Luxação</option>
104| <option value="QUEIMADURA">Queimadura</option>
105| <option value="INTOXICACAO">Intoxicação</option>
106| <option value="AMPUTACAO">Amputação</option>
107| <option value="CONTUSAO">Contusão</option>
108| <option value="OUTRO">Outro</option>
109| </select>
110| </div>
111| </div>
112| <div class="col-6">
113| <div class="form-group">
114| <label>Severidade da Lesão <span class="text-danger ev-inj-injury-required-mark">*</span></label>
115| <select class="form-control ev-inj-injury-severity">
116| <option value="" disabled selected>Selecione a severidade</option>
117| <option value="LEVE">Leve</option>
118| <option value="MODERADA">Moderada</option>
119| <option value="GRAVE">Grave</option>
120| <option value="CRITICA">Crítica</option>
121| </select>
122| </div>
123| </div>
124| </div>
125|
126| <div class="ev-inj-body-map-slot"></div>
127|
128| <div class="form-row mt-2 ev-inj-cat-row">
129| <div class="col-6">
130| <div class="form-group ev-inj-classification-row">
131| <label>Classificação de Ocorrência <span class="text-danger">*</span></label>
132| <select class="form-control ev-inj-injury-classification">
133| <option value="" disabled selected>Selecione</option>
134| <option value="FAC" data-leave="NAO">FAC — Primeiros socorros</option>
135| <option value="MTC" data-leave="NAO">MTC — Tratamento médico</option>
136| <option value="RWC" data-leave="NAO">RWC — Trabalho restrito</option>
137| <option value="FAT" data-leave="TOTAL">FAT — Fatalidade</option>
138| <option value="LTI_INCAPACITANTE" data-leave="TOTAL">LTI — Afastamento</option>
139| <option value="LTI_FATALIDADE" data-leave="TOTAL" class="d-none">LTI — Fatalidade (legado)</option>
140| <option value="LTI" data-leave="TOTAL" class="d-none">LTI — Afastamento (legado)</option>
141| </select>
142| </div>
143| </div>
144| <div class="col-6">
145| <div class="form-group">
146| <label>Tipo de CAT</label>
147| <select class="form-control ev-inj-work-leave" disabled aria-readonly="true" tabindex="-1">
148| <option value="">Selecione a classificação</option>
149| <option value="NAO">Sem afastamento</option>
150| <option value="TOTAL">Com afastamento</option>
151| </select>
152| </div>
153| </div>
154| </div>
155|
156| <div class="form-row ev-inj-consequence-row d-none" aria-hidden="true">
157| <div class="col-6">
158| <div class="form-group mb-2">
159| <label>Consequência real <span class="text-danger">*</span></label>
160| <select class="form-control ev-inj-consequence">
161| <option value="" disabled selected>Selecione a consequência</option>
162| {% include 'ssma/occurrence/partials/_ev_consequence_options.html.twig' %}
163| </select>
164| <div class="ev-inj-derived-severity-wrap mt-2">
165| <label class="text-muted small d-block mb-1">Gravidade da ocorrência (automática)</label>
166| <span class="ev-inj-derived-severity-badge ssma-shared-tag"
167| style="background:rgba(108,117,125,0.10);color:#6c757d;border-color:#adb5bd;">—</span>
168| </div>
169| </div>
170| </div>
171| <div class="col-6">
172| <div class="form-group mb-2">
173| <label>Consequência potencial <span class="text-danger">*</span></label>
174| <select class="form-control ev-inj-potential-consequence">
175| <option value="" disabled selected>Selecione a consequência</option>
176| {% include 'ssma/occurrence/partials/_ev_consequence_options.html.twig' %}
177| </select>
178| </div>
179| </div>
180| </div>
181|
182| {# CAT eSocial — exibido quando integração estiver ativa #}
183| <div class="ev-inj-esocial-cat-wrap d-none mt-2 p-2 rounded border">
184| <div class="small font-weight-bold mb-1">Registro da CAT no eSocial (automático)</div>
185| <div class="ev-inj-esocial-cat-body small text-muted">—</div>
186| </div>
187| </div>
188|
189| <p class="small text-muted font-italic mb-0 mt-2">Oriente o profissional a anexar evidências (fotos, laudos) na etapa de registro, se aplicável.</p>
190|
191| {# Só renderiza se a coluna Descaracterizar estiver marcada na tag de Acidente Pessoal. #}
192| {% if ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']|default(false) %}
193| <div class="ev-inj-descaracter mt-3 pt-3 border-top d-none">
194| <div class="form-check mb-2">
195| <input class="form-check-input ev-inj-suspect-chk" type="checkbox">
196| <label class="form-check-label font-weight-bold">Há suspeita de descaracterização do acidente?</label>
197| </div>
198| <div class="ev-inj-descaracter-yesno-wrap d-none">
199| <label class="d-block small mb-2 font-weight-bold">
200| Caracterizado como acidente?
201| <i class="fas fa-info-circle text-muted ml-1 ev-inj-descaracter-tip"
202| style="cursor:help;font-size:12px;"
203| data-toggle="tooltip"
204| data-placement="top"
205| title="Sim = é acidente. Não (descaracterizar) só quem tem permissão na coluna Descaracterizar em Profissionais de Saúde."></i>
206| </label>
207| <div class="ev-inj-descaracter-toggle d-flex align-items-center mb-3" role="group" aria-label="Caracterizado como acidente">
208| <button type="button" class="mhs-btn-cancel ev-inj-descaracter-btn" data-descaracter-val="0" style="min-width:84px;">Sim</button>
209| <button type="button" class="mhs-btn-cancel ev-inj-descaracter-btn" data-descaracter-val="1" style="min-width:84px;">Não</button>
210| </div>
211| <div class="form-group mb-0 ev-inj-descaracter-comment-wrap">
212| <label class="small mb-1">Comentário <span class="text-danger">*</span></label>
213| <textarea class="form-control form-control-sm ev-inj-descaracter-comment"
214| rows="2"
215| maxlength="2000"></textarea>
216| </div>
217| <p class="ev-inj-descaracter-no-perm small text-muted mb-0 mt-2 d-none">
218| Sem permissão para descaracterizar o acidente.
219| Peça ao gestor que marque a coluna <strong>Descaracterizar</strong> em
220| Profissionais de Saúde (configuração de aprofundamento).
221| </p>
222| </div>
223| </div>
224| {% endif %}
225| </div>
226|</div>
227|
Request #51
deepseek-v4-flash
P:64.59K C:363 CR:60.93K CW:0
3781ms
Reasoning
Now confirm finding #3 already covered. Let's look at `evSyncDescaracterStageUi` and `evCanDescharacterizeAccident` (JS) used in payload at line 7196: `if (!descFromCard && evAprofundamentoOnlyMode && !evCanDescharacterizeAccident()) { descFromCard = '0'; }` This is a fallback: "médico sem permissão de descaracterizar nunca pode marcar 'Não'". evCanDescharacterizeAccident presumably consults `ssmaCanDescharacterizeAccident` (the boolean) or tag. But note: the boolean `ssmaCanDescharacterizeAccident` is no longer passed to `_modal_event.html.twig` from either index.html.twig or occurrence_view.html.twig? Let's check: index includes _modal_event with ssmaAllowedCreateTypes and now ssmaCanDescharacterizeByType. But ssmaCanDescharacterizeAccident was not previously passed either? Let me verify the JS global variable for descaracterization. The modal reads `ssmaCanDescharacterizeAccident` from somewhere in JS (window/global or a var passed?). Let's search within `_modal_event.html.twig` for `ssmaCanDescharacterizeAccident`.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "ssmaCanDescharacterizeAccident"}
Result
File: docs/ssma/CORRECOES-OCORRENCIA-FIGMA-PARTE-2.md
Match lines: 1
164|**Status:** **Feito** (flag `ssmaCanDescharacterizeAccident` ↔ coluna Descaracterizar)
File: docs/ssma/ocorrencia-07-suspeita-descaracterizacao-ui.md
Match lines: 1
25|Permissão: flag `ssmaCanDescharacterizeAccident` / `SSMA_CAN_DESCARACTERIZE` (coluna Descaracterizar em Profissionais de Saúde).
File: src/Controller/SsmaController.php
Match lines: 2
12540| $ssmaCanDescharacterizeAccident = (bool) ($ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false);
12657| 'ssmaCanDescharacterizeAccident' => $ssmaCanDescharacterizeAccident,
File: src/Service/Ssma/ViewData/SsmaPermissionContextResolver.php
Match lines: 1
27| 'ssmaCanDescharacterizeAccident',
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 1
57| window.SSMA_CAN_DESCARACTERIZE = {{ ssmaCanDescharacterizeAccident|default(false) ? 'true' : 'false' }};
code_search
Show Details
Arguments
{"search_text": "evCanDescharacterizeAccident"}
Result
File: docs/ssma/ocorrencia-07-suspeita-descaracterizacao-ui.md
Match lines: 1
33|| Gate permissão | `evCanDescharacterizeAccident()` |
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 4
2644| if (val === '1' && !evCanDescharacterizeAccident()) {
2921| function evCanDescharacterizeAccident() {
2978| var canSn = evCanDescharacterizeAccident();
7196| if (!descFromCard && evAprofundamentoOnlyMode && !evCanDescharacterizeAccident()) {
Request #52
deepseek-v4-flash
P:65.44K C:473 CR:64.9K CW:0
3863ms
Reasoning
At line 57 of `_modal_event.html.twig`, `window.SSMA_CAN_DESCARACTERIZE` set from `ssmaCanDescharacterizeAccident` variable passed into template context. Wait, `_modal_event.html.twig` uses `ssmaCanDescharacterizeAccident|default(false)`. But the include call from index.html.twig only passes `ssmaCanDescharacterizeByType`, not `ssmaCanDescharacterizeAccident`. Let's check the includes again: index.html.twig include at line 114-127; occurrence_view at 1308-1320. Neither passes `ssmaCanDescharacterizeAccident` but Twig include inherits the top-level context (from controller view vars) because these are renders of the full page; `_modal_event.html.twig` is included within the full page render whose root context includes `ssmaCanDescharacterizeAccident` (passed to template from controller). Unless the include is scoped by `only` keyword... Let me check index include.
Tool Calls (3)
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/index.html.twig", "start_line": 100, "end_line": 135}
Result
File: templates/ssma/occurrence/index.html.twig (Total lines: 135)
IS_TRUNCATED: false
LINE_RANGE: 100-135
100| {% endif %}
101|
102| {% include 'ssma/partials/_modal_action.html.twig' with {
103| occurrences: occurrences|default([]),
104| allMembers: allMembers|default([]),
105| action_type_config: action_type_config|default({ types: [] })
106| } %}
107| {% include 'ssma/partials/_modal_delete_confirm.html.twig' %}
108|
109| {# Modais no fim do section — evita espaço fantasma acima do .modern-header sticky #}
110| {% set _membersForModal = ssma_apply_team_event_scope|default(false) ? all_members_for_event_people|default([]) : allMembers|default([]) %}
111| {% set _gestoresForModal = gestores_for_event_modal|default(gestores|default([])) %}
112| {% set _teamsForModal = teams_for_event_modal|default(teams|default([])) %}
113| {% include 'ssma/occurrence/partials/_modal_classify.html.twig' %}
114| {% include 'ssma/occurrence/partials/_modal_event.html.twig' with {
115| allMembers: _membersForModal,
116| allMembersForMeta: allMembers|default([]),
117| gestores: _gestoresForModal,
118| teams: _teamsForModal,
119| occurrence_type_config: occurrence_type_config|default({ types: [] }),
120| ssma_event_form_defaults: ssma_event_form_defaults|default({}),
121| user_technical_types: user_technical_types|default([]),
122| ssmaCanManageOccurrences: ssmaCanManageOccurrences|default(false),
123| ssma_hide_event_title_status_on_create: ssma_hide_event_title_status_on_create|default(false),
124| ssmaCanRegisterNewOccurrence: ssmaCanRegisterNewOccurrence|default(false),
125| ssmaAllowedCreateTypes: ssmaAllowedCreateTypes|default([]),
126| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
127| } %}
128|</section>
129|{% endblock %}
130|
131|{% block javascripts %}
132|{{ parent() }}
133|{# Botões "+ Evento" / "+ ROS": handler em _tab_occurrences e _modal_event — abre offcanvas tipado #}
134|{% endblock %}
135|
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/occurrence_view.html.twig", "start_line": 1295, "end_line": 1330}
Result
File: templates/ssma/occurrence/occurrence_view.html.twig (Total lines: 3226)
IS_TRUNCATED: false
LINE_RANGE: 1295-1330
1295|</template>
1296|{% include 'ssma/partials/_modal_action.html.twig' with {
1297| occurrences: occurrences,
1298| allMembers: allMembers
1299|} %}
1300|{% include 'ssma/partials/_modal_action_resolution.html.twig' %}
1301|{% include 'ssma/partials/_modal_delete_confirm.html.twig' %}
1302|
1303|{# Offcanvas de edição / aprofundamento — disponível também para especialistas técnicos. #}
1304|{% if can_edit_occurrence|default(false) or show_aprofundamento_btn|default(false) %}
1305| {% set _membersForModal = ssma_apply_team_event_scope|default(false) ? all_members_for_event_people|default([]) : allMembers|default([]) %}
1306| {% set _gestoresForModal = gestores_for_event_modal|default(gestores|default([])) %}
1307| {% set _teamsForModal = teams_for_event_modal|default(teams|default([])) %}
1308| {% include 'ssma/occurrence/partials/_modal_event.html.twig' with {
1309| allMembers: _membersForModal,
1310| allMembersForMeta: allMembers|default([]),
1311| gestores: _gestoresForModal,
1312| teams: _teamsForModal,
1313| occurrence_type_config: occurrence_type_config|default({ types: [] }),
1314| ssma_event_form_defaults: ssma_event_form_defaults|default({}),
1315| user_technical_types: user_technical_types|default([]),
1316| ssmaCanManageOccurrences: ssmaCanManageOccurrences|default(false),
1317| ssma_hide_event_title_status_on_create: ssma_hide_event_title_status_on_create|default(false),
1318| ssmaCanRegisterNewOccurrence: ssmaCanRegisterNewOccurrence|default(false),
1319| ssmaAllowedCreateTypes: ssmaAllowedCreateTypes|default([]),
1320| ssmaCanDescharacterizeByType: ssmaCanDescharacterizeByType|default({})
1321| } %}
1322| {% if can_edit_occurrence|default(false) %}
1323| {% include 'ssma/occurrence/partials/_modal_occurrence.html.twig' %}
1324| {% endif %}
1325|{% endif %}
1326|
1327|{# Modal: vincular ação a um plano de ação (detalhe da ocorrência). IDs com prefixo ssmaOccView* para não colidir com #ssmaLinkProjectModal da aba Plano de Ação. #}
1328|<div class="modal fade" id="ssmaOccViewLinkProjectModal" tabindex="-1" role="dialog" aria-labelledby="ssmaOccViewLinkProjectModalLabel" aria-hidden="true">
1329| <div class="modal-dialog modal-dialog-centered" role="document">
1330| <div class="modal-content">
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 40, "end_line": 70}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 40-70
40| BLOCO 1 — Identificação do evento
41| ══════════════════════════════════════════ #}
42| <h5 class="ssma-form-section text-primary">Identificação do evento</h5>
43|
44| {# Etapa 0: ocultar Título/Status na criação para membro (sem gestão SSMA). Em edição os campos voltam. #}
45| {% set ssmaIsAuraAdmin = is_granted('ROLE_MANAGER') or is_granted('ROLE_TENANT') or is_granted('ROLE_SUPER_ADMIN') %}
46| {# ROS — "Relatado por": tenant admin escolhe livremente; gestor vem pré-selecionado (mas pode trocar); pessoa física comum não vê o campo. #}
47| {% set ssmaIsTenantAdminUser = is_granted('ROLE_TENANT') or is_granted('ROLE_SUPER_ADMIN') %}
48| {% set ssmaIsGestorUser = ssma_is_gestor_user|default(false) %}
49| {% set ssmaIsPessoaFisicaComumUser = ssma_is_pessoa_fisica_comum|default(false) %}
50| <script>
51| window.SSMA_IS_AURA_ADMIN = {{ ssmaIsAuraAdmin ? 'true' : 'false' }};
52| window.SSMA_IS_TENANT_ADMIN_USER = {{ ssmaIsTenantAdminUser ? 'true' : 'false' }};
53| window.SSMA_IS_GESTOR_USER = {{ ssmaIsGestorUser ? 'true' : 'false' }};
54| window.SSMA_IS_PESSOA_FISICA_COMUM_USER = {{ ssmaIsPessoaFisicaComumUser ? 'true' : 'false' }};
55| {% set _ssmaHideTitleStatusOnCreate = ssma_hide_event_title_status_on_create|default(not ssmaCanManageOccurrences|default(false)) or ssmaIsAuraAdmin %}
56| window.SSMA_HIDE_EVENT_TITLE_STATUS_ON_CREATE = {{ _ssmaHideTitleStatusOnCreate ? 'true' : 'false' }};
57| window.SSMA_CAN_DESCARACTERIZE = {{ ssmaCanDescharacterizeAccident|default(false) ? 'true' : 'false' }};
58| {# Só Adm / gestor admin / gestor de equipe deve cadastrar locais de referência. #}
59| window.SSMA_CAN_MANAGE_LOCATIONS = {{ (
60| ssmaCanManageConfig|default(false)
61| or ssmaIsAuraAdmin
62| or is_granted('ROLE_MANAGER_GESTOR')
63| ) ? 'true' : 'false' }};
64| </script>
65| <div class="form-row{% if _ssmaHideTitleStatusOnCreate %} d-none{% endif %}" id="ev-title-status-row">
66| <div class="col-6">
67| <div class="form-group">
68| <label for="ev_title">Título da ocorrência</label>
69| <input type="text" class="form-control" id="ev_title" name="ev_title"
70| placeholder="Ex.: Acidente com empilhadeira">
Request #53
deepseek-v4-flash
P:68.08K C:397 CR:65.79K CW:0
3709ms
Reasoning
Since the include in index.html.twig doesn't use the `only` keyword, Twig includes inherit the whole parent context (unless `only`). So the controller-level `ssmaCanDescharacterizeAccident` is still available inside `_modal_event.html.twig`. Wait, but is there a `only` on the include? No, plain `with`. So top-level context vars (from controller's array_merge render) are all available within _modal_event.html.twig, unless shadowed by the with-provided ones. So `ssmaCanDescharacterizeAccident` global from controller's data is available. But wait, is `_modal_event.html.twig` also embedded in other templates with `only` keyword anywhere? Search shows include from index and occurrence_view only; but the file itself also included from other contexts? No.
However, in `index.html.twig`, `_tab_occurrences.html.twig` also exists separately. Actually there's a tab occurrence listing, which may be an AJAX-loaded template? Not relevant.
OK, so `window.SSMA_CAN_DESCARACTERIZE` gets set from controller var. Now the JS `evCanDescharacterizeAccident()` presumably returns window.SSMA_CAN_DESCARACTERIZE.
Let me look at lines 2915-2990 to see functions including evCanDescharacterizeAccident, evIsDescaracterSuspectChecked etc.
Tool Calls (1)
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 2900, "end_line": 3000}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 2900-3000
2900| var pe = document.getElementById('ev_people_ids');
2901| if (pe) pe.value = data.__people_ids;
2902| }
2903| if (data.__witness_ids) {
2904| var we = document.getElementById('ev_witness_ids');
2905| if (we) we.value = data.__witness_ids;
2906| }
2907| if (data.__injured_details) {
2908| var ie = document.getElementById('ev_injured_person_details');
2909| if (ie) ie.value = data.__injured_details;
2910| }
2911| // Remonta caixinhas após restaurar o JSON do draft.
2912| setTimeout(function () {
2913| if (typeof evRenderInjuredPersonBoxes === 'function') evRenderInjuredPersonBoxes();
2914| }, 0);
2915| return true;
2916| } catch (e) {
2917| return false;
2918| }
2919| }
2920|
2921| function evCanDescharacterizeAccident() {
2922| return window.SSMA_CAN_DESCARACTERIZE === true || window.SSMA_CAN_DESCARACTERIZE === 'true';
2923| }
2924|
2925| function evIsDescaracterSuspectChecked() {
2926| var el = document.getElementById('ev_descaracter_suspect');
2927| if (el && el.checked) return true;
2928| return !!document.querySelector('.ev-type-descaracter-suspect:checked');
2929| }
2930|
2931| function evGetTypeDescaracterRoot(type) {
2932| return document.querySelector('[data-descaracter-root][data-descaracter-type="' + type + '"]');
2933| }
2934|
2935| function evApplyTypeDescaracterPayload(payload, type) {
2936| var root = evGetTypeDescaracterRoot(type);
2937| if (!root) return;
2938| var chk = root.querySelector('.ev-type-descaracter-suspect');
2939| payload.descaracter_suspect = chk && chk.checked ? 1 : 0;
2940| var descVal = String((document.getElementById('ev_descaracterizado') || {}).value || '');
2941| if (descVal === '0' || descVal === '1') payload.descaracterizado = descVal;
2942| var comm = root.querySelector('.ev-type-descaracter-comment');
2943| var commVal = comm ? String(comm.value || '').trim() : '';
2944| if (commVal) payload.descaracter_comment = commVal;
2945| }
2946|
2947| function evIsCreateMode() {
2948| return ((document.getElementById('ev_form_mode') || { value: 'create' }).value === 'create');
2949| }
2950|
2951| function evSyncDescaracterStageUi() {
2952| var isAp = evSelectedType() === 'ACIDENTE_PESSOAL';
2953| // Sim/Não aparece no passo aprofundamento (especialista only-mode OU admin em openEdit).
2954| var isDoctorAprof = !!evAprofundamentoOnlyMode || evCurrentStep === 'aprofundamento';
2955| var form = document.getElementById('form-event-new');
2956| if (form) form.classList.toggle('is-doctor-aprof', isDoctorAprof);
2957| // Checkbox global de suspeita (etapa 1) fica sempre oculto — suspeita agora é por card no aprofundamento.
2958| var suspectWrap = document.getElementById('ev-suspeita-wrap');
2959| if (suspectWrap) {
2960| suspectWrap.classList.add('d-none');
2961| }
2962| document.querySelectorAll('.ev-inj-descaracter').forEach(function (el) {
2963| // Seção de descaracterização só aparece no aprofundamento do especialista.
2964| el.classList.toggle('d-none', !isAp || !isDoctorAprof);
2965| });
2966| // Sincroniza Sim/Não de cada card com o estado do checkbox de suspeita do próprio card.
2967| document.querySelectorAll('.ev-injured-person-box').forEach(function (card) {
2968| var suspChk = card.querySelector('.ev-inj-suspect-chk');
2969| var yesNoWrap = card.querySelector('.ev-inj-descaracter-yesno-wrap');
2970| if (suspChk && yesNoWrap) {
2971| yesNoWrap.classList.toggle('d-none', !suspChk.checked);
2972| }
2973| });
2974| }
2975|
2976| function evSyncDescaracterUi() {
2977| var hidden = document.getElementById('ev_descaracterizado');
2978| var canSn = evCanDescharacterizeAccident();
2979| var cur = String((hidden || {}).value || '');
2980|
2981| evSyncDescaracterStageUi();
2982|
2983| // Pré-seleciona "Sim" quando o profissional não tem permissão de descaracterização
2984| // e o campo ainda está vazio. Ele só pode dizer "Sim" de qualquer forma, então
2985| // pré-preencher evita a validação falhar sem o usuário perceber o que falta.
2986| if (!canSn && cur === '' && evAprofundamentoOnlyMode && hidden) {
2987| hidden.value = '0';
2988| cur = '0';
2989| document.querySelectorAll('.ev-injured-person-box').forEach(function (c) {
2990| c.setAttribute('data-descaracterizado', '0');
2991| });
2992| }
2993|
2994| document.querySelectorAll('.ev-injured-person-box').forEach(function (card) {
2995| var noPerm = card.querySelector('.ev-inj-descaracter-no-perm');
2996| var cardDesc = card.getAttribute('data-descaracterizado') || cur;
2997| if (noPerm) noPerm.classList.toggle('d-none', canSn);
2998| card.querySelectorAll('.ev-inj-descaracter-btn').forEach(function (b) {
2999| var val = b.getAttribute('data-descaracter-val');
3000| // Sem permissão: "Não" fica visível mas desabilitado — o par Sim/Não precisa aparecer.
Request #54
deepseek-v4-flash
P:70.05K C:1.28K CR:68.48K CW:0
11099ms
Reasoning
Now let me note a very concrete new bug candidate:
`evIsDescaracterSuspectChecked()` is used at line 2216 in `evReadCardInjuryData` for EACH injured person card, i.e., suspect flag is global across cards. And payload at 7200 uses the same. The per-type roots use `.ev-type-descaracter-suspect` (suspect is global per event, not per type/card). Those all mirror global checkbox.
New type-specific descaracter UI for ROS/QA/AM/AA: Because there's only a single occurrence type at a time, no per-card issue.
Let me now consider the Suspect block's yes/no buttons for type-based descaracter: they store `ev_descaracterizado` hidden (a global, but there's only one type at a time since block is within type's own block). Actually the DOM holds all four type blocks (ROS/QA/AM/AA), each with a data-descaracter-root element (all render simultaneously, since only one is shown at a time). When user toggles Sim/Não in the block for a type (the visible one), global hidden updated. When switching types (e.g., in create mode switching from ROS to QA), roots stay in DOM. If a user answered ROS then switches to QA and saves QA without answering, `evApplyTypeDescaracterPayload(payload,'QUASE_ACIDENTE')` reads global hidden `ev_descaracterizado` and could set payload.descaracterizado to the ROS's previously chosen answer. That's the cross-type pollution already in confirmed finding #4? Let me re-read confirmed finding #4: "Os quatro blocos por tipo ... gravam o Sim/Não num único campo escondido global (`ev_descaracterizado`) e este payload lê esse campo global independentemente do tipo que está sendo salvo. Se o usuário trocar o tipo na criação ou alternar entre ocorrênci..." Yes, that covers it.
OK so what NEW issues can I add? Let me check for details that confirmed findings may not have captured:
Confirmed:
#1 controller semantic regression (super admin etc.)
#2 service memberCanDescharacterizeForType ignores team links, team config
#3 _ev_injured_person_box hiding
#4 modal event cross-type global state
#5 god template
Potential new findings:
A. **Controller still passes `ssmaCanDescharacterizeAccident` derived only from ACIDENTE_PESSOAL tag column, whereas previously it did auto-liberation... ** covered in #1.
B. There's an important potential NEW issue: The map computation calls service which creates SsmaOccurrenceTypeConfig entity via findOrCreateEntity during GET requests (read page). But this side effect happens for each of 5 tags? Actually findOrCreateEntity called once per memberCanDescharacterizeForType -> per type (5x). After first call it persists, subsequent calls find it (no side effect). Only on first GET request for that company ever. Not huge.
C. What about using only tag-by-type membership: Since 'ACIDENTE_PESSOAL' key only read from `$ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']`, but the controller also passes the whole map. However there's a mismatch between ROS & QA: The old flow of ROS/QA suspects? Not clear.
D. Templates: `ssmaCanDescharacterizeByType` in `_modal_event.html.twig` — when template is included in other pages that don't render the event modal (e.g., could be included with `only`?) No.
E. Data-type mismatch of new partial rendering when the event is of type ROS/QA and the descaracterization UI isn't a per-type thing? Wait actually consider ACIDENTE_PESSOAL: the ROS/QA/AM/AA flow now supports descaracterization within aprofundamento step. But in the ROS/QA general step there's also a "Há suspeita de descaracterização" block in step 1? For ROS there's `#ev-suspeita-wrap` used only for AP type (`.ev-inj...`)... Actually the global `#ev_descaracter_suspect` suspect checkbox was previously only shown for AP (etapa 1: suspeita). Now with the new type block added in aprofundamento for ROS/QA/AM/AA, is the requirement that suspect can be marked by specialists? Possibly.
But look at `evSyncDescaracterStageUi`: it sets all `.ev-inj-descaracter` visibility toggle based on AP, isDoctorAprof. But the new per-type roots `.ev-type-descaracter` are NOT toggled there. They're always visible whenever the corresponding type block is visible in aprofundamento. And since the blocks are placed inside each type block and the type block is visible only in aprofundamento step (they're inside `#ev-spec-type-card` which is within `#ev-step-aprofundamento`) — for ROS/QA. And for AM/AA blocks also within `ev-technical-section` which is part of aprofundamento.
OK so in the readonly mode (viewing an occurrence), the aprofundamento offcanvas could be readonly; is the descaracter root disabled? Let's check how readonly is implemented. Search `evSetAprofundamentoReadonly` and `.ev-type-descaracter`.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "evSetAprofundamentoReadonly"}
Result
File: .opencodereview/rules/ssma/occurrence-ros-aprofundamento-readonly.md
Match lines: 1
7|- `templates/ssma/occurrence/partials/_modal_event.html.twig` — `EvModal.openAprofundamento`, `evAprofundamentoCanEditFromServer`, `evCanEditAprofundamento`, `evSetAprofundamentoReadonly`
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 4
3337| function evSetAprofundamentoReadonly(readonly) {
3436| evSetAprofundamentoReadonly(!evCanEditAprofundamento(evSelectedType()));
5185| evSetAprofundamentoReadonly(!evRequiresAprofundamento(type) || !evCanEditAprofundamento(type));
5932| evSetAprofundamentoReadonly(!evRequiresAprofundamento(evSelectedType()) || !evCanEditAprofundamento(evSelectedType()));
code_search
Show Details
Arguments
{"search_text": "readonly", "file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"]}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 28
1106|.ev-step-panel.is-readonly .form-control,
1107|.ev-step-panel.is-readonly .custom-select,
1108|.ev-step-panel.is-readonly .select2-selection,
1109|.ev-step-panel.is-readonly .ssma-shared-upload-area {
1114|.ev-step-panel.is-readonly .form-check-input,
1115|.ev-step-panel.is-readonly #ev-body-map-host {
1118|.ev-step-panel.is-readonly #ev-body-map-host {
1402|.ev-step-panel.is-readonly .custom-modern-select-trigger {
1407|.ev-step-panel.is-readonly .ev-inj-descaracter-btn {
3337| function evSetAprofundamentoReadonly(readonly) {
3340| if (panel) panel.classList.toggle('is-readonly', !!readonly);
3342| alert.classList.toggle('d-none', !readonly);
3359| el.disabled = !!readonly;
3421| general.classList.toggle('is-readonly', !!evAprofundamentoOnlyMode);
3436| evSetAprofundamentoReadonly(!evCanEditAprofundamento(evSelectedType()));
5185| evSetAprofundamentoReadonly(!evRequiresAprofundamento(type) || !evCanEditAprofundamento(type));
5597| var panelReadonly = !!(document.getElementById('ev-step-aprofundamento') || {}).classList
5598| && document.getElementById('ev-step-aprofundamento').classList.contains('is-readonly');
5605| var requireInjury = showFullInjury && !panelReadonly;
5635| el.disabled = !!panelReadonly;
5636| el.required = !panelReadonly;
5638| el.disabled = !!panelReadonly;
5639| el.required = !panelReadonly && showTypeSeverity;
5653| el.disabled = panelReadonly;
5686| el.disabled = panelReadonly;
5932| evSetAprofundamentoReadonly(!evRequiresAprofundamento(evSelectedType()) || !evCanEditAprofundamento(evSelectedType()));
6235| if (generalPanel) generalPanel.classList.remove('is-readonly');
6677| if (generalPanelCreate) generalPanelCreate.classList.remove('is-readonly');
Request #55
deepseek-v4-flash
P:72.14K C:296 CR:71.3K CW:0
2832ms
Reasoning
There's `.ev-step-panel.is-readonly .ev-inj-descaracter-btn` styling line 1407, and CSS at 1106-1118 for `.form-control`, `.form-check-input`. If `.ev-step-panel.is-readonly` disables pointer events (or opacity), probably those cover the new `.ev-type-desc-btn` (with class mhs-btn-cancel) and `.ev-type-descaracter-suspect` (form-check-input). Let me read 1100-1130 and 1400-1410.
Tool Calls (2)
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 1098, "end_line": 1130}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 1098-1130
1098|#modalEventNew-offcanvas-wrapper .ev-steps-bar .insp-step-seg.active {
1099| background: var(--primary, #186073);
1100|}
1101|#ev-aprofundamento-denied-alert {
1102| background-color: #fff8e1;
1103| border-color: #ffe8a1;
1104| color: #856404;
1105|}
1106|.ev-step-panel.is-readonly .form-control,
1107|.ev-step-panel.is-readonly .custom-select,
1108|.ev-step-panel.is-readonly .select2-selection,
1109|.ev-step-panel.is-readonly .ssma-shared-upload-area {
1110| background-color: #F1F3F5 !important;
1111| opacity: 0.78;
1112| pointer-events: none;
1113|}
1114|.ev-step-panel.is-readonly .form-check-input,
1115|.ev-step-panel.is-readonly #ev-body-map-host {
1116| pointer-events: none;
1117|}
1118|.ev-step-panel.is-readonly #ev-body-map-host {
1119| opacity: 0.45;
1120|}
1121|.ev-ap-body-map-field {
1122| text-align: center;
1123|}
1124|.ev-ap-body-map-title {
1125| color: #1E1E1E;
1126| font-size: 12px;
1127| font-weight: 600;
1128|}
1129|.ev-ap-body-map-field #ev-body-map-host {
1130| margin-left: auto;
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 3337, "end_line": 3430}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 3337-3430
3337| function evSetAprofundamentoReadonly(readonly) {
3338| var panel = document.getElementById('ev-step-aprofundamento');
3339| var alert = document.getElementById('ev-aprofundamento-denied-alert');
3340| if (panel) panel.classList.toggle('is-readonly', !!readonly);
3341| if (alert) {
3342| alert.classList.toggle('d-none', !readonly);
3343| if (evIsAprofundamentoFinalized() && !EV_IS_ADMIN_APROFUNDAMENTO) {
3344| alert.innerHTML = '<i class="fas fa-lock mr-2"></i>Aprofundamento finalizado. Somente um administrador ou gestor administrador pode alterar.';
3345| } else {
3346| alert.innerHTML = '<i class="fas fa-exclamation-triangle mr-2"></i>O aprofundamento é preenchido pelo profissional responsável (gestor direto do colaborador ou equipe técnica SSMA).';
3347| }
3348| }
3349| var controls = document.querySelectorAll(
3350| '#ev-technical-section input, #ev-technical-section select, #ev-technical-section textarea,' +
3351| '#ev-spec-type-card input, #ev-spec-type-card select, #ev-spec-type-card textarea,' +
3352| '#ev-gravity-wrap input, #ev-gravity-wrap select,' +
3353| '#ev-corrective-actions-section input, #ev-corrective-actions-section select, #ev-corrective-actions-section textarea, #ev-corrective-actions-section button,' +
3354| '#ev-step-aprofundamento .ev-inj-descaracter-btn'
3355| );
3356| Array.prototype.forEach.call(controls, function (el) {
3357| if (!el || el.type === 'hidden') return;
3358| if (el.classList && el.classList.contains('ev-inj-descaracter-suspect-ro')) return;
3359| el.disabled = !!readonly;
3360| });
3361| // Reaplica bloqueio Sem dano — o loop acima zera disabled de todos os selects.
3362| evSyncInjuryTypeByConsequence();
3363| evSyncDescaracterStageUi();
3364| }
3365|
3366| function evUpdateFooter() {
3367| var type = evSelectedType();
3368| var canEditAprofundamento = evCanEditAprofundamento(type);
3369| var back = document.getElementById('ev-btn-back');
3370| var cancel = document.getElementById('ev-btn-cancel');
3371| var save = document.getElementById('ev-btn-save');
3372| var draft = document.getElementById('ev-btn-draft');
3373| var label = document.getElementById('ev-btn-label');
3374| if (draft) {
3375| draft.classList.toggle('d-none', !evAprofundamentoOnlyMode || evCurrentStep !== 'aprofundamento');
3376| }
3377| if (evAprofundamentoOnlyMode) {
3378| if (back) back.classList.add('d-none');
3379| if (cancel) cancel.classList.remove('d-none');
3380| if (!label || !save) return;
3381| if (evIsAprofundamentoFinalized() && !EV_IS_ADMIN_APROFUNDAMENTO) {
3382| save.disabled = true;
3383| save.classList.add('d-none');
3384| if (draft) draft.classList.add('d-none');
3385| return;
3386| }
3387| save.classList.remove('d-none');
3388| save.disabled = false;
3389| label.textContent = evIsAprofundamentoFinalized() ? 'Salvar alterações' : 'Finalizar';
3390| return;
3391| }
3392| if (back) back.classList.toggle('d-none', evCurrentStep !== 'aprofundamento');
3393| if (cancel) cancel.classList.toggle('d-none', evCurrentStep === 'aprofundamento');
3394| if (!label || !save) return;
3395| save.classList.remove('d-none');
3396| save.disabled = false;
3397| if (evCurrentStep === 'general') {
3398| label.innerHTML = (evRequiresAprofundamento(type) && evCanEditAprofundamento(type))
3399| ? 'Aprofundamento <i class="fas fa-chevron-right ml-1"></i>'
3400| : ((document.getElementById('ev_form_mode') || { value: 'create' }).value === 'edit'
3401| ? 'Salvar alterações'
3402| : 'Registrar');
3403| return;
3404| }
3405| label.textContent = (document.getElementById('ev_form_mode') || { value: 'create' }).value === 'edit'
3406| ? 'Salvar alterações'
3407| : 'Registrar';
3408| // Registrar nunca fica bloqueado por falta de permissão de aprofundamento.
3409| save.disabled = false;
3410| }
3411|
3412| function evSetStep(step) {
3413| if (evAprofundamentoOnlyMode) {
3414| step = 'aprofundamento';
3415| }
3416| evCurrentStep = step === 'aprofundamento' ? 'aprofundamento' : 'general';
3417| var general = document.getElementById('ev-step-general');
3418| var apro = document.getElementById('ev-step-aprofundamento');
3419| if (general) {
3420| general.classList.toggle('d-none', evCurrentStep !== 'general');
3421| general.classList.toggle('is-readonly', !!evAprofundamentoOnlyMode);
3422| }
3423| if (apro) apro.classList.toggle('d-none', evCurrentStep !== 'aprofundamento');
3424| document.querySelectorAll('#ev-steps-bar .insp-step-seg').forEach(function (bar) {
3425| var key = bar.getAttribute('data-ev-progress');
3426| if (evAprofundamentoOnlyMode) {
3427| bar.classList.toggle('is-active', key === 'aprofundamento');
3428| bar.classList.toggle('active', key === 'aprofundamento');
3429| } else {
3430| bar.classList.toggle('is-active', key === 'general' || key === evCurrentStep);
Request #56
deepseek-v4-flash
P:74.42K C:532 CR:72.32K CW:0
5315ms
Reasoning
evSetAprofundamentoReadonly disables controls in `#ev-technical-section`, `#ev-spec-type-card`, etc. The new per-type roots are inside those sections, so they become disabled in readonly mode. Good, no new bug there (though it also means the type-desc buttons get disabled). Fine.
Now check the change at line 2216/7200 - `evIsDescaracterSuspectChecked` reading type-root: This global behavior extends to the AP injured cards and payload. But this is consistent with the type root toggling global checkbox.
Now let's look at the "suspect" general step flow for ROS/QA/AM/AA with the new UI: The new partial for ROS (in aprofundamento) requires the user to open the aprofundamento step. But is that reachable in flow for types that previously did NOT require aprofundamento? e.g., for ROS/QA, aprofundamento is always there. For AM/AA too. For ROS maybe? Actually all types have technical aprofundamento.
Hmm. Big possible bug candidate: ROS/QA/AM/AA previously never had descaracterização; the descaracter_suspect/descaracterizado fields were AP-only (see export schema `ap_descaracter_suspect`). Now the PR adds descaracter fields to ROS etc. But given the feature intent (per type flags), this is the intended change.
Now let's examine the backend: when saving ROS with `payload.descaracter_suspect` and `descaracterizado`, SsmaEventValidator line 719: `$hasSuspect = !empty($d['descaracter_suspect']) && $d['descaracter_suspect'] !== '0';`. Let me look at the validator logic to see if requiring descaracter fields for ROS causes validation to force values on fields that previously didn't exist or would be validated differently. Since ROS events with no AP may not have validation requiring "caracterizado" but suspect present? Let's read SsmaEventValidator around 700-760.
Tool Calls (1)
file_read
Show Details
Arguments
{"file_path": "src/Service/Ssma/SsmaEventValidator.php", "start_line": 690, "end_line": 780}
Result
File: src/Service/Ssma/SsmaEventValidator.php (Total lines: 887)
IS_TRUNCATED: false
LINE_RANGE: 690-780
690| if (!\is_string($d['body_location_detail'])) {
691| $errors[] = 'Detalhe da localização no corpo deve ser texto.';
692| } elseif (mb_strlen((string) $d['body_location_detail']) > 2000) {
693| $errors[] = 'Detalhe da localização no corpo: no máximo 2000 caracteres.';
694| }
695| }
696| /* hand_finger / foot_toe no nível details: legado (MAO/PE sem lado); preferir por body_parts[]. */
697| $allowedHandFlat = ['POLEGAR', 'INDICADOR', 'MEDIO', 'ANULAR', 'MINIMO'];
698| $allowedFootFlat = ['HALUX', 'SEGUNDO_DEDO', 'TERCEIRO_DEDO', 'QUARTO_DEDO', 'MINIMO_PE'];
699| if (!empty($d['hand_finger'])) {
700| foreach (array_filter(array_map('trim', explode(',', (string) $d['hand_finger']))) as $v) {
701| if (!\in_array($v, $allowedHandFlat, true)) {
702| $errors[] = 'Dedo da mão inválido: ' . $v;
703| }
704| }
705| }
706| if (!empty($d['foot_toe'])) {
707| foreach (array_filter(array_map('trim', explode(',', (string) $d['foot_toe']))) as $v) {
708| if (!\in_array($v, $allowedFootFlat, true)) {
709| $errors[] = 'Dedo do pé inválido: ' . $v;
710| }
711| }
712| }
713| }
714|
715| $descVal = array_key_exists('descaracterizado', $d) ? (string) $d['descaracterizado'] : '';
716| // Caracterizar é do médico no aprofundamento dedicado — não na criação.
717| // Sim/Não + comentário só são obrigatórios quando há suspeita de descaracterização marcada.
718| if (!empty($data['aprofundamento_only'])) {
719| $hasSuspect = !empty($d['descaracter_suspect']) && $d['descaracter_suspect'] !== '0';
720| if ($hasSuspect) {
721| if (!\in_array($descVal, ['0', '1'], true)) {
722| $errors[] = 'Informe se o evento é caracterizado como acidente (Sim/Não).';
723| } else {
724| $comment = trim((string) ($d['descaracter_comment'] ?? ''));
725| if ($comment === '') {
726| $errors[] = 'Comentário de caracterização do acidente é obrigatório.';
727| }
728| }
729| }
730| }
731|
732| return $errors;
733| }
734|
735| private function validateAcidenteMaterial(array $d): array
736| {
737| $errors = [];
738|
739| if (empty($d['potential_severity']) || !PotentialSeverityEnum::isValid($d['potential_severity'])) {
740| $errors[] = 'Consequência potencial / Gravidade é obrigatória. Selecione uma opção válida.';
741| }
742|
743| if (empty($d['asset_type'])) {
744| $errors[] = 'Tipo de ativo é obrigatório para Acidente Material.';
745| }
746| if (!isset($d['operational_impact'])) {
747| $errors[] = 'Impacto operacional é obrigatório.';
748| }
749| // Barreira que falhou removida do formulário AM (Brenda) — legado opcional.
750| if (!empty($d['failed_barrier']) && !FailedBarrierEnum::isValid((string) $d['failed_barrier'])) {
751| $errors[] = 'Barreira que falhou: valor inválido.';
752| }
753| if (empty($d['barrier_type']) || !BarrierTypeEnum::isValid((string) $d['barrier_type'])) {
754| $errors[] = 'Tipo de barreira é obrigatório. Selecione uma opção válida.';
755| }
756|
757| return $errors;
758| }
759|
760| private function validateAcidenteAmbiental(array $d): array
761| {
762| $errors = [];
763|
764| if (empty($d['potential_severity']) || !PotentialSeverityEnum::isValid($d['potential_severity'])) {
765| $errors[] = 'Consequência potencial / Gravidade é obrigatória. Selecione uma opção válida.';
766| }
767|
768| if (empty($d['environmental_medium']) || !EnvironmentalMediumEnum::isValid((string) $d['environmental_medium'])) {
769| $errors[] = 'Meio ambiental é obrigatório. Selecione uma opção válida.';
770| }
771| // Formulário novo envia PollutantTypeEnum. Texto livre já gravado (legado) também
772| // passa, para não bloquear re-save de eventos antigos.
773| $pollutant = trim((string) ($d['pollutant_type'] ?? ''));
774| if ($pollutant === '') {
775| $errors[] = 'Tipo de poluente é obrigatório. Selecione uma opção válida.';
776| }
777| if (!isset($d['containment_done'])) {
778| $errors[] = 'Informe se houve contenção.';
779| }
780| // external_impact: removido do cadastro (Parte 1 C7) — opcional/legado, não bloqueia save.
Request #57
deepseek-v4-flash
P:76.36K C:660 CR:74.88K CW:0
5853ms
Reasoning
Let's read the descaracter block in `validateAcidentePessoal` to see the original rules. But we've already seen this.
Actually more important: The general step payload for ROS/QA when creating an event with no aprofundamento_only... `evApplyTypeDescaracterPayload(payload, 'ROS')` sets payload.descaracter_suspect only (0 or 1); in the case where `evAprofundamentoOnlyMode` is false (step 1 general save) and the root `ev-type-descaracter` might be hidden (d-none because step-aprofundamento hidden but root may still be checked in DOM). Wait if the root exists but is inside hidden step, its checkbox state could still be `checked` if it was previously checked in an earlier editing session and then user goes back to the general step (in create mode they may go back from aprofundamento to general). Then `evApplyTypeDescaracterPayload` sets `descaracter_suspect=1` while not aprofundamento_only. Then backend validation for non-aprofundamento... If `descaracter_suspect=1` but the aprofundamento_only flag is false, no cross-field validation. But when saving the general step it overwrites? SsmaEventService line 161 lists the allowed fields; `descaracter_suspect` maybe stored.
But the real issue: In the general step, when saving "step 1" of ROS with `payload.descaracter_suspect` possibly 0, previously a ROS event's details would contain no descaracter_suspect. But there might be a semantic gate elsewhere that shows alert red flag on the list if `descaracter_suspect=1` for events. That is intended if suspect exists.
Not confident enough.
Wait—the more serious issue: ROS/QA/AM/AA are NOT AP; the descaracter UI comment on line 217 says "Há suspeita de descaracterização do acidente?" in a ROS block that describes near-miss; is descaracterization semantically valid for ROS/QA? That is a product question; can't assert.
Let's now consider the SsmaEventValidator for ROS (validateRos) and QA (validateQuaseAcidente). Does the new descaracter fields block create any required validation? Since these new payload keys come only from UI and are allowed in the save allowlist (`SsmaEventService` line 161 or `SsmaController` line 26988 list) maybe not included for ROS... Not a concern unless payload keys get stripped.
Let's read SsmaEventService lines ~130-200 to understand how details persisted and per-card data handled.
Tool Calls (1)
file_read
Show Details
Arguments
{"file_path": "src/Service/Ssma/SsmaEventService.php", "start_line": 130, "end_line": 230}
Result
File: src/Service/Ssma/SsmaEventService.php (Total lines: 859)
IS_TRUNCATED: false
LINE_RANGE: 130-230
130| if (array_key_exists($topKey, $card)) {
131| $payload[$topKey] = $card[$topKey];
132| }
133| }
134|
135| $payloads[] = $payload;
136| }
137|
138| return $payloads;
139| }
140|
141| /**
142| * @param array<string, mixed> $baseDetails
143| * @param array<string, mixed> $card
144| *
145| * @return array<string, mixed>
146| */
147| private function mergeInjuredCardIntoDetails(array $baseDetails, int $personId, array $card): array
148| {
149| $details = $baseDetails;
150| $details['person_id'] = $personId;
151| $details['injured_person_details'] = [(string) $personId => $card];
152|
153| $hadInjury = $card['had_injury'] ?? $details['had_injury'] ?? null;
154| if ($hadInjury !== null) {
155| $details['had_injury'] = $hadInjury;
156| }
157|
158| foreach ([
159| 'injury_type', 'injury_classification', 'work_leave', 'body_parts',
160| 'body_location_detail', 'attendance_date', 'breve_relato',
161| 'descaracter_suspect', 'descaracterizado', 'descaracter_comment',
162| 'consequence', 'potential_consequence',
163| ] as $key) {
164| if (array_key_exists($key, $card)) {
165| $details[$key] = $card[$key];
166| }
167| }
168|
169| $cardSeverity = PotentialSeverityEnum::coerce($card['potential_severity'] ?? null)
170| ?? PotentialSeverityEnum::coerce($card['consequence'] ?? null)
171| ?? PotentialSeverityEnum::coerce($card['potential_consequence'] ?? null)
172| ?? PotentialSeverityEnum::coerce($details['potential_severity'] ?? null);
173| if ($cardSeverity !== null) {
174| $details['potential_severity'] = $cardSeverity;
175| }
176|
177| if (!isset($details['injury_severity'])) {
178| $details['injury_severity'] = '';
179| }
180|
181| $injClass = strtoupper(trim((string) ($details['injury_classification'] ?? '')));
182| if ($injClass === 'LTI_FATALIDADE') {
183| $details['injury_classification'] = 'FAT';
184| }
185|
186| if (!empty($card['descaracter_suspect'])) {
187| $details['descaracter_suspect'] = 1;
188| } elseif (array_key_exists('descaracter_suspect', $card)) {
189| $details['descaracter_suspect'] = 0;
190| }
191|
192| return $details;
193| }
194|
195| /**
196| * Atualiza um SsmaEvent existente com um payload parcial ou completo.
197| *
198| * @param array<string, mixed> $data
199| * @param array<string, mixed> $editorMeta name, role (Colaborador|Profissional|Administrador)
200| */
201| public function updateFromPayload(SsmaEvent $event, array $data, User $user, array $editorMeta = []): SsmaEvent
202| {
203| $prevStatus = $event->getStatus();
204| $prevConsequence = $event->getConsequence();
205| $prevType = $event->getType();
206| $prevDetails = $event->getDetails();
207| $prevLocation = $event->getLocation();
208| $prevDescription = $event->getDescription();
209|
210| if (isset($data['details']) && is_array($data['details'])) {
211| $existingDetails = is_array($event->getDetails()) ? $event->getDetails() : [];
212| $incomingDetails = $data['details'];
213| // Front sempre envia evidences: [] quando a lista local está vazia — não apagar anexos já salvos.
214| foreach (['evidences', 'ros_resolution_evidences'] as $evKey) {
215| if (
216| array_key_exists($evKey, $incomingDetails)
217| && is_array($incomingDetails[$evKey])
218| && $incomingDetails[$evKey] === []
219| && is_array($existingDetails[$evKey] ?? null)
220| && $existingDetails[$evKey] !== []
221| ) {
222| unset($incomingDetails[$evKey]);
223| }
224| }
225| $data['details'] = array_merge($existingDetails, $incomingDetails);
226| }
227|
228| $this->applyPayload($event, $data);
229|
230| // Permitir override explícito de status; se não enviado, preserva o status atual.
Request #58
deepseek-v4-flash
P:78.26K C:2.34K CR:76.93K CW:0
19817ms
Reasoning
OK. Now, I realize there's a possibly significant NEW issue in the controller in the diff that isn't covered: The code path computes the flags once per SSR page for both `index.html.twig` and `occurrence_view.html.twig`. But `SsmaController` also renders an AJAX-returned "detail view" partial for occurrence? Might be fine.
Let me step back and focus on important things I can strongly verify:
Issue candidates remaining (not overlapping with the 5 confirmed):
C1. In `memberCanDescharacterizeForType`, `$this->getRepository(SsmaPermissionTag::class)` — actually uses `$this->em->getRepository(SsmaPermissionTag::class)`. Fine.
C2. `findBy(['company' => $company, ...])`: strict company scoping. Good. But what about `$company instanceof Company && $currentMemberForExport` guard: For a tenant super admin with no CompanyMembers record (because admins are excluded from member list), `$currentMemberForExport` is null so the map empty; previously the old helper returned true for ROLE_SUPER_ADMIN without member. That's confirmed #1.
C3. The service is now called on a GET (read) path for every index/detail render of occurrences. `findOrCreateEntity` can create + flush a config entity if company not yet configured → DB write on GET. But this pre-existed through other methods in that service for similar tasks; not introduced materially new? The previous code called `memberCanDescharacterizeAccident` which also calls `findOrCreateEntity`. So no new side effect; it's a wash.
C4. Possible **missing the 'ACIDENTE_PESSOAL' key usage with map but `ROS` vs `QUASE_ACIDENTE`**: For `_ev_injured_person_box`, AP block gated by AP flag. Wait, confirmed #3 covers.
C5. **Duplicate rendering / stale UI when the user has permission only for one type**: The blocks render only if the corresponding flag is set. However the ROS and QA both within `#ev-spec-type-card`, AM and AA within `#ev-technical-section`. When a user opens an edit for ROS occurrence where they only have permission for type ROS, block appears for ROS, and when they switch... no.
C6. In the new partial, the checkbox and buttons of descaracterization appear in aprofundamento ONLY for people with flag. But for ROS, the suspicion used to be something only the relator could register in the first step? Not sure; not enough data.
C7. The Twig new partial `_ev_descaracter_suspect_block.html.twig` uses `ssmaCanDescharacterizeByType[_type_key]|default(false)` — but the array could be missing entirely in contexts where partial included from other template (only index/occurrence_view includes _modal_event, and partial included only from _modal_event). So always in scope. Fine.
C8. **Potential mismatch between feature gate and the permission who can edit aprofundamento.** Under the new code, rendering of the type-based suspect/descaracter UI is gated by the "Descaracterizar" tag column for that type. But this conflicts with the injured card where "suspeita editável por qualquer especialista AP" per old comment. In confirmed #3.
Hmm, maybe look at other aspect: For `_modal_event.html.twig` rendering for **creation of a new event** (openCreate). There is `ssmaCanDescharacterizeByType` passed from the page. During create, for a ROS event, aprofundamento fields shown after general step; the descaracter root visible if the user has ROS descaracter tag. This extends descaracterization to ROS etc. But wait—the descaracterização (descaracterização de acidente) concept likely applies only to ACIDENTE_PESSOAL. Extending to ROS/QA/AM/AA would change business logic. Actually, a "quase acidente" by definition is not an accident so descaracterization makes no sense (a near miss has no CAT). This is speculative though. Not solid.
Let me review the original per-AP behavior of `evSyncDescaracterStageUi` and note: the new per-type blocks are not synced to step state (always shown in aprofundamento). But if the user is in AP-only (evAprofundamentoOnlyMode true) and type=ROS, then suspect UI shows for ROS regardless. Before this PR (for ROS), the block didn't exist. Is there a risk that a specialist opening aprofundamento for an existing ROS without a tag flag won't show? Yes by design.
Now look at the confirmed finding #4, note that in the reported text they said the field set cross types. But there is one more nuance — beyond `descaracterizado`, the comment `.ev-type-descaracter-comment` per root read from its own root: good. And `descaracter_suspect` also per-root. But `ev_descaracterizado` global is shared across blocks: yes.
New candidate: When the user selects "Sim"/"Não" in one type block, the buttons' active state is managed via `window.SsmaShared.toggleYesNo(root.querySelectorAll('.ev-type-desc-btn'), ...)`. Buttons within the clicked root are toggled properly.
But when modal re-opens to edit an existing ROS event with descaracter_comment previously saved, the restore code at 6548 sets `comm.value` from `det.descaracter_comment`. However the restore code sets this same comment into ALL roots (all types) because comment is global in the saved event details. If the saved comment was 'abc' for ROS, then if user switches type in create mode... covered #4.
Let me now also look at whether restoring per-type root Suspect checkbox and "Sim/Não" button active states happen correctly when event loaded: line 6548 sets checkbox; line 6552 shows yesno; but the Sim/Não button active state (button active class toggling) not set from stored descVal for type blocks — descVal global `ev_descaracterizado` set at 6567 then `evSyncDescaracterUi()` syncs button states only for `.ev-inj-descaracter-btn` (AP card), not for `.ev-type-desc-btn` in per-type roots. Let's check `evSyncDescaracterUi` further lines 2998+. It only iterates `.ev-inj-descaracter-btn`. The per-type `.ev-type-desc-btn` active class will only be set when user clicks; the global hidden will hold value, but the visible Sim/Não buttons in the root won't show active state on load. That's a UI regression but not a correctness bug in payload because descVal read from hidden global. But wait: hidden `ev_descaracterizado` is the single source for Sim/Não. So on reload, active class not set → user sees neither Sim nor Não selected, but hidden has value. If the user doesn't re-click, `evApplyTypeDescaracterPayload` uses hidden value → saves correctly. If the user clicks "Sim", the hidden updated. Actually there's a subtle bug: the user could click "Não" only if they're authorized to descaracterize; but the Sim/Não isn't disabled for non-descaracterize users in the type blocks! Unlike AP card flow where `evSyncDescaracterUi` disables "Não" when `!canSn`... For the new type blocks (ROS/QA/AM/AA), the block itself only renders if the user has the tag Descaracterizar permission for that type. So all users seeing the block have permission. OK fine.
For the load of buttons active class issue — is there UI? Wait line 6552 yesno `.ev-type-descaracter-yesno` show when suspect on. But the active state of the Sim/Não buttons in the root may not restore. It'd display both buttons unhighlighted; global hidden keeps the value so saves remain correct. Minor UI inconsistency, but maybe not worth.
Let's look at the restore logic more carefully to see if there is a *data loss* bug: line 6567 sets hidden ev_descaracterizado from `det.descaracterizado`/`data.descaracterizado`. For a ROS event saved with `descaracterizado = '0'` and comment, on edit mode, the type block visible only for ROS. Suspect true → yesno shown. hidden has '0'. Save again → payload gets descaracterizado='0'. OK.
But suppose suspect = true but no Sim/Não was set in the stored event (old ROS events with descaracter_suspect=1 but no descVal), then on save the validator throws error requiring Sim/Não. Not new data problem.
I think the truly NEW findable issue might be:
**Issue A (medium):** New block for ROS etc. appears inside aprofundamento regardless of whether `descaracterização` is appropriate; not enough.
**Issue B:** `evSyncDescaracterStageUi` doesn't hide per-type `.ev-type-descaracter` root when type is not currently being shown? But since blocks live within each type's block (which are toggled d-none based on type), the root visibility follows type visibility. Actually wait: for ROS block (`ev-block-ros`) inside `ev-spec-type-card`; for AM/AA inside `ev-technical-section`. Both are sections shown only for their type. OK.
Hmm, but there is one more concrete thing: In step 1 (general), before choosing type or while the current step is general — the roots still exist in DOM and are visible? No, they are inside `ev-step-aprofundamento` which is d-none while in general. But the root's checkbox could still have stale checked state from previous sessions while saving step 1 payload. Let's examine the payload function that calls these branch blocks; is the payload for "general step" and "aprofundamento step" the same function? Look around line 7050-7100. The payload function building per-type, then `evApplyTypeDescaracterPayload` is included for each type. Let me examine where this build function is invoked to understand if it is used on both steps. Let me look at where the big function starts (before 7090). Let me look around 7000-7090.
Tool Calls (1)
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 7000, "end_line": 7092}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 7000-7092
7000| var catSel = document.getElementById('ev_category');
7001| if (catWrap && catSel && !catWrap.classList.contains('d-none')) {
7002| var catVal = (catSel.value || '').trim();
7003| if (catVal) {
7004| payload.category = catVal;
7005| }
7006| }
7007|
7008| var cd = document.getElementById('ev_classifier_dano');
7009| var cr = document.getElementById('ev_classifier_risco');
7010| var ca = document.getElementById('ev_classifier_afetado');
7011| if (cd && cd.value) payload.classifier_dano = cd.value;
7012| if (cr && cr.value) payload.classifier_risco = cr.value;
7013| if (ca && ca.value) payload.classifier_afetado = ca.value;
7014|
7015| if (evRequiresAccidentTechnical(type)) {
7016| var derivedCrit = evResolvePotentialSeverity(
7017| (document.getElementById('ev_derived_criticality_select') || {}).value,
7018| (document.getElementById('ev_derived_criticality') || {}).value,
7019| payload.consequence,
7020| payload.potential_consequence
7021| );
7022| if (derivedCrit) {
7023| payload.potential_severity = derivedCrit;
7024| }
7025| } else if (type === 'ROS') {
7026| // Campo já é a escala de gravidade (LEVE…CRITICO).
7027| var rosPc = (document.getElementById('ev_ros_potential_consequence') || { value: '' }).value;
7028| var rosSev = evResolvePotentialSeverity(rosPc);
7029| if (rosSev) payload.potential_severity = rosSev;
7030| } else if (type === 'QUASE_ACIDENTE') {
7031| var qaPc = (document.getElementById('ev_qa_potential_consequence') || { value: '' }).value;
7032| var qaCrit = evResolvePotentialSeverity(
7033| qaPc,
7034| (document.getElementById('ev_criticality') || {}).value
7035| );
7036| if (qaCrit) payload.potential_severity = qaCrit;
7037| } else {
7038| var critEl = document.getElementById('ev_criticality');
7039| if (critEl && critEl.value) {
7040| payload.potential_severity = evResolvePotentialSeverity(critEl.value) || critEl.value;
7041| }
7042| }
7043|
7044| if (evRequiresAprofundamento(type)) {
7045| payload.corrective_actions = evCollectCorrectiveActions();
7046| }
7047|
7048| // Marca 2ª etapa: backend exige campos técnicos só quando o médico finaliza o Aprofundamento.
7049| if (evCurrentStep === 'aprofundamento' && evAprofundamentoOnlyMode) {
7050| payload.aprofundamento_only = true;
7051| payload.aprofundamento_complete = !!finalizeAprofundamento;
7052| payload.aprofundamento_status = finalizeAprofundamento ? 'finalized' : 'draft';
7053| }
7054|
7055| // Etapa 1 de acidentes: não envia campos técnicos vazios (evita disparar validação da 2ª etapa).
7056| if (
7057| (type === 'ACIDENTE_PESSOAL' || type === 'ACIDENTE_MATERIAL' || type === 'ACIDENTE_AMBIENTAL')
7058| && evCurrentStep !== 'aprofundamento'
7059| && !evCanEditAprofundamento(type)
7060| ) {
7061| payload.consequence = '';
7062| payload.potential_consequence = '';
7063| delete payload.potential_severity;
7064| delete payload.injury_type;
7065| delete payload.injury_classification;
7066| delete payload.injury_severity;
7067| delete payload.descaracterizado;
7068| delete payload.descaracter_comment;
7069| delete payload.body_parts;
7070| delete payload.strategic_nature;
7071| delete payload.corrective_actions;
7072| delete payload.asset_type;
7073| delete payload.failed_barrier;
7074| delete payload.barrier_type;
7075| delete payload.environmental_medium;
7076| delete payload.pollutant_type;
7077| }
7078|
7079| if (mode === 'edit') {
7080| payload.status = document.getElementById('ev_status').value;
7081| } else {
7082| var stEl = document.getElementById('ev_status');
7083| payload.status = (stEl && stEl.value) ? stEl.value : 'ABERTO';
7084| }
7085|
7086| // ROS "Visto e resolvido" = SIM: a ocorrência já nasce (ou é salva) como resolvida.
7087| if (type === 'ROS' && evIsRosResolvedChecked()) {
7088| payload.status = 'CONCLUIDO';
7089| }
7090|
7091| if (type === 'ROS') {
7092| payload.deviation_type = document.getElementById('ev_deviation_type').value;
Request #59
deepseek-v4-flash
P:81.95K C:3.55K CR:80.51K CW:0
29167ms
Reasoning
So the per-type block of type-specific payload is always computed regardless of step, including when saving the general step in create mode. Interesting note: for ROS at step 1 (create) — `evApplyTypeDescaracterPayload(payload, 'ROS')` runs, sets payload.descaracter_suspect based on checkbox; but at create step 1, aprofundamento not yet performed, and checkbox is unchecked, so descaracter_suspect = 0. For ROS, this means saving step 1 stores `descaracter_suspect = 0` in details. Then when ROS later goes to aprofundamento, if user does nothing, it stays 0. When the ROS is finally finalized with aprofundamento and no suspect marked, descaracter_suspect remains 0. Fine.
Wait but what about the old logic: previously for ROS no descaracter fields were sent at step 1. Actually this only adds `descaracter_suspect: 0`. Could that trigger something? Backend: SsmaController line 26988 lists `... 'descaracter_suspect' ...` as allowed in the update path, presumably on validate/approval step maybe. Where might `descaracter_suspect=0` influence: possibly the list "ocorrências com suspeita de descaracterização" filters if descaracter_suspect == 1; no.
Let me not dig too deep.
Now let me review a possible *functional deadlock*: The type-based blocks appear only if the user has the Descaracterizar column for that tag, per the new server flag. But wait: the whole point per PR title "implement descharacterization flags by type for occurrences". OK.
Given confirmed #1-#5 are the main findings, maybe there are still some concrete NEW code-level bugs in the diff worth reporting. Let me examine the diff hunks in _modal_event.html.twig JS more carefully for actual mistakes:
1) `evApplyTypeDescaracterPayload` when called with the currently selected type always writes descaracter_suspect; if the type root missing (no permissão/flag), function returns early; OK.
2) At line 2928, `evIsDescaracterSuspectChecked` returns `!!document.querySelector('.ev-type-descaracter-suspect:checked')`. Because this is a global selector, when saving the AP type (ACIDENTE_PESSOAL), payload.descaracter_suspect would be true if ANY type root is checked even though AP block renders only if AP flag set. But those roots exist in DOM for all types (if flagged for ROS etc.), while creating an AP occurrence with no AP permission but ROS permission: the ROS root exists and is visible? No, only if the current type block is shown. But the roots exist in the DOM regardless of whether their block is visible — all the type blocks are in the DOM but only the active type block is displayed (other blocks d-none). Their checkboxes might be stale from prior interactions within the same session (e.g., switching types). That could leak `descaracter_suspect = 1` into an AP payload. This is essentially part of confirmed finding #4's general cross-type state issue (global hidden) — but #4 focused on descaracterizado hidden global across type saves. The `evIsDescaracterSuspectChecked()` reading any type root is a related but separate manifestation: AP save at line 7200 reads `.ev-type-descaracter-suspect:checked` global, whereas the AP UI path for suspicion is in per-card `.ev-inj-suspect-chk`, not `.ev-type-descaracter-suspect`. Wait: does AP card suspect state also mirror to global `ev_descaracter_suspect` (line 5816)? Yes, `.ev-inj-suspect-chk` mirrors into the global checkbox; and `evIsDescaracterSuspectChecked` checks global checkbox first, then any `.ev-type-descaracter-suspect:checked`. So AP card checks → global checkbox set (line 5816), so function reads true from global. Good. So the fallback to `.ev-type-descaracter-suspect` might be to support the type roots for ROS etc.
So the same state pollution issue. It may all fit within #4's scope but this particular one about reading in evIsDescaracterSuspectChecked and its usage for AP could be new detail. Hmm.
I think we should be careful about duplicates. Let me read confirmed #4 precisely again: "Os quatro blocos por tipo (ROS, quase acidente, acidente material/ambiental) gravam o Sim/Não num único campo escondido global (`ev_descaracterizado`) e este payload lê esse campo global independentemente do tipo que está sendo salvo. Se o usuário trocar o tipo na criação ou alternar entre ocorrênci..." yes. It includes the shared-global-state concern. The `evIsDescaracterSuspectChecked` reading any type root is the "suspect" analog of the same shared-state design flaw. It might be worth reporting separately as it's a distinct root cause (reading any of the type-suspect checkboxes) and affects AP saving and per-card serialization too. But because it's the same conceptual category (cross-type contamination from all blocks in DOM), I'll consider reporting it as a separate but lower-severity note only if distinct enough.
Actually wait — there's a bigger concern: `evReadCardInjuryData` (per-card AP serialization) reads `evIsDescaracterSuspectChecked()` global; because each card's data include descaracter_suspect via global, meaning per-card suspect identical globally. Pre-existing pattern? It was already the case (since each card reads `#ev_descaracter_suspect`). Adding the type roots selector introduces new routes to pollution. Actually before this PR the function already returned from global `#ev_descaracter_suspect`. So the new cross-type roots only matter when global is false and a type root checked. That's for ROS/QA/AM/AA whose root in DOM could be checked while saving an AP occurrence — only if the user switched types within the same session and left ROS suspect checked, then later switched to AP. In such a case the AP payload would erroneously have suspect = 1 even though the per-card suspect checkboxes are unchecked (but they mirror global checkbox which isn't updated when checking the type root... wait, when checking a type root at line 5788-5789 it sets the global checkbox checked! So global checkbox would be checked too, and the AP per-card checkboxes? In create, the AP cards may not exist yet at that time; if cards are rendered later (via evRenderInjuredPersonBoxes), do they mirror the global suspect state? Possibly they initialize checked=false. Let me not overreach.
There is the line in restore: 6547 `evSetChk('ev_descaracter_suspect', suspectOn)`. Actually wait, line 6547 sets the global checkbox checked = suspectOn; then loops all roots. Hmm, but the global element is inside the general-step card `#ev-suspeita-wrap` which is hidden. So on edit load, when type-root suspect checked for ROS (det), global checked too. OK.
Given the confirmed findings already flag the central design problem (#4), reporting it again in another manifestation would be redundant. Let me not.
Now, distinct new items to potentially report:
(i) The controller removed the broad boolean and now the map is computed as a per-member fetch via the service in a read path; but **the same SSR route for `occurrence_view` also passes these flags for a DIFFERENT user context?** No.
(ii) In `SsmaOccurrenceTypeConfigService`, the docblock of `memberCanDescharacterizeForType` mentions tag 23 = QUASE_ACIDENTE; implementation strictly matches occurrenceTypeKey. But wait, `findBy(['company', 'occurrenceTypeKey'])` only looks at tags that have `occurrenceTypeKey` set to that typeKey. But if the customer's environment had already configured Descaracterizar members under `aprofundamento_descaracter['team:{id}']` or `tag:{id}` where tag does NOT have `occurrenceTypeKey` (e.g., the old AP tag configs or group-level), then these flags would silently be false. Covered #2.
(iii) `getDescharacterizeFlagsByType` loops 5 keys but only tags' Descaracterizar list is consulted; the requirement presumably "coluna Descaracterizar da tag daquele tipo (tag de aprofundamento)". The relationship between tag Descaracterizar column and `aprofundamento_descaracter['tag:{id}']` seems right.
(iv) There's no company-level membership isolation problem.
Let me check whether the controller or service use of company with different company filter could leak across company: service uses `$company` strictly in the config entity keyed per company and in tags query. Good.
Now let me revisit the `SsmaController` context lines around 12534. Wait: In the diff context `$company` variable is `?Company`. `$currentMemberForExport` from getCurrentCompanyMember. The old flag allowed `ROLE_MANAGER`/super admin auto — confirmed #1 covers removal of roles. But there's another nuance: **the whole new map returns `[]` for admin users with no member; then the JS template hides the UI and SSMA_CAN_DESCARACTERIZE false**. #1 covers that.
So among remaining new issues, let me look again at the `occurrence_view.html.twig` and `index.html.twig` change; those simply forward `ssmaCanDescharacterizeByType`. No bug.
Now `_ev_injured_person_box.html.twig` change: replaced old comment (Descaracterização — só no aprofundamento. Suspeita editável por qualquer especialista AP; Sim/Não só quem tem permissão Descaracterizar) and wrapped in the new gating `{% if %}` — meaning when permission missing, the entire AP descaracter block (including `.ev-inj-suspect-chk` used for red alert) removed → confirmed #3.
But also for the case where permission exists: The block is included and the code below (which ends with `</div>...` etc.) is unchanged.
One more possible NEW bug: In `_ev_descaracter_suspect_block.html.twig`, when included with `type_key` provided and permission on, the markup shows "Há suspeita de descaracterização do acidente?" etc. but the **Sim/Não choice (`.ev-type-desc-btn`) uses the same `data-descaracter-val` semantics as AP card (0=Sim/é acidente, 1=Não/descaracteriza)**. So far consistent.
OK now, an important one maybe: **data type of `$ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']` keyed strings must match the FIXED_TECHNICAL_OCCURRENCE_KEYS values.** All of ROS/QA/AM/AA/AP exist in constant. Good.
Let me now look at the line 7184-7200 in the modal for AP: payload.descaracter_suspect = evIsDescaracterSuspectChecked() ? 1 : 0; and the AP block in `_ev_injured_person_box` is gated to users with AP flag. But `payload.descaracter_suspect` at line 7200 is not gated: For AP users without the flag (no AP tag descaracter), the suspect checkbox from card is hidden. If the global checkbox (ev_descaracter_suspect) is not checked, descaracter_suspect 0 stored. Yet that's a *change* from the old flow where any AP specialist could mark suspect even without "Descaracterizar" column (since only Sim/Não required the column). This is essentially confirmed #3's text (especialistas AP podem marcar a suspeita, disparando alerta vermelho; apenas Sim/Não restrito). So covered.
Now the controller's service return type: `getDescharacterizeFlagsByType` is called with `(int) $currentMemberForExport->getId()`. Then service method signature: `memberCanDescharacterizeForType(Company $company, int $memberId, string $typeKey)`. If `getId()` returns int, fine.
Now new issue candidate: **`SsmaOccurrenceTypeConfigService::memberCanDescharacterizeForType` uses `$this->em->getRepository(SsmaPermissionTag::class)->findBy(...)` with no eager loading; each call does queries; and getDescharacterizeFlagsByType calls for each key = 5 queries + 5 config loads, each on SSR GET page loads** → performance. On heavy occurrence index/detail pages that already have many queries... Possibly worth a low/medium note? Performance rule says only with evidence of meaningful scale or hot path. This code runs once per page load of the occurrences hub and detail view for every user of the SSMA module. 10 extra DB queries per page view on a hot module. Since it was previously ONE call to `memberCanDescharacterizeAccident` (single config load), the new code multiplies by five and adds tags query. Might merit an "Atenção" performance note: batch the tag ids in a single query and load config once. Given the PR review strict focus on functional stuff and confirmed #1-5... But I should consider it a valid performance comment. Not blocking but a legit maintainability/performance improvement.
Also the service method name: `memberCanDescharacterizeForType` duplicates logic in the same file with `memberCanDescharacterizeAccident`; the confirmed #2 said it ignores team links. The duplication itself is maintainability, but #2 covers functionally.
Now the biggest unexplored one: The **security/integrity question**: The type-based descaracter UI for ROS/QA/AM/AA **is rendered inside aprofundamento; but for types other than AP, the suspect/descaracterization fields previously weren't part of the product**, meaning new data now stored for ROS etc. Then export/automations only map `ap_descaracter_suspect`. Could cause data mixing? Not severe.
Another: In ROS/QA creation, if the user checks suspect (with permission) but does NOT answer Sim/Não in step 1 (only step 2) and then saves step 1 with ROS type - payload.descaracter_suspect = 1 in step 1 (non-aprofundamento). Then the validator for ROS at general step doesn't enforce descaracter comment requirement (only when aprofundamento_only). OK.
Hmm, but does `evApplyTypeDescaracterPayload` write `payload.descaracter_suspect` in the general step but the hidden root is in the DOM (invisible) and possibly still carries an answer from a previous event because when opening modal for a NEW event, the roots' checkbox states are not reset in `openCreate`. So creating a new ROS after having edited an old ROS with suspect: openCreate might not reset `.ev-type-descaracter-suspect` and hidden `ev_descaracterizado`. Let me check `openCreate`/reset logic to see if form resets reset those fields. It could cause data from the previous event to leak into a new one. This would be a genuine new bug! Let's look at openCreate and reset function to see if they reset the root fields & hidden values.
Search "ev_descaracter" resets in the template.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "ev_descaracter_suspect", "file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"]}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 12
291| <input class="form-check-input" type="checkbox" id="ev_descaracter_suspect" name="ev_descaracter_suspect" value="1">
292| <label class="form-check-label" for="ev_descaracter_suspect">Há suspeita de descaracterização do acidente?</label>
465| {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
539| {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
887| {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
907| {% include 'ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig' with {
2926| var el = document.getElementById('ev_descaracter_suspect');
5774| var suspectChk = document.getElementById('ev_descaracter_suspect');
5788| var globalChk = document.getElementById('ev_descaracter_suspect');
5816| var globalChk = document.getElementById('ev_descaracter_suspect');
6547| evSetChk('ev_descaracter_suspect', suspectOn);
7184| var suspectEl = document.getElementById('ev_descaracter_suspect');
code_search
Show Details
Arguments
{"search_text": "function evResetForm|evClearForm|function evOpenCreate|openCreate = ", "file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"]}
Result
No matches found
Request #60
deepseek-v4-flash
P:85.87K C:183 CR:85.38K CW:0
2319ms
Reasoning
Let's find the reset flow: `evResetModalState`/`evResetForm`. Let me search for the reset function names referenced in openCreate.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "form.reset()", "file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"]}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig Match lines: 3 4891| /** Limpa chips, hiddens, evidências e UI auxiliar — form.reset() não cobre isso. */ 4903| form.reset(); 6219| if (form) form.reset();
code_search
Show Details
Arguments
{"search_text": "openCreate", "file_patterns": ["templates/ssma/occurrence/partials/_modal_event.html.twig"]}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 4
6650| window.EvModal.openCreate = function (opts) {
7739| if (window.EvModal && typeof window.EvModal.openCreate === 'function') {
7740| window.EvModal.openCreate(opts || {});
7743| console.error('[SSMA] EvModal.openCreate', err);
Request #61
deepseek-v4-flash
P:86.24K C:180 CR:86.02K CW:0
1796ms
Tool Calls (2)
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 4880, "end_line": 4930}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 4880-4930
4880| return;
4881| }
4882| for (var j = 0; j < sn.options.length; j++) {
4883| if (sn.options[j].value === 'SEGURANCA') {
4884| sn.selectedIndex = j;
4885| sn.value = 'SEGURANCA';
4886| break;
4887| }
4888| }
4889| }
4890|
4891| /** Limpa chips, hiddens, evidências e UI auxiliar — form.reset() não cobre isso. */
4892| function evResetCreateUiState() {
4893| if (evDraftTimer) {
4894| clearTimeout(evDraftTimer);
4895| evDraftTimer = null;
4896| }
4897| if (typeof evClearDraft === 'function') {
4898| evClearDraft();
4899| }
4900|
4901| var form = document.getElementById('form-event-new');
4902| if (form) {
4903| form.reset();
4904| }
4905|
4906| var shared = window.SsmaShared || {};
4907| var tc = (window.EvModal && window.EvModal._tagConfigs) ? window.EvModal._tagConfigs : {};
4908| if (typeof shared.resetTagSelect === 'function') {
4909| ['people', 'witnesses', 'responsible', 'body_region'].forEach(function (key) {
4910| if (tc[key]) {
4911| shared.resetTagSelect(tc[key]);
4912| }
4913| });
4914| }
4915|
4916| ['ev_people_ids', 'ev_witness_ids', 'ev_responsible_ids', 'ev_injured_person_details', 'ev_approach_custom'].forEach(function (id) {
4917| var el = document.getElementById(id);
4918| if (el) el.value = '';
4919| });
4920|
4921| var injBoxes = document.getElementById('ev_injured_person_boxes');
4922| if (typeof evParkBodyMapBlock === 'function') {
4923| evParkBodyMapBlock();
4924| }
4925| if (injBoxes) injBoxes.innerHTML = '';
4926| var personSelClear = document.getElementById('ev_person_id');
4927| if (personSelClear) personSelClear.removeAttribute('data-primary-injured-id');
4928|
4929| var hostReset = document.getElementById('ev-body-map-host');
4930| if (hostReset) {
file_read
Show Details
Arguments
{"file_path": "templates/ssma/occurrence/partials/_modal_event.html.twig", "start_line": 6195, "end_line": 6245}
Result
File: templates/ssma/occurrence/partials/_modal_event.html.twig (Total lines: 7801)
IS_TRUNCATED: false
LINE_RANGE: 6195-6245
6195| /* ── API pública para abertura em modo edição ─────────── */
6196| window.EvModal = window.EvModal || {};
6197| window.EvModal.populateForEdit = function (data) {
6198| var $ = window.jQuery;
6199| if (!$) return;
6200| window.__ssmaEvCreateMode = null;
6201| evAprofundamentoOnlyMode = false;
6202| evAprofundamentoCanEditFromServer = null;
6203| evAprofundamentoFinalizeIntent = true;
6204| var detEarly = (data && data.details && typeof data.details === 'object') ? data.details : (data || {});
6205| var aprofStatus = String(detEarly.aprofundamento_status || (data && data.aprofundamento_status) || '').toLowerCase();
6206| evAprofundamentoFinalized = aprofStatus === 'finalized'
6207| || !!(detEarly.aprofundamento_complete || (data && data.aprofundamento_complete));
6208| var typeWrap = document.getElementById('ev_type_wrap');
6209| if (typeWrap) typeWrap.classList.remove('d-none');
6210| var shared = window.SsmaShared || {};
6211| var tc = window.EvModal._tagConfigs;
6212| data = data || {};
6213| // det: objeto details (formato serialize) ou fallback para o próprio data (formato listagem)
6214| var det = (data.details && typeof data.details === 'object') ? data.details : data;
6215| var type = data.type || data.type_value || '';
6216|
6217| // Reset form
6218| var form = document.getElementById('form-event-new');
6219| if (form) form.reset();
6220| evApplyDatetimeMax();
6221| evEvidences = [];
6222| evEvidenceRenderList();
6223| evRosResolutionEvidences = [];
6224| if (typeof evRosResolutionEvidenceRenderList === 'function') {
6225| evRosResolutionEvidenceRenderList();
6226| }
6227|
6228| // Modo e ID
6229| document.getElementById('ev_form_mode').value = 'edit';
6230| document.getElementById('ev_id').value = String(data.id || '');
6231|
6232| var modalTitle = document.getElementById('ev-modal-title');
6233| if (modalTitle) modalTitle.textContent = 'Editar ocorrência';
6234| var generalPanel = document.getElementById('ev-step-general');
6235| if (generalPanel) generalPanel.classList.remove('is-readonly');
6236|
6237| // ── Campos básicos ──────────────────────────────────
6238| // Mapa legado: status_value da listagem usa slugs lowercase; o select precisa do enum
6239| var EV_STATUS_MAP = {
6240| nova: 'ABERTO',
6241| em_investigacao: 'EM_INVESTIGACAO',
6242| investigada: 'EM_ANALISE',
6243| aguard_validacao_medica: 'AGUARDANDO_VALIDACAO_MEDICA',
6244| aguard_validacao_tecnica: 'AGUARDANDO_VALIDACAO_TECNICA',
6245| finalizada: 'CONCLUIDO',
Request #62
deepseek-v4-flash
P:87.92K C:705 CR:86.4K CW:0
6669ms
Reasoning
So `form.reset()` is called on edit create reset. But checkboxes inside the form (`.ev-type-descaracter-suspect`, `.ev-inj-suspect-chk`) are part of the form? The new partial is inside the form presumably? Actually the checkboxes have no name attributes, but form.reset() resets checked states to their default (unchecked) regardless of name. However, the comment textareas `.ev-type-descaracter-comment` are inside the form and reset to default (empty). Good. `form.reset()` resets to default value (value from markup), which for textarea is '' and checkbox is unchecked. So a new create resets state as long as the elements are inside the form element. The partial is inside `form-event-new`? Need to confirm the modal elements are within the form. The whole offcanvas content is within `<form id="form-event-new">` likely. If the new partial is inside, reset works.
The hidden global `ev_descaracterizado` (id) — reset to '' by form.reset(). Since inside form, yes.
But after form.reset(), `evIsDescaracterSuspectChecked()` reads nothing.
Also openCreate and populateForEdit call form.reset() before setting data (populate for edit does form.reset() then populates). So state contamination between events likely not an issue because form.reset() precedes population. But is populateForEdit's form.reset() executed before restore code (line 6547)? Yes at 6219 reset, then fill later at 6545.
But one exception: The draft restore path (evRestoreDraft) may restore fields without resetting type roots? At line 2910ish the draft restore sets tag selects and injured details but may not sync `.ev-type-descaracter-suspect` states; but a draft restore would eventually call populate for edit? Probably fine.
OK. Let me step back. Given the already confirmed findings are strong, I need to decide which NEW issues to add.
Let me re-check the templates `_ev_descaracter_suspect_block.html.twig` for correct use of `_type_key` attribute matching what's expected by JS `evApplyTypeDescaracterPayload`. All type keys used = FIXED keys except AP. Good.
But notice in the partial, `data-descaracter-type="{{ _type_key }}"`, `id="ev-qa-descaracter"` only for QA.
Now, check: for QUASE_ACIDENTE the JS references `evGetTypeDescaracterRoot('QUASE_ACIDENTE')` etc. In the markup, `_type_key = 'QUASE_ACIDENTE'`; yes.
Now, could there be **duplicated element ids**: `#ev-qa-descaracter` vs other places referencing? Search maybe `ev-qa-descaracter` was already used for an existing element? Search in the file to verify no duplicate id introduced.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "ev-qa-descaracter"}
Result
File: templates/ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig
Match lines: 1
7| {% if _type_key == 'QUASE_ACIDENTE' %}id="ev-qa-descaracter"{% endif %}>
code_search
Show Details
Arguments
{"search_text": "data-descaracter-root"}
Result
File: templates/ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig
Match lines: 1
5| data-descaracter-root="1"
File: templates/ssma/occurrence/partials/_modal_event.html.twig
Match lines: 3
2932| return document.querySelector('[data-descaracter-root][data-descaracter-type="' + type + '"]');
5782| document.querySelectorAll('[data-descaracter-root]').forEach(function (root) {
6548| document.querySelectorAll('[data-descaracter-root]').forEach(function (root) {
Request #63
deepseek-v4-flash
P:88.84K C:980 CR:88.58K CW:0
8977ms
Reasoning
No id conflict.
Now consider the semantic: the descaracter suspect UI is inside the technical-type section for ROS/QA — meaning it appears in aprofundamento for the *relator/especialista*. But was this UI meant for the approval step in **AP only**? This whole PR is explicitly about adding these per type, so it's intended. OK.
Now, one more angle to consider: potential **XSS** in JS building HTML by type name? No type strings are user-controlled.
Let me reconsider the possibility that **the removal of the `ssmaCanDescharacterizeAccident` old gate also removed a "viewer"/"admin" override where the view shows the type blocks for `ACIDENTE_PESSOAL` based on AP flag.** Covered by #1/#3.
Actually wait. Confirm #3 says "Para quem não está marcado na coluna Descaracterizar da tag — incluindo especialistas de AP que preenchem o aprofundamento. Antes, qualquer especialista AP podia marcar a suspeita..." The old flow in the injured card per-person, where the block `.ev-inj-descaracter` (suspect checkbox) had `evSyncDescaracterStageUi` toggling d-none only when `!isAp || !isDoctorAprof`. So old: shown to any AP specialist in aprofundamento regardless of tag Descaracterizar flag. Yes.
Now let me consider the `occurrence_view.html.twig`/`index.html.twig` both pass only `ssmaCanDescharacterizeByType`. Good.
Wait — potential bug: `_modal_event.html.twig` is included in `index.html.twig` (line 114). `index.html.twig` is rendered at the occurrence listing that includes tabs including `_tab_occurrences.html.twig`. But the "new event" button opens the offcanvas; the modal markup also includes the partial with `ssmaCanDescharacterizeByType` value computed from the SSR route. On AJAX paging (the Hub "SSR/AJAX por página"), each page navigation likely re-renders the entire index page? Or fetches partial occurrence lists and updates table rows (not the modal). Since modal markup remains in place across paging (if it's full page reload with only table content updated via AJAX), the modal stays as first-rendered. Then no issue.
But for the occurrence **view** detail (not index), `show_aprofundamento_btn` may be true while `can_edit_occurrence` false. The include is inside `{% if can_edit_occurrence|default(false) or show_aprofundamento_btn|default(false) %}` — for read-only view with the aprofundamento button. That's fine.
Now a different nuance on the confirmed #4: I might want to check the actual SAVE payload when the same event has suspect but for type blocks. However covered.
Let me look for a NEW data-integrity bug in the type-specific flow for ROS/QA/AM/AA: When the aprofundamento is finalized on ROS/QA/AM/AA and suspect is checked with Sim/Não, backend validation in SsmaEventValidator validateAcidenteMaterial/Ambiental/QuaseAcidente — is there a general validate that runs `$this->validateDescaracterCommon`? Let's find where line 715-730 block is inside which function, since the snippet at 715 refers to `$data['aprofundamento_only']` and `$d['descaracter...']`. Which type validators get this block? Probably `validateAcidentePessoal`. Let's check to see if descaracter block validation applies only to AP. If new ROS/QA/AM/AA descaracter fields require similar validation but only AP validator covers it, then ROS suspect with no Sim/Não... would save without validation → data inconsistent. But also, the fields being allowed for ROS depends on which keys are whitelisted in the update flow.
Let me find function boundaries; read around 600-735 to find which validator encloses line 715-730, and see if ROS/QA validators include descaracter checks.
Tool Calls (1)
file_read
Show Details
Arguments
{"file_path": "src/Service/Ssma/SsmaEventValidator.php", "start_line": 560, "end_line": 735}
Result
File: src/Service/Ssma/SsmaEventValidator.php (Total lines: 887)
IS_TRUNCATED: false
LINE_RANGE: 560-735
560|
561| // fatal / barreira / causa imediata: opcionais (removidos do formulário de AP; legado ainda pode enviar)
562| if (array_key_exists('fatal', $d) && $d['fatal'] !== null && $d['fatal'] !== '') {
563| if (!\is_bool($d['fatal']) && !\in_array($d['fatal'], [0, 1, '0', '1'], true)) {
564| $errors[] = 'Campo fatalidade inválido.';
565| }
566| }
567| if (!empty($d['failed_barrier']) && !FailedBarrierEnum::isValid($d['failed_barrier'])) {
568| $errors[] = 'Barreira que falhou inválida. Selecione uma opção válida.';
569| }
570| // Dimensão trocada por Tipo de barreira (Brenda).
571| if (empty($d['barrier_type']) || !BarrierTypeEnum::isValid((string) $d['barrier_type'])) {
572| $errors[] = 'Tipo de barreira é obrigatório. Selecione uma opção válida.';
573| }
574| if (isset($d['immediate_cause']) && $d['immediate_cause'] !== null && !\is_string($d['immediate_cause'])) {
575| $errors[] = 'Causa imediata deve ser texto.';
576| }
577|
578| // Body map: condicional quando had_injury = true
579| if ($hadInjury && !empty($d['body_parts'])) {
580| if (!is_array($d['body_parts'])) {
581| $errors[] = 'Partes do corpo devem ser uma lista.';
582| } else {
583| $allowedHand = ['POLEGAR', 'INDICADOR', 'MEDIO', 'ANULAR', 'MINIMO'];
584| $allowedFoot = ['HALUX', 'SEGUNDO_DEDO', 'TERCEIRO_DEDO', 'QUARTO_DEDO', 'MINIMO_PE'];
585| $allowedCabeca = ['OLHO_ESQ', 'OLHO_DIR', 'BOCA', 'NARIZ', 'ORELHA_ESQ', 'ORELHA_DIR', 'TESTA', 'MENTO'];
586| $allowedPescoco = ['PESCOCO_ANT', 'PESCOCO_POST', 'PESCOCO_LAT_ESQ', 'PESCOCO_LAT_DIR'];
587| $allowedFace = ['FACE_BOCA', 'FACE_NARIZ', 'FACE_BOCHE_ESQ', 'FACE_BOCHE_DIR', 'FACE_MENTO', 'FACE_MAXILAR'];
588| $allowedOlhos = ['OLHO_ESQ', 'OLHO_DIR', 'SOBRANCELHA_ESQ', 'SOBRANCELHA_DIR'];
589| foreach ($d['body_parts'] as $i => $part) {
590| if (!\is_array($part)) {
591| $errors[] = 'Parte do corpo inválida.';
592|
593| continue;
594| }
595| if (empty($part['region']) || !BodyRegionEnum::isValid($part['region'])) {
596| $errors[] = 'Região do corpo inválida.';
597| }
598| if (!empty($part['side']) && !BodySideEnum::isValid($part['side'])) {
599| $errors[] = 'Lado do corpo inválido.';
600| }
601| if (!empty($part['injury_type']) && !InjuryTypeEnum::isValid($part['injury_type'])) {
602| $errors[] = 'Tipo de lesão inválido na região marcada.';
603| }
604| if (!empty($part['hand_finger'])) {
605| foreach (array_filter(array_map('trim', explode(',', (string) $part['hand_finger']))) as $v) {
606| if (!\in_array($v, $allowedHand, true)) {
607| $errors[] = 'Dedo da mão inválido: ' . $v;
608| }
609| }
610| }
611| if (!empty($part['foot_toe'])) {
612| foreach (array_filter(array_map('trim', explode(',', (string) $part['foot_toe']))) as $v) {
613| if (!\in_array($v, $allowedFoot, true)) {
614| $errors[] = 'Dedo do pé inválido: ' . $v;
615| }
616| }
617| }
618| $reg = (string) ($part['region'] ?? '');
619| if (!empty($part['cabeca_zones'])) {
620| if ($reg !== 'CABECA') {
621| $errors[] = 'Zonas de cabeça só são permitidas quando a região é Cabeça.';
622| } else {
623| foreach (array_filter(array_map('trim', explode(',', (string) $part['cabeca_zones']))) as $v) {
624| if (!\in_array($v, $allowedCabeca, true)) {
625| $errors[] = 'Zona de cabeça inválida: ' . $v;
626| }
627| }
628| }
629| }
630| if (!empty($part['pescoco_zones'])) {
631| if ($reg !== 'PESCOCO') {
632| $errors[] = 'Zonas de pescoço só são permitidas quando a região é Pescoço.';
633| } else {
634| foreach (array_filter(array_map('trim', explode(',', (string) $part['pescoco_zones']))) as $v) {
635| if (!\in_array($v, $allowedPescoco, true)) {
636| $errors[] = 'Zona de pescoço inválida: ' . $v;
637| }
638| }
639| }
640| }
641| if (!empty($part['face_zones'])) {
642| if ($reg !== 'FACE') {
643| $errors[] = 'Zonas de face só são permitidas quando a região é Face.';
644| } else {
645| foreach (array_filter(array_map('trim', explode(',', (string) $part['face_zones']))) as $v) {
646| if (!\in_array($v, $allowedFace, true)) {
647| $errors[] = 'Zona de face inválida: ' . $v;
648| }
649| }
650| }
651| }
652| if (!empty($part['olhos_zones'])) {
653| if ($reg !== 'OLHOS') {
654| $errors[] = 'Zonas de olhos só são permitidas quando a região é Olhos.';
655| } else {
656| foreach (array_filter(array_map('trim', explode(',', (string) $part['olhos_zones']))) as $v) {
657| if (!\in_array($v, $allowedOlhos, true)) {
658| $errors[] = 'Zona de olhos inválida: ' . $v;
659| }
660| }
661| }
662| }
663| }
664| }
665| }
666|
667| $workLeave = strtoupper(trim((string) ($d['work_leave'] ?? '')));
668| $injClass = strtoupper(trim((string) ($d['injury_classification'] ?? '')));
669| if ($hadInjury && $injClass === '') {
670| $errors[] = 'Classificação da lesão é obrigatória quando há lesão.';
671| }
672| if ($workLeave === 'PARCIAL') {
673| $errors[] = 'Afastamento parcial não é mais permitido. Use Com ou Sem afastamento.';
674| }
675| if ($workLeave !== '' && !\in_array($workLeave, ['NAO', 'TOTAL'], true)) {
676| $errors[] = 'Licença inválida. Use Sem afastamento ou Com afastamento total.';
677| }
678| if ($workLeave === 'NAO' && \in_array($injClass, ['LTI', 'LTI_FATALIDADE', 'LTI_INCAPACITANTE', 'FAT'], true)) {
679| $errors[] = 'LTI/FAT não é permitido quando a licença é Sem afastamento.';
680| }
681| if ($workLeave === 'TOTAL' && $injClass !== '' && !\in_array($injClass, ['LTI', 'LTI_FATALIDADE', 'LTI_INCAPACITANTE', 'FAT'], true)) {
682| $errors[] = 'Com afastamento total, a classificação deve ser FAT ou LTI — Afastamento.';
683| }
684| if ($workLeave === 'NAO' && $injClass !== '' && !\in_array($injClass, ['FAC', 'MTC', 'RWC'], true)) {
685| $errors[] = 'Sem afastamento, use apenas FAC, MTC ou RWC.';
686| }
687|
688| if ($hadInjury) {
689| if (isset($d['body_location_detail']) && $d['body_location_detail'] !== null && $d['body_location_detail'] !== '') {
690| if (!\is_string($d['body_location_detail'])) {
691| $errors[] = 'Detalhe da localização no corpo deve ser texto.';
692| } elseif (mb_strlen((string) $d['body_location_detail']) > 2000) {
693| $errors[] = 'Detalhe da localização no corpo: no máximo 2000 caracteres.';
694| }
695| }
696| /* hand_finger / foot_toe no nível details: legado (MAO/PE sem lado); preferir por body_parts[]. */
697| $allowedHandFlat = ['POLEGAR', 'INDICADOR', 'MEDIO', 'ANULAR', 'MINIMO'];
698| $allowedFootFlat = ['HALUX', 'SEGUNDO_DEDO', 'TERCEIRO_DEDO', 'QUARTO_DEDO', 'MINIMO_PE'];
699| if (!empty($d['hand_finger'])) {
700| foreach (array_filter(array_map('trim', explode(',', (string) $d['hand_finger']))) as $v) {
701| if (!\in_array($v, $allowedHandFlat, true)) {
702| $errors[] = 'Dedo da mão inválido: ' . $v;
703| }
704| }
705| }
706| if (!empty($d['foot_toe'])) {
707| foreach (array_filter(array_map('trim', explode(',', (string) $d['foot_toe']))) as $v) {
708| if (!\in_array($v, $allowedFootFlat, true)) {
709| $errors[] = 'Dedo do pé inválido: ' . $v;
710| }
711| }
712| }
713| }
714|
715| $descVal = array_key_exists('descaracterizado', $d) ? (string) $d['descaracterizado'] : '';
716| // Caracterizar é do médico no aprofundamento dedicado — não na criação.
717| // Sim/Não + comentário só são obrigatórios quando há suspeita de descaracterização marcada.
718| if (!empty($data['aprofundamento_only'])) {
719| $hasSuspect = !empty($d['descaracter_suspect']) && $d['descaracter_suspect'] !== '0';
720| if ($hasSuspect) {
721| if (!\in_array($descVal, ['0', '1'], true)) {
722| $errors[] = 'Informe se o evento é caracterizado como acidente (Sim/Não).';
723| } else {
724| $comment = trim((string) ($d['descaracter_comment'] ?? ''));
725| if ($comment === '') {
726| $errors[] = 'Comentário de caracterização do acidente é obrigatório.';
727| }
728| }
729| }
730| }
731|
732| return $errors;
733| }
734|
735| private function validateAcidenteMaterial(array $d): array
Request #64
deepseek-v4-flash
P:92.76K C:591 CR:89.73K CW:0
5801ms
Reasoning
This descaracter block (715-730) is inside validateAcidentePessoal presumably (body maps, injury classification). The signature of that function needs context to confirm. Anyway: For ROS/QA/AM/AA, there might not be equivalent validation of the new descaracter fields. But since these fields are being saved via the same `aprofundamento_only` payload on ROS/QA events, then the backend per-type validators for ROS/QA/AM/AA won't check "if suspect -> requires Sim/Não + comment", meaning the UI (Sim/Não/comment required red asterisk) could be bypassed for ROS/QA/AM/AA: user checks suspect but doesn't answer Sim/Não and still can finalize without error. But that's a *validation* issue of new feature logic. Hmm, is the comment mandatory? In the new block partial, label has red asterisk; the yes/no toggle: user can only check suspect then Sim/Não default? Let's examine if Sim/Não required (in the partial block, when check suspect, the yesno div is revealed; user may not click). `evApplyTypeDescaracterPayload` sets descaracterizado only when hidden already 0/1; else not set. If not set, backend for ROS won't flag error (only AP validator covers). So data integrity: an ROS/QA/AM/AA finalized aprofundamento with suspect=1, no caracterizado → details with incomplete info. But is that reachable? Only for users who have the Descaracterizar flag for that type. Since they can finalize, they'd be able to store inconsistent data. However this might be exactly the same bug category #4? No, #4 was cross-type contamination. This is "no backend validation for ROS/QA/AM/AA descaracter fields." Actually we must check whether the descaracter validation block (lines 715-730) is executed for all types in a shared method. Let me find the enclosing method and see which validators call validateDescaracter... There isn't a separate method; it's inline. Let me search for the method that starts before line ~500 containing these and the method name, and check if it's only for AP; also find ROS/QA/AM/AA validator functions and where the common descaracter block might be duplicated.
Let me find function names: search for 'function validate' in SsmaEventValidator.
Tool Calls (1)
code_search
Show Details
Arguments
{"search_text": "private function validate", "file_patterns": ["src/Service/Ssma/SsmaEventValidator.php"]}
Result
File: src/Service/Ssma/SsmaEventValidator.php Match lines: 11 190| private function validateBase(array $data, array $context = []): array 231| private function validateClassification(array $data, bool $requiresTechnicalDepth): array 351| private function validateDetails(string $type, array $details, array $data = []): array 368| private function validateRos(array $d): array 420| private function validateQuaseAcidente(array $d): array 467| private function validateAcidentePessoalEtapa1(array $d): array 530| private function validateAcidentePessoal(array $d, array $data = []): array 735| private function validateAcidenteMaterial(array $d): array 760| private function validateAcidenteAmbiental(array $d): array 793| private function validateSharedDetails(array $d, bool $requiresTechnicalDepth, string $type = ''): array 840| private function validatePotentialGteReal(array $data): array
Request #65
deepseek-v4-flash
P:93.59K C:2.22K CR:93.31K CW:0
18495ms
Reasoning
So the descaracter validation block is only inside `validateAcidentePessoal`. ROS/QA/AM/AA validators do not require descaracter fields. This is pre-existing backend (not changed in this diff). The change (new per-type UI) extends the UI fields to ROS/QA/AM/AA without backend validation changes in this diff. Given the feature adds fields into ROS/QA/AM/AA aprofundamento, but the only backend validation for the completion requires Sim/Não + comment for AP only. For ROS/QA/AM/AA, users who check "Há suspeita..." and don't answer Sim/Não can finalize successfully storing suspect=1 with missing caracterizado/comment. Whether intended? This suggests the backend needs updates in a future diff. However, since this diff didn't touch the validators or the allowlists, and because the "coluna Descaracterizar" gating means only flagged users get the UI for ROS/QA/AM/AA, this is a plausible NEW issue worth flagging: for the four new type blocks, UI says comment * required and Sim/Não required but no server-side validation ensures them. The task mentions integrity of data review. Might be a valid maintainability/functional bug (missing server-side required fields for new flow). I think it's a reasonable finding: "Campo obrigatório que depende do fluxo/tipo é validado no servidor, não só no JavaScript do modal." Controller rules: "Campo obrigatório que depende do fluxo/tipo é validado no servidor, não só no JavaScript do modal." So yes, worth noting.
But wait — is this validated elsewhere for ROS/QA/AM/AA? Not in validators. But maybe payload fields are allowed for those types only when aprofundamento_only flag and descaracter_suspect=1; the whitelist at SsmaController 26988 includes the three descaracter fields presumably when validating/approving. Also SsmaEventService merging only via injured card (AP). If details saved for ROS from new UI include descaracter fields, does the server permit storing them (allowlist)? Where does the details allowlist happen? SsmaController 26988 area is the list of allowed details keys on update? Let's quickly check to see if descaracter fields are in the general allowlist for ROS. Actually SsmaEventValidator and SsmaEventService handle details arrays; the allowed field list might be elsewhere. Let's check SsmaEventService applyPayload to see if it just takes whatever details keys. Let me search where 'details' whitelisting happens.
Given time, I'll do a targeted check: line 26988 context in controller, to see list includes 'descaracter_suspect' at top-level (meaning it's an allowed key when validating event). Also note the descaracter fields are top-level details keys. For ROS events, the backend likely stores whatever payload details. This likely does store them. So the concern about missing server validation for required Sim/Não/comment on new per-type blocks stands.
However, do we know that the descaracterized data for ROS/QA/AM/AA even semantically should be validated? Consider "quase acidente" (near miss). Descaracterizar a near miss does not make sense because it never was considered an accident. But the PR author deliberately put descaracterização in all types. Anyway.
I'm torn on whether this is truly valid to report or it's more of a product decision.
Let me look at the actual user task/PR title: "implement descharacterization flags by type for occurrences". The visual says: In the injured box for AP, previously only... Now they add per-type blocks. Wait, is this actually from a hotfix branch "permission-descaraterzacao-ssma"? The feature adds the ability for the config to control per-type whether the suspect checkbox shows (column Descaracterizar at the tag config UI).
The requirement originally for AP: "Suspeita editável por qualquer especialista AP; Sim/Não só quem tem permissão Descaracterizar." In the new design, all per-type UI including Suspect is gated by Descaracterizar column.
OK let me not report missing server validation, because the feature might be strictly gated by this new permission flag and the Sim/Não isn't mandatory unless flagged; but since comment shows '*' (required), still mismatch. Actually for suspects marked and descaracterizado missing, backend for ROS will not reject; but will the data integrity be compromised? It's plausible but speculative to determine severity. Given limited time, maybe report as low/medium "Atenção".
Let me re-check the validator for QA/ROS and AM/AA to make sure they don't call some shared descaracter validation. validateRos lines 368-419, validateQuaseAcidente 420-466, validateAcidenteMaterial 735-758, Ambiental 760-792. No descaracter checks. OK.
Now also important to reconsider the **`SsmaController` pass of `ssmaCanDescharacterizeAccident` and the JS `evCanDescharacterizeAccident()`** as used at AP payload line 7196 fallback; plus `evSyncDescaracterUi` line 2978. Since ssmaCanDescharacterizeAccident now only reflects the tag Descaracterizar membership, it no longer auto-true for SuperAdmin/Manager. As a consequence, in AP aprofundamento, the **Sim/Não** buttons become disabled for admin unless explicitly configured? Wait for admin role without member, ssmaCanDescharacterizeByType=[] → canDescharacterizeAccident false → in AP flow, "Não" disabled and default Sim preselected. Before, SuperAdmin auto-liberated. #1 covers.
OK.
Now, I want to verify another subtle: `$ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false` uses `?? false`, but service returns bool values. If key exists but false, `?? false` returns false. fine.
Now review whether all the JS per-type blocks get **synced** when the type changes. When user switches type within the same modal (create), each block root retains its previous state; save only applies the currently selected type's block. Confirmed #4 covers.
Given all confirmed findings already cover the biggest problems, I'd like to find NEW genuine issues to add to be thorough. Let me look for something in the JS logic more carefully:
In the type block click handler at 5793:
```
root.addEventListener('click', function (e) {
var btn = e.target && e.target.closest ? e.target.closest('.ev-type-desc-btn') : null;
if (!btn) return;
var hidden = document.getElementById('ev_descaracterizado');
if (hidden) hidden.value = btn.getAttribute('data-descaracter-val') || '';
if (window.SsmaShared && ...) {
window.SsmaShared.toggleYesNo(root.querySelectorAll('.ev-type-desc-btn'), hidden ? hidden.value : null, { valueAttr: 'data-descaracter-val' });
}
evPersistDraftSoon();
});
```
Now, in **read-only / disabled state** (aprofundamento readonly), `evSetAprofundamentoReadonly(true)` disables all inputs within the technical sections, including these `.ev-type-desc-btn` buttons (button disabled) - actually disabled buttons do not fire click events; fine.
Also, in readonly, the checkbox `.ev-type-descaracter-suspect` disabled; and CSS `pointer-events: none` applied to `.form-check-input`. OK.
Now the **suspect change handler** sets `globalChk.checked = chk.checked` but does not call `evSyncInjuredPersonDetailsHidden()` which the AP global suspect handler does (line 5776-5780). For AP card handler at 5807-5820 it calls evSyncInjuredPersonDetailsHidden(). For type roots it only calls `evPersistDraftSoon()`. The injured_person_details hidden JSON stores per-card descaracter_suspect via `evReadCardInjuryData` when cards are synced... but that sync happens on events (change of fields). The per-type root is outside injured card. Might not be an issue.
There is a real potential bug though: **changing the type root suspect does not update the per-card `.ev-inj-suspect-chk` when AP type** — but per-type roots are only rendered for ROS/QA/AM/AA (no AP root), so AP unaffected.
Now there's another one: The `change` listener on `.ev-type-descaracter-suspect` at 5786 updates `globalChk`.checked but not the **yesNo** `.ev-type-descaracter-yesno` classes of OTHER roots — fine since each root toggles its own yesNo on its own change. However restoring code (6548-6555) sets all roots at once; only one root's parent block is displayed.
Ok, enough. Let's consider the missing addition of these new fields into the whitelist at SsmaEventService `mergeInjuredCardIntoDetails`; that only handles AP cards.
Let me examine what happens server-side when saving ROS/QA/AM/AA **aprofundamento** with new descaracter fields. Look at SsmaController lines 26980-27110 and 27320-27360 to see whitelist for details keys (in updateEvent route and in status transitions). Since the SsmaEventService updateFromPayload takes details array keys in the payload, possibly no filtering. Let me check where the controller sanitizes which keys to persist; line 27084 loops over ['descaracter_suspect','descaracterizado','descaracter_comment'] for "details". It might be within specific code that pulls descaracter info from a special request field. Not crucial.
Let me read 26970-27110 quickly.
Tool Calls (1)
file_read
Show Details
Arguments
{"file_path": "src/Controller/SsmaController.php", "start_line": 26970, "end_line": 27110}
Result
File: src/Controller/SsmaController.php (Total lines: 27765)
IS_TRUNCATED: false
LINE_RANGE: 26970-27110
26970| *
26971| * @param array<string, mixed> $data
26972| *
26973| * @return array<string, mixed>
26974| */
26975| private function normalizeSsmaEventPayload(array $data, ?Company $company = null): array
26976| {
26977| $detailKeys = [
26978| 'activity', 'approach', 'responsible_ids',
26979| 'title', 'manager_id', 'people_ids', 'team_id', 'evidences',
26980| 'strategic_nature', 'area_label', 'potential_consequence',
26981| 'classifier_dano', 'classifier_risco', 'classifier_afetado',
26982| 'category',
26983| 'occurrence_time',
26984| 'deviation_type', 'involvement_type', 'potential_severity', 'immediate_risk',
26985| 'failed_barrier', 'failed_barrier_other', 'barrier_type',
26986| 'person_id', 'person_type', 'had_injury', 'injury_type', 'injury_severity', 'injury_classification',
26987| 'work_leave', 'fatal', 'immediate_cause', 'body_parts', 'body_location_detail', 'hand_finger', 'foot_toe',
26988| 'injured_person_details', 'descaracter_suspect', 'descaracterizado', 'descaracter_comment', 'witness_ids',
26989| 'asset_type', 'operational_impact', 'estimated_loss', 'downtime',
26990| 'environmental_medium', 'pollutant_type', 'estimated_volume',
26991| 'containment_done', 'containment_time', 'external_impact', 'affected_area',
26992| 'gmr',
26993| 'corrective_actions',
26994| 'improvement_suggestions',
26995| 'ros_resolved',
26996| 'ros_resolution_notes',
26997| 'ros_resolution_evidences',
26998| ];
26999|
27000| $details = isset($data['details']) && is_array($data['details']) ? $data['details'] : [];
27001|
27002| foreach ($detailKeys as $key) {
27003| if (array_key_exists($key, $data)) {
27004| $details[$key] = $data[$key];
27005| }
27006| }
27007|
27008| $footCodes = ['HALUX', 'SEGUNDO_DEDO', 'TERCEIRO_DEDO', 'QUARTO_DEDO', 'MINIMO_PE'];
27009| $hfRaw = isset($details['hand_finger']) ? trim((string) $details['hand_finger']) : '';
27010| $ftRaw = isset($details['foot_toe']) ? trim((string) $details['foot_toe']) : '';
27011| /* Swap antigo (single-value): mantêm compatibilidade apenas se não houver vírgula */
27012| if ($ftRaw === '' && $hfRaw !== '' && !str_contains($hfRaw, ',') && \in_array($hfRaw, $footCodes, true)) {
27013| $details['foot_toe'] = $hfRaw;
27014| $details['hand_finger'] = '';
27015| }
27016|
27017| $type = $data['type'] ?? '';
27018| $categoryLabel = trim((string) ($details['category'] ?? ''));
27019| if ($categoryLabel !== '') {
27020| $natureFromCategory = \App\Enum\Ssma\EventNatureEnum::resolveFromLabel($categoryLabel);
27021| if ($natureFromCategory !== null) {
27022| $data['nature'] = $natureFromCategory;
27023| }
27024| }
27025|
27026| if ($type === EventTypeEnum::ROS && isset($details['involvement_type'])) {
27027| $normalizedInv = RosInvolvementTypeEnum::normalizeLegacy((string) $details['involvement_type']);
27028| if (RosInvolvementTypeEnum::isValid($normalizedInv)) {
27029| $details['involvement_type'] = $normalizedInv;
27030| }
27031| }
27032|
27033| if (in_array($type, [\App\Enum\Ssma\EventTypeEnum::ROS, \App\Enum\Ssma\EventTypeEnum::QUASE_ACIDENTE], true)) {
27034| $n = $details['nature'] ?? '';
27035| if ($n === '' || !\App\Enum\Ssma\EventClassNatureEnum::isValid((string) $n)) {
27036| $approach = (string) ($details['approach'] ?? '');
27037| $details['nature'] = match ($approach) {
27038| 'MEDIACAO' => \App\Enum\Ssma\EventClassNatureEnum::ORGANIZACIONAL,
27039| 'TREINAMENTO', 'ACAO_DISCIPLINAR' => \App\Enum\Ssma\EventClassNatureEnum::COMPORTAMENTAL,
27040| 'MELHORIA_PROCESSO' => \App\Enum\Ssma\EventClassNatureEnum::TECNICA,
27041| default => \App\Enum\Ssma\EventClassNatureEnum::OPERACIONAL,
27042| };
27043| }
27044| }
27045|
27046| if ($type === EventTypeEnum::ACIDENTE_AMBIENTAL) {
27047| $em = (string) ($details['environmental_medium'] ?? '');
27048| if ($em === 'AGUA') {
27049| $details['environmental_medium'] = EnvironmentalMediumEnum::AGUA_SUPERFICIAL;
27050| } elseif ($em === 'MULTIPLO') {
27051| $details['environmental_medium'] = EnvironmentalMediumEnum::OUTRO;
27052| }
27053| }
27054|
27055| $sn = $details['strategic_nature'] ?? '';
27056| if ($sn === '' || $sn === null) {
27057| $details['strategic_nature'] = \App\Enum\Ssma\EventStrategicNatureEnum::PROCESSO;
27058| }
27059|
27060| if (isset($details['manager_id']) && $details['manager_id'] !== '' && $details['manager_id'] !== null) {
27061| $details['manager_id'] = (int) $details['manager_id'];
27062| }
27063|
27064| // Caixinhas do acidentado: form envia JSON string; persiste como objeto.
27065| if (isset($details['injured_person_details']) && is_string($details['injured_person_details'])) {
27066| $decodedInj = json_decode($details['injured_person_details'], true);
27067| $details['injured_person_details'] = is_array($decodedInj) ? $decodedInj : [];
27068| }
27069|
27070| $consequenceReal = strtoupper(trim((string) ($data['consequence'] ?? $details['consequence'] ?? '')));
27071| if ($consequenceReal === 'SEM_DANO') {
27072| $details['had_injury'] = 0;
27073| $details['injury_type'] = '';
27074| $details['injury_severity'] = '';
27075| } elseif (!empty($details['injured_person_details']) && is_array($details['injured_person_details'])) {
27076| $pid = isset($details['person_id']) ? (string) $details['person_id'] : '';
27077| if ($pid !== '' && isset($details['injured_person_details'][$pid]) && is_array($details['injured_person_details'][$pid])) {
27078| $card = $details['injured_person_details'][$pid];
27079| foreach (['injury_type', 'injury_severity', 'injury_classification', 'work_leave'] as $injKey) {
27080| if (empty($details[$injKey]) && !empty($card[$injKey])) {
27081| $details[$injKey] = $card[$injKey];
27082| }
27083| }
27084| foreach (['descaracter_suspect', 'descaracterizado', 'descaracter_comment'] as $descKey) {
27085| if ((!array_key_exists($descKey, $details) || $details[$descKey] === '' || $details[$descKey] === null)
27086| && array_key_exists($descKey, $card) && $card[$descKey] !== '' && $card[$descKey] !== null) {
27087| $details[$descKey] = $card[$descKey];
27088| }
27089| }
27090| if (!isset($details['had_injury']) && array_key_exists('had_injury', $card)) {
27091| $details['had_injury'] = !empty($card['had_injury']) ? 1 : 0;
27092| }
27093| }
27094| }
27095|
27096| if (isset($details['descaracter_suspect'])) {
27097| $details['descaracter_suspect'] = !empty($details['descaracter_suspect']) && $details['descaracter_suspect'] !== '0' ? 1 : 0;
27098| }
27099| if (array_key_exists('descaracterizado', $details) && $details['descaracterizado'] !== null && $details['descaracterizado'] !== '') {
27100| $details['descaracterizado'] = in_array((string) $details['descaracterizado'], ['1', 'true'], true) ? '1' : '0';
27101| }
27102|
27103| // Paridade Adriana: horário explícito ou extraído do datetime do modal manual.
27104| $occurrenceTime = trim((string) ($details['occurrence_time'] ?? $data['occurrence_time'] ?? $data['occurrenceTime'] ?? ''));
27105| if ($occurrenceTime === '' && !empty($data['datetime'])) {
27106| try {
27107| $occurrenceTime = (new \DateTime((string) $data['datetime']))->format('H:i');
27108| } catch (\Throwable) {
27109| $occurrenceTime = '';
27110| }
Request #66
deepseek-v4-flash
P:98.3K C:526 CR:95.74K CW:0
5103ms
Reasoning
So details allowlist includes the descaracter fields for ALL types; and backend normalizes/validates per type. For ROS/QA/AM/AA there is no server validation requiring Sim/Não when suspect, but there's no *server-side authorization* validation either that user has the descaracterization permission for the type when saving descaracter fields!
This is a big NEW security/authorization candidate: The per-type permission is used only to render the UI (hide/show). But server-side, when saving an aprofundamento with `descaracter_suspect=1` and `descaracterizado='1'` for ROS, does the backend verify the logged user has the tag column Descaracterizar for ROS? If not, any aprofundamento editor (who has technical tag ROS but NOT the Descaracterizar column) could forge the fields and set "descaracterizado" via crafted request, bypassing the permission. The old AP flow had backend validation? Let's check if there's backend authorization check that the user may set descaracterizado for AP. SsmaEventValidator might enforce `can descharacterize` for AP `descaracterizado=1`? Let's look for authorization checks. Let's check for the phrase 'descaracteriz' authorization on save routes. The save probably occurs in SsmaEventService.updateFromPayload and controller. In controller there may be an authorization gate: "Só quem tem permissão de descaracterizar pode marcar não" — search SsmaController for 'Descaracterizar' or 'descaracterizado'.
Given time constraints, but a strong security candidate if absent, let me search.
Tool Calls (2)
code_search
Show Details
Arguments
{"search_text": "descaracterizado", "file_patterns": ["src/Service/Ssma/SsmaEventValidator.php", "src/Service/Ssma/SsmaEventService.php", "src/Service/Ssma/SsmaAutomationService.php"]}
Result
File: src/Service/Ssma/SsmaAutomationService.php
Match lines: 5
648| $desc = (string) ($payload['descaracterizado'] ?? '');
652| if (in_array('descaracterizado_sim', $selected, true) && $desc !== '1') {
655| if (in_array('descaracterizado_nao', $selected, true) && $desc !== '0') {
2031| $payload['descaracterizado'] = array_key_exists('descaracterizado', $details)
2032| ? (string) $details['descaracterizado']
File: src/Service/Ssma/SsmaEventService.php
Match lines: 1
161| 'descaracter_suspect', 'descaracterizado', 'descaracter_comment',
File: src/Service/Ssma/SsmaEventValidator.php
Match lines: 2
183| $desc = array_key_exists('descaracterizado', $d) ? (string) $d['descaracterizado'] : '';
715| $descVal = array_key_exists('descaracterizado', $d) ? (string) $d['descaracterizado'] : '';
code_search
Show Details
Arguments
{"search_text": "CanDescharacterize|canDescharacterize|memberCanDescharacterize", "file_patterns": ["src/"]}
Result
No matches found
Request #67
deepseek-v4-flash
P:99.12K C:119 CR:98.82K CW:0
2040ms
Reasoning
Let me check SsmaEventValidator lines 160-190 to see the descaracter check there (maybe it validates permission with context).
Tool Calls (1)
file_read
Show Details
Arguments
{"file_path": "src/Service/Ssma/SsmaEventValidator.php", "start_line": 150, "end_line": 240}
Result
File: src/Service/Ssma/SsmaEventValidator.php (Total lines: 887)
IS_TRUNCATED: false
LINE_RANGE: 150-240
150| EventTypeEnum::ACIDENTE_PESSOAL,
151| EventTypeEnum::ACIDENTE_MATERIAL,
152| EventTypeEnum::ACIDENTE_AMBIENTAL,
153| ], true);
154| }
155|
156| /**
157| * @param array<string, mixed> $data
158| * @param array<string, mixed> $d
159| */
160| private function hasAccidentAprofundamentoFields(array $data, array $d): bool
161| {
162| // NÃO usar approach/strategic_nature aqui: o formulário manda approach com default
163| // na 1ª etapa e isso não significa que o usuário entrou no Aprofundamento.
164| if (trim((string) ($data['consequence'] ?? '')) !== '') {
165| return true;
166| }
167|
168| foreach ([
169| 'potential_consequence',
170| 'potential_severity',
171| 'injury_type',
172| 'injury_classification',
173| 'asset_type',
174| // Meio/poluente ficam na Identificação (Ambiental) — não disparam aprofundamento.
175| 'failed_barrier',
176| 'barrier_type',
177| ] as $key) {
178| if (trim((string) ($d[$key] ?? '')) !== '') {
179| return true;
180| }
181| }
182|
183| $desc = array_key_exists('descaracterizado', $d) ? (string) $d['descaracterizado'] : '';
184|
185| return \in_array($desc, ['0', '1'], true);
186| }
187|
188| // ── Base ──────────────────────────────────────────────────────────────────
189|
190| private function validateBase(array $data, array $context = []): array
191| {
192| $errors = [];
193|
194| $type = $data['type'] ?? '';
195| $allowed = $context['allowed_type_keys'] ?? null;
196| if ($allowed === null) {
197| if (empty($type) || !EventTypeEnum::isValid((string) $type)) {
198| $errors[] = 'type: obrigatório e deve ser um dos valores válidos (' . implode(', ', EventTypeEnum::values()) . ').';
199| }
200| } else {
201| if (empty($type) || !in_array((string) $type, $allowed, true)) {
202| $errors[] = 'type: obrigatório ou não está habilitado para esta empresa.';
203| }
204| }
205|
206| if (!empty($data['origin']) && !EventOriginEnum::isValid($data['origin'])) {
207| $errors[] = 'origin: valor inválido.';
208| }
209|
210| if (empty($data['datetime'])) {
211| $errors[] = 'datetime: obrigatório.';
212| } elseif (!\DateTime::createFromFormat('Y-m-d\TH:i:s', $data['datetime'])
213| && !\DateTime::createFromFormat('Y-m-d H:i:s', $data['datetime'])
214| && !\DateTime::createFromFormat('Y-m-d\TH:i', $data['datetime'])) {
215| $errors[] = 'datetime: formato inválido. Use ISO 8601 (ex.: 2026-04-07T10:30:00).';
216| }
217|
218| if (empty($data['location']) || trim((string) $data['location']) === '') {
219| $errors[] = 'location: obrigatório.';
220| }
221|
222| if (empty($data['description']) || trim((string) $data['description']) === '') {
223| $errors[] = 'description: obrigatório.';
224| }
225|
226| return $errors;
227| }
228|
229| // ── Classificação técnica ─────────────────────────────────────────────────
230|
231| private function validateClassification(array $data, bool $requiresTechnicalDepth): array
232| {
233| $errors = [];
234| $type = (string) ($data['type'] ?? '');
235| // Natureza foi unificada com Categoria — campo não é mais obrigatório no formulário.
236| if (!empty($data['nature']) && !EventNatureEnum::isValid($data['nature'])) {
237| $errors[] = 'nature: valor inválido.';
238| }
239|
240| if (!empty($data['agent']) && !EventAgentEnum::isValid($data['agent'])) {
Request #68
deepseek-v4-flash
P:100.36K C:364 CR:99.2K CW:0
4098ms
Reasoning
There's no server-side check tying "descaracterizado" to a permission at the point of saving. Was that previously enforced anywhere? Given the old AP gate: "Sim/Não só quem tem permissão Descaracterizar". If previously the server didn't enforce it either, then it wasn't a regression — but previously the AP UI disabled the Não button for users without permission (client-side). Where did the server rely? Possibly automation triggers alert, but data integrity not verified server-side before, i.e., pre-existing condition.
BUT now the new per-type flags are computed server side and passed to the template; the UI hides everything for unauthorized users. This diff's purpose is specifically about enforcing the per-type permission. Since the template is gated client-side only (hiding controls), the actual authorization enforcement would require server-side check on save; whether that existed for the AP is questionable; but the diff didn't add it for the new types. That may be considered a valid review point under "Authorization enforced only in a client/template/hidden control rather than at the server-side operation". We should double check whether the endpoint that saves aprofundamento validates that the current user has the "descaracterizar" permission for the type being saved. Let me search in the save route for canEditAprofundamento and permission checks. Search `descaracter` in controller around the event save/update route.
Tool Calls (1)
code_search
Show Details
Arguments
{"search_text": "descaracter", "file_patterns": ["src/Controller/SsmaController.php"]}
Result
File: src/Controller/SsmaController.php
Match lines: 35
10194| * S/N de descaracterização: liberado automaticamente para Gestor Administrador/Tenant
14433| 'descaracter_suspect' => !empty($details['descaracter_suspect']) ? 1 : 0,
14434| 'descaracterizado' => array_key_exists('descaracterizado', $details) ? (string) $details['descaracterizado'] : '',
24252| * POST /manager/ssma/config/aprofundamento/descaracter
24253| * Persiste flag "pode descaracterizar acidente" por membro do grupo (team ou tag).
24255| public function aprofundamentoSalvarDescaracter(Request $request): JsonResponse
24295| $this->ssmaOccurrenceTypeConfig->setAprofundamentoDescaracterMember(
24355| $descaracterIds = $this->ssmaOccurrenceTypeConfig->getAprofundamentoDescaracterMemberIds($company, 'team', $teamId);
24356| $descaracterSet = array_fill_keys($descaracterIds, true);
24379| 'can_descharacterize' => isset($descaracterSet[$m->getId()]),
24503| $descaracterIds = $this->ssmaOccurrenceTypeConfig->getAprofundamentoDescaracterMemberIds($company, 'tag', $tagId);
24504| $descaracterSet = array_fill_keys($descaracterIds, true);
24521| 'can_descharacterize' => isset($descaracterSet[$m->getId()]),
25312| $data = $this->applySsmaDescaracterPermissionGate($data, $company, $user);
25527| $data = $this->applySsmaDescaracterPermissionGate(
26988| 'injured_person_details', 'descaracter_suspect', 'descaracterizado', 'descaracter_comment', 'witness_ids',
27084| foreach (['descaracter_suspect', 'descaracterizado', 'descaracter_comment'] as $descKey) {
27096| if (isset($details['descaracter_suspect'])) {
27097| $details['descaracter_suspect'] = !empty($details['descaracter_suspect']) && $details['descaracter_suspect'] !== '0' ? 1 : 0;
27099| if (array_key_exists('descaracterizado', $details) && $details['descaracterizado'] !== null && $details['descaracterizado'] !== '') {
27100| $details['descaracterizado'] = in_array((string) $details['descaracterizado'], ['1', 'true'], true) ? '1' : '0';
27330| 'descaracterizado',
27331| 'descaracter_comment',
27332| 'descaracter_suspect',
27401| * S/N de descaracterização só pode ser gravado por membro com flag na coluna Descaracterizar.
27408| private function applySsmaDescaracterPermissionGate(
27421| if ($existingDetails !== null && array_key_exists('descaracterizado', $existingDetails)
27422| && \in_array((string) $existingDetails['descaracterizado'], ['0', '1'], true)) {
27424| $details['descaracterizado'] = (string) $existingDetails['descaracterizado'];
27425| } elseif (isset($data['details']['descaracterizado'])
27426| && \in_array((string) $data['details']['descaracterizado'], ['0', '1'], true)) {
27428| $details['descaracterizado'] = (string) $data['details']['descaracterizado'];
27431| // Quem não pode descaracterizar nunca poderia marcar "Não" de qualquer forma.
27432| $details['descaracterizado'] = '0';
27434| unset($data['descaracterizado']);
Request #69
deepseek-v4-flash
P:101.67K C:382 CR:100.61K CW:0
3483ms
Reasoning
There's already a server-side gate `applySsmaDescaracterPermissionGate` that forces descaracterizado='0' for those who can't descaracterize. Let me read that method 27401-27460 to understand its semantics, especially for which roles/members it allows, and whether it handles the new per-type scenario (it likely uses old memberCanDescharacterizeAccident full-config method, not the per-type). And where is it applied? Lines 25312 and 25527 in POST endpoints. This is important to evaluate new authorization gap.
Let me read lines 27401-27460 and the surrounding usage 25300-25320, 25515-25535.
Tool Calls (3)
file_read
Show Details
Arguments
{"file_path": "src/Controller/SsmaController.php", "start_line": 27400, "end_line": 27480}
Result
File: src/Controller/SsmaController.php (Total lines: 27765)
IS_TRUNCATED: false
LINE_RANGE: 27400-27480
27400| /**
27401| * S/N de descaracterização só pode ser gravado por membro com flag na coluna Descaracterizar.
27402| *
27403| * @param array<string, mixed> $data
27404| * @param array<string, mixed>|null $existingDetails details já persistidos (update)
27405| *
27406| * @return array<string, mixed>
27407| */
27408| private function applySsmaDescaracterPermissionGate(
27409| array $data,
27410| Company $company,
27411| $user,
27412| ?array $existingDetails = null
27413| ): array {
27414| $member = $this->getCurrentCompanyMember($company, $user);
27415| $can = $this->ssmaMemberCanDescharacterizeAccident($company, $member);
27416| if ($can) {
27417| return $data;
27418| }
27419|
27420| $details = isset($data['details']) && is_array($data['details']) ? $data['details'] : [];
27421| if ($existingDetails !== null && array_key_exists('descaracterizado', $existingDetails)
27422| && \in_array((string) $existingDetails['descaracterizado'], ['0', '1'], true)) {
27423| // Mantém o valor já salvo anteriormente.
27424| $details['descaracterizado'] = (string) $existingDetails['descaracterizado'];
27425| } elseif (isset($data['details']['descaracterizado'])
27426| && \in_array((string) $data['details']['descaracterizado'], ['0', '1'], true)) {
27427| // Aceita o valor enviado pelo frontend se for válido.
27428| $details['descaracterizado'] = (string) $data['details']['descaracterizado'];
27429| } else {
27430| // Sem valor anterior e sem permissão: default "Sim" (é acidente = '0').
27431| // Quem não pode descaracterizar nunca poderia marcar "Não" de qualquer forma.
27432| $details['descaracterizado'] = '0';
27433| }
27434| unset($data['descaracterizado']);
27435| $data['details'] = $details;
27436|
27437| return $data;
27438| }
27439|
27440| /**
27441| * Resolve manager_id a partir de manager_name quando o front/LLM só enviou o nome.
27442| *
27443| * @param array<string, mixed> $data
27444| *
27445| * @return array<string, mixed>
27446| */
27447| private function normalizeSsmaEventManagerInDetails(array $data, Company $company): array
27448| {
27449| $details = $data['details'] ?? [];
27450| if (!is_array($details)) {
27451| return $data;
27452| }
27453|
27454| $rawId = $details['manager_id'] ?? null;
27455| if ($rawId !== null && $rawId !== '') {
27456| $details['manager_id'] = (int) $rawId;
27457| $data['details'] = $details;
27458|
27459| return $data;
27460| }
27461|
27462| $name = trim((string) ($details['manager_name'] ?? ''));
27463| if ($name === '') {
27464| return $data;
27465| }
27466|
27467| $membersById = [];
27468| $members = $this->entityManager->getRepository(CompanyMembers::class)
27469| ->findBy(['company' => $company, 'isRemoved' => 0]);
27470| foreach ($members as $cm) {
27471| if (!$cm instanceof CompanyMembers) {
27472| continue;
27473| }
27474| $memberId = (int) $cm->getId();
27475| if ($memberId <= 0) {
27476| continue;
27477| }
27478| $label = $this->ssmaMemberDisplayLabel($cm);
27479| if ($label === '') {
27480| $label = (string) ($cm->getEmail() ?? '');
file_read
Show Details
Arguments
{"file_path": "src/Controller/SsmaController.php", "start_line": 25290, "end_line": 25325}
Result
File: src/Controller/SsmaController.php (Total lines: 27765)
IS_TRUNCATED: false
LINE_RANGE: 25290-25325
25290|
25291| // =========================================================================
25292| // EVENTOS SSMA (SSMAEvent tipado)
25293| // =========================================================================
25294|
25295| /**
25296| * POST /manager/ssma/events
25297| * Cria um novo evento SSMA tipado.
25298| */
25299| public function createEvent(Request $request): JsonResponse
25300| {
25301| /** @var \App\Entity\User|null $user */
25302| $user = $this->getUser();
25303| $company = $user?->getCompany();
25304| if (!$user || !$company) {
25305| return new JsonResponse(['success' => false, 'message' => 'Não autenticado.'], 401);
25306| }
25307|
25308| $data = json_decode($request->getContent(), true) ?? [];
25309| $data = $this->normalizeSsmaEventPayload($data, $company);
25310| $data = $this->normalizeSsmaEventManagerInDetails($data, $company);
25311| $data = $this->forceSsmaRosReporterForPlainMember($data, $company, $user);
25312| $data = $this->applySsmaDescaracterPermissionGate($data, $company, $user);
25313| $data = $this->ensureSsmaEventTitle($data);
25314|
25315| $validator = new \App\Service\Ssma\SsmaEventValidator();
25316| $errors = $validator->validate($data, [
25317| 'allowed_type_keys' => $this->ssmaOccurrenceTypeConfig->getAllowedTypeKeys($company),
25318| ]);
25319| if ($errors !== []) {
25320| return new JsonResponse([
25321| 'success' => false,
25322| 'message' => implode(' ', $errors),
25323| 'errors' => $errors,
25324| ], 422);
25325| }
file_read
Show Details
Arguments
{"file_path": "src/Controller/SsmaController.php", "start_line": 25505, "end_line": 25540}
Result
File: src/Controller/SsmaController.php (Total lines: 27765)
IS_TRUNCATED: false
LINE_RANGE: 25505-25540
25505| }
25506| if ($aprofundamentoFinalized && !$this->isSsmaAprofundamentoAdmin($company, $user)) {
25507| return new JsonResponse(['success' => false, 'message' => 'Aprofundamento finalizado. Somente um administrador ou gestor administrador pode alterar.'], 403);
25508| }
25509| $data = $this->mergeSsmaEventAprofundamentoOnlyPayload($event, $data);
25510| } else {
25511| $data = array_merge($this->eventToValidationArray($event), $data);
25512| if ($aprofundamentoFinalized && !$this->isSsmaAprofundamentoAdmin($company, $user)) {
25513| if ($aprofundamentoOnly || $isAprofundamentoUpdate) {
25514| return new JsonResponse(['success' => false, 'message' => 'Aprofundamento finalizado. Somente um administrador ou gestor administrador pode alterar.'], 403);
25515| }
25516| $data = $this->stripSsmaEventAprofundamentoFieldsFromPayload(
25517| $data,
25518| (string) ($data['type'] ?? $event->getType()),
25519| $existingDetails
25520| );
25521| }
25522| }
25523|
25524| $data = $this->normalizeSsmaEventPayload($data, $company);
25525| $data = $this->normalizeSsmaEventManagerInDetails($data, $company);
25526| $data = $this->forceSsmaRosReporterForPlainMember($data, $company, $user);
25527| $data = $this->applySsmaDescaracterPermissionGate(
25528| $data,
25529| $company,
25530| $user,
25531| $existingDetails
25532| );
25533|
25534| $eventType = (string) ($data['type'] ?? $event->getType());
25535| $eventDetails = is_array($data['details'] ?? null) ? $data['details'] : [];
25536| // Em modo só-aprofundamento o especialista já está autorizado; não stripa o que acabou de enviar.
25537| if (
25538| !$aprofundamentoOnly
25539| && !$this->canAccessSsmaEventAprofundamento($company, $user, $eventType, $eventDetails, $event->getCreatedById())
25540| && in_array($eventType, ['ROS', 'QUASE_ACIDENTE', 'ACIDENTE_PESSOAL', 'ACIDENTE_MATERIAL', 'ACIDENTE_AMBIENTAL'], true)
Request #70
deepseek-v4-flash
P:104.32K C:10.81K CR:102.02K CW:0
86850ms
Reasoning
Now this is very important. Look at `applySsmaDescaracterPermissionGate` (unchanged in this diff), which uses `ssmaMemberCanDescharacterizeAccident` — the OLD method that includes auto-liberation for ROLE_SUPER_ADMIN/ROLE_MANAGER/Gestor Admin AND any group (tag/team) across all types. So server-side gate allows a user who has Descaracterizar flag for ANY type (e.g., ROS only) to save `descaracterizado='1'` on an **AP** event too, because `ssmaMemberCanDescharacterizeAccident` is type-agnostic and aggregates all groups. Conversely the UI now only shows AP descaracter UI if the AP tag column is marked (findBy occurrenceTypeKey='ACIDENTE_PESSOAL'). So UI and server gate are inconsistent:
- UI hides AP block unless AP tag column is checked.
- But the server still lets any user with Descaracterizar on any group mark Não on AP (they could craft request).
Also new per-type UI for ROS/QA/AM/AA uses the per-type flags but server gate for those types uses old aggregate + super admin auto. For ROS/QA/AM/AA users flagged on AP only... they'd be authorized server-side on ROS/QA/AM/AA even though UI is hidden. Inconsistency, not a security hole (permission over-broad server side). Not new issue since server gate unchanged; only new because UI changed. Possibly a medium "discrepancy" note, but might be beyond diff scope since server-side file not changed.
Hmm; but the gate does not implement the per-type granularity, which is exactly what the feature wants to enforce. Since the diff's goal is "per-type flags", failing to update the server gate to be type-aware means the security model claimed by the UI isn't actually enforced server-side: A user flagged only for QUASE_ACIDENTE can still POST descaracterizado=1 for an ACIDENTE_PESSOAL etc. This is a real gap in the changed feature (a "new" issue on the feature, though the specific lines changed are in templates/service). Because we can only comment on files in review_files, and the finding needs to reference lines added in the diff. Best location: the template gating in `_ev_injured_person_box` or service `memberCanDescharacterizeForType`, or controller `ssmaCanDescharacterizeByType`. But the issue is the server gate remains old full-map. Given confirmed #1, #2 point into the same area (removed old aggregation, type-agnostic old function), but specifically they discussed UI flag regression and team-link config ignoring. The server gate inconsistency is somewhat the reverse side (server accepts more than UI shows). Might add as a finding: server-side gate (`applySsmaDescaracterPermissionGate`) is still type-agnostic and auto-liberates admin/manager; with this PR per-type flags become the source in the UI while the API gate remains old; hence enforcement mismatch. But wait, confirmed #1 says: "a flag de descaracterização passou a ser derivada apenas do novo mapa por tipo... abandonando os casos que o helper antigo `ssmaMemberCanDescharacterizeAccident` liberava automaticamente: ROLE_SUPER_ADMIN/ROLE_MANAGER, tag Gestor Administrador e config por equipe. Na prática,..." So they already point to mismatch between old helper and new per-type flags.
But there's still the server-gate authorization aspect for per-type enforcement. Since the PR is about per-type permission UI, and the corresponding server enforcement isn't type-aware, that's arguably the most critical security-ish concern. Actually, wait—is that a regression introduced by this diff? Before this diff: UI = AP-only; server gate = type-agnostic. If a user had a Descaracterizar flag for ROS but not AP, then before they could still mark Não on AP events (server allowed; UI? The AP UI Sim/Não gating used ssmaCanDescharacterizeAccident derived from old aggregate memberCanDescharacterizeAccident (any group), so the UI would show Sim/Não enabled as well). So before, the UI and server were both type-agnostic consistent. After this diff, UI became per-type (ROS flag does not enable AP UI), but server remains type-agnostic — creating a new inconsistency where the UI disallows what server still allows. That's a real introduced inconsistency (though it errs on restrictive UI + over-permissive server). The impact: an AP user who previously could mark descaracterizar Não (because they had a flag in some group) now loses that UI capability unless AP tag flagged, while the server still would accept a crafted value. The user-visible consequence: regression for users flagged on any group (not AP-specific), same as #1-3 in practice, since UI is the blocker.
I think adding a distinct comment about the server-side gate not being updated to per-type is fair but risks duplication of #1/#2. I'll lean to skip duplicates.
Let me now look at the two remaining review files I haven't thoroughly reviewed for issues: `SsmaController.php` only one small diff hunk — confirmed #1. `SsmaOccurrenceTypeConfigService` new methods — confirmed #2.
New potential specific bug in `SsmaOccurrenceTypeConfigService::memberCanDescharacterizeForType`: docblock says "tag de aprofundamento daquele tipo (ex.: tag 23 = QUASE_ACIDENTE)". The implementation checks `findBy(['company', 'occurrenceTypeKey'])` returning tags. For each tag, we check memberIds in config keyed 'tag:{tagId}'. Good. But there's a subtle: old `memberCanDescharacterizeAccident` also counted the config's keys for tag groups even if the tag no longer exists or even if the tag isn't one of the fixed technical tags (e.g., arbitrary custom tag with members configured with Descaracterizar column). The new per-type restrict only to fixed technical tags per occurrenceTypeKey. Covered #2 semantics.
Now examine a NEW potential issue in the service: it introduces SsmaPermissionTagRepository constant usage with import of SsmaPermissionTagRepository and SsmaPermissionTag entity (lines added imports). Note it uses `SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS`. Fine.
One more nuance: **the new per-type flag computation is executed twice?** In the controller only once. But it calls the service for every occurrence listing SSR and view. Minor perf. I'll possibly mention performance N+1 as low.
Actually, more precise: getDescharacterizeFlagsByType for each of 5 typeKeys → each does a `findBy` plus `getAprofundamentoDescaracterMemberIds` which itself calls `findOrCreateEntity` and reads JSON config → Each call reads entity separately (same entity found in identity map after first load so only 1 query). So effectively 1 config query + 5 tag queries = 6 queries per page render, plus possibly creation side effect. Previously controller called `ssmaMemberCanDescharacterizeAccident` which called `memberCanDescharacterizeAccident` (1 config query). That's +5 queries per page on a very frequently loaded module page (occurrence hub + every detail view). Could be worth a performance "Atenção" note: compute once by loading all tags for company in a single query. It's modest but legitimate.
But wait: is this a hot path? The index view is loaded by every user opening the SSMA occurrence hub. 5 extra queries each page. Considering this entire controller already does dozens of queries, the marginal +5 might be considered minor. I'd rate low. Since the review instructs performance only with evidence of meaningful scale or hot path, mention as low/attention.
Let me also look carefully at the `_modal_event.html.twig` hunk around 6545 restore for the new type roots. Potential NEW bug: When restoring an AP event (type ACIDENTE_PESSOAL), the restore sets per-type roots all with `suspectOn` from `det.descaracter_suspect`. But these roots are for ROS/QA/AM/AA, not AP. No harm.
But when restoring an existing ROS event in **view-only** mode (readonly), the restore code at 6548 runs? This happens only in populate for edit. The readonly applied after data load in openAprofundamento flow. Both fine.
Another subtle new bug: In the type root change event (line 5786-5790), when user un-checks the suspect, only globalChk is cleared; the **yesNo** hidden gets toggled. If previously they had selected "Não" in the descaracter yes/no section, then they uncheck suspect and then re-check suspect, the yes/no section returns; but the hidden `ev_descaracterizado` still holds previous '1'. If they then save without clicking again, descaracterizado='1' with suspect=1 again → consistent-ish. Fine.
If they uncheck suspect but hidden still has '1', the payload sets descaracter_suspect=0; `evApplyTypeDescaracterPayload` only adds `descaracterizado` if hidden is 0/1 — so it'd still send descaracterizado='1' with descaracter_suspect=0! That would persist caracterizado=1 (não é acidente) without a suspect flag. For AP it's fine since payload handles via descAnswered etc. For ROS/QA/AM/AA: If user marks suspect, answers Não (hidden 1), then unchecks suspect, then saves → descaracter_suspect 0 but descaracterizado '1' persists → an event with "descaracterizado=1" but no suspicion. Data inconsistency. Because there's no clearing of hidden on uncheck. The severity is modest, and it's within the same design as #4 (reuse global hidden without clearing). Actually the change listener should clear hidden value and button active states when unchecked. This is a NEW distinct bug: unchecking suspect leaves stale `descaracterizado` and no reset of active buttons; on save those stale values still sent. Might be worth adding as a medium finding.
Wait, for AP they do have `evSyncDescaracterUi` and `evSyncDescaracterStageUi`. Does unchecking per-card suspect clear data-descaracterizado? Not necessarily. But in AP flow `descAnswered && evAprofundamentoOnlyMode` determines whether to include descaracterizado. descFromCard from card attr; card set data-descaracter-suspect 0/1 but descaracterizado remains. When suspect unchecked, if descFromCard still present '1' then payload includes descaracterizado '1' even with no suspect... Actually there's logic maybe elsewhere that hides yes/no when not suspect; but payload doesn't check suspectOn vs desc. Not new behavior.
For ROS/QA/AM/AA, though, this is newly introduced logic. When user unchecks suspect, the descaracterizado hidden isn't cleared; but since ROS/QA/AM/AA payload includes descaracterizado unconditionally whenever hidden = 0/1, stale value could persist. Also in a full "finalizar" save, if suspect unchecked and no stale value, then payload has no descaracterizado and no comment; fine.
Given #4 already covers cross-type stale state of the same hidden field, this is adjacent but a distinct trigger (unchecking suspect). I'd consider it part of the design concern: the Sim/Não stored globally is not cleared when suspect toggled off. Since #4's main point is that a global hidden is reused across types/blocks without proper clearing, the stale-clearing issue might be duplicative enough to avoid.
I need to decide the final set of new comments. The confirmed findings are probably the main ones; our job: continue reviewing for other real issues.
Let me reconsider template partial - `_ev_descaracter_suspect_block.html.twig` new file, plus it's used in index.html.twig and occurrence_view (indirect). Wait, the four includes are in `_modal_event.html.twig`. It's rendered for every page that opens the modal (even for users without permission: the include renders empty markup `{% if ... %}`). Good.
But here's another NEW issue worth mentioning: In **occurrence_view.html.twig** and index, the modal includes the descaracter blocks. But if the user lacks any of the flags (array empty), the blocks never render, meaning when a ROS event whose details already has `descaracter_suspect=1` is displayed in aprofundamento readonly mode, no Suspect info is visible anywhere. Previously the suspect state was shown on the occurrence listing detail? The AP red alert in tabs? Actually, when user opens event to view its aprofundamento info, previously the suspect checkbox would appear per-card for AP specialists regardless of the column; now hidden for non-flagged AP user — that's confirmed #3 with AP injured box.
For ROS/QA/AM/AA with stored descaracter data (new fields) but current user without Descaracterizar column → data invisible. It's a new hidden data problem but only after someone previously flagged saved data and later the permission got revoked or a different viewer opens it. Data hidden, not destroyed; that's a UX concern for read-only viewing by users who do not have the flag. Given the requirement comment originally stated "sim/não só quem tem permissão; suspeita por qualquer especialista AP". Not clear.
OK, at this point I should also read the remaining un-visited hunks in _modal_event at 6545 added lines again and 6548; already read.
Let me check whether the added per-type roots `.ev-type-descaracter` are properly hidden when suspect unchecked but appear within AP readonly in the view mode? not.
Let me look at possible duplicated execution of binding when modal open repeated (init code at 5782 runs once on DOMContentLoaded). The roots exist at DOMContentLoaded? Yes because the modal markup is inline in the page. Binding each root once. Fine. However, when the DOM is loaded before the includes? It is static markup.
One thing: These handlers are added inside what appears to be an init function that might run multiple times (e.g., function called on DOMContentLoaded and also maybe on modal open). If the init is invoked twice, the change listeners on `.ev-type-descaracter-suspect` would double-fire (e.g., globalChk.checked set toggling?). Re-checking would not toggle since checking same value → but listeners would fire evPersistDraftSoon twice — harmless. Need to check whether the enclosing block is a one-time initialization function executed on DOMContentLoaded only. Let's find the function containing 5782. Look upward for function definition ~ line 5600-5782.
Actually, wait: if the init executes multiple times, each root gets 2 listeners; clicking the suspect checkbox would fire twice: each sets globalChk.checked = chk.checked (same), evPersistDraftSoon twice. Not harmful. So no.
Let me check whether there's a possibility that these roots are re-created after AJAX reloading of the modal content (if modal content is re-rendered). If modal gets loaded dynamically when offcanvas opens via `load`, the init bind at 5782 wouldn't rerun after new DOM... unless init function runs when `ev:formLoaded` etc. Actually, the binding code at 5782-5805 is located in the same script with the modal loaded inline in the page (the markup inside the file is inline in the parent template, not loaded dynamically). Offcanvas content loaded from within the same DOM.
OK.
Now I'll consider whether to add these additional comments:
New comment candidate 1 (performance, low/medium): In `SsmaOccurrenceTypeConfigService::getDescharacterizeFlagsByType`, repeated per-key queries (5 findBy + up to 5 config loads) for a single read of flags used in the controller on every listing/detail page; batch load tags once (findBy company) and reuse config map; also mention potential DB write (config entity creation) on GET. Maybe low severity, "Atenção".
New comment candidate 2 (data/consistency, medium): The controller map is not recomputed on the AJAX/Auth changes... skip.
New comment candidate 3 (correctness of sim/não requirement server side for ROS/QA/AM/AA): The newly added descaracterização per type (ROS/QA/AM/AA) writes `descaracter_suspect/descaracterizado/descaracter_comment` through the same payload keys, but backend validation (`validateRos/validateQuaseAcidente/validateAcidenteMaterial/validateAcidenteAmbiental`) doesn't enforce that suspect with Sim/Não + comment, and the authorization gate remains AP-typed/all-type-agnostic (memberCanDescharacterizeAccident). Result: data for those new type blocks is not protected server-side, and values can be sent for types the user isn't flagged for (if they edit via API or older UI). Since this PR introduces per-type flags *for all five types* but only touches UI gating, missing server side validation for new flow — worth a note (medium/high?). Place comment near the includes in _modal_event.html.twig? Better place at service `memberCanDescharacterizeForType` or in the template gating in _ev_injured_person_box? But issue is not about a specific changed line's own defect... Usually code_comment must anchor to newly added lines within review_files. I'll anchor at the new partial include in _modal_event (line 887 for AM block) but the more representative is `evApplyTypeDescaracterPayload` at 2935 (new code) or template include. I think anchoring to the new partial include for ROS at line 465 could work, mentioning the new per-type descaracter UI and absence of backend validation/authorization. But is that real? Since backend's AP validator also only enforces Sim/Não when aprofundamento_only and for AP. For ROS/QA/AM/AA, suspect field with required * comment isn't validated. So user can finalize with suspect=1 and empty Sim/Não? But UI requires clicking... but user might not know; if he leaves Sim/Não unclicked with suspect checked and tries finalizar, the finalize button? Is there a required check front? Actually there's no JS enforcing either; the Sim/Não default is unset. But maybe suspect implies the characterization is answered implicitly? Hmm.
Actually wait, maybe Sim/Não default to "Sim" via evSyncDescaracterUi which sets hidden to '0' when !canSn and aprofundamentoOnlyMode. For users WITH permission (canSn true) and in aprofundamento only mode, hidden remains empty until user clicks. So if the user checks suspect and clicks Finalizar without choosing Sim/Não, payload: suspect 1, descaracterizado absent, comment maybe empty. For AP the validator rejects. For ROS/QA/AM/AA it accepts. So yes inconsistency with UI (comment '*' + Sim/Não required concept). It may be accepted as intended flow bug — should flag.
Actually let me verify ROS's finalizar validator: maybe there's a generic post-audit "aprof" check that requires descaracterizado for all types in case suspect=1? Check SsmaEventValidator.validate for complete list. Search 'descaracter' only appears at 183 and 715. So no ROS/QA/AM/AA descaracter enforcement. Confirmed.
So I'd report new bug #C: "Os novos blocos de descaracterização para ROS, quase acidente, material e ambiental enviam os campos `descaracter_suspect`/`descaracterizado`/`descaracter_comment` no mesmo payload, mas a validação que exige Sim/Não + comentário quando há suspeita existe só no `validateAcidentePessoal`. Resultado: quem tem permissão nesses tipos pode finalizar o aprofundamento marcando suspeita sem responder Sim/Não/comentário — o backend aceita e grava dados incompletos."
Category bug; severity medium (data integrity / validations), and perhaps also mention that authorization server side uses type-agnostic `ssmaMemberCanDescharacterizeAccident` (gate still any-type). Hmm, that's a separate nuance. I could fold into one comment about server-side not enforcing per-type permission for the new UI.
Let me double check that the save route is used by these new blocks: ROS aprofundamento finalized saved with payload.aprofundamento_only and type ROS; SsmaController updateEvent 25509 calls mergeSsmaEventAprofundamentoOnlyPayload then applySsmaDescaracterPermissionGate (type-agnostic). Then validation via validator->validate including validateRos. So yes, no per-type enforcement.
Also createEvent also calls gate; but new type-based descaracter in step2 is only via updateEvent likely. Since even during create, the aprofundamento only occurs in second step but createEvent handles only general? Actually createEvent handles create, including step1; when user creates ROS, second step's Finalizar would probably call updateEvent (event already created). Fine.
Also note the `applySsmaDescaracterPermissionGate` for users with any descaracter permission returns $data unchanged, allowing descaracterizado to be whatever (0 or 1) for any type. And since the new per-type map exists only to show/hide UI, an ROS-only flagged user who opens AP via... they don't get UI for AP because template gating hides. But they can still call updateEvent directly. This is a "hidden by UI but no real protection". It mirrors how permission should be enforced server-side. That's a security finding? Category security? Well, authorization enforced only in template → per controller rules this is a blocking point (authorization enforced only in client/template). However given existing server gate is broad (allows anyone with any group flag), the risk is over-permission to users who DO have some flag in some group but not the right type. That's a real authorization enforcement gap (medium). But note the server gate also handles "can=false": forcing '0'. For can=true but only for another type...
I'll craft one comment anchoring to the service's `memberCanDescharacterizeForType` (new code) stating that the server-side save gate (`applySsmaDescaracterPermissionGate`) still grants based on `memberCanDescharacterizeAccident` (qualquer tipo/equipe), so the per-type restriction this PR applies in UI is not enforced on the API — someone with Descaracterizar só em ROS ainda consegue gravar `descaracterizado=1` num ACIDENTE_PESSOAL via requisição direta, e vice-versa. Recomendo atualizar o gate para receber o tipo e usar `memberCanDescharacterizeForType`, ou bloquear por tipo no controller. Category security; severity medium/high.
Hmm, but is that within reachable context? Yes because UI sends descaracter fields in payload (only when flagged); server normalizes regardless of type for all allowed. If an AP-only flagged user crafts a request for ROS event descaracterizado=1, the gate uses memberCanDescharacterizeAccident returns true (AP flag counts) → allowed → data persisted for ROS even though UI would not show ROS block for them (they lack ROS flag). So the new per-type flag concept is NOT enforced on the server. That means the whole feature intent (per-type permission) is only cosmetic. This is a legitimately strong finding. But is it "introduced by this diff"? The diff introduces per-type flags as the only authoritative signal in the UI/controller for page data, while leaving the save-time server gate old. That's a genuine inconsistency introduced/left by this PR, worth flagging as new (distinct from #1/#2 which talk about UI-side regression and team config).
Let me anchor this to the new controller code or service method. The most precise: In `SsmaController` the new code computes `$ssmaCanDescharacterizeByType` and gates UI, but the actual event save endpoints use `ssmaMemberCanDescharacterizeAccident`/`applySsmaDescaracterPermissionGate` unchanged → no per-type enforcement. Since file under review: SsmaController.php is in review_files. Good anchor lines: 12534-12539 or 12540. I'll anchor at line 12540: `$ssmaCanDescharacterizeAccident = (bool) ($ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false);`.
Let me confirm that `applySsmaDescaracterPermissionGate` is invoked regardless of the per-type flags and does not use type. Yes lines 25312, 25527.
I'll report:
Finding 6 (security/authorization) on SsmaController: "As flags por tipo agora controlam a interface, mas a permissão que o backend aplica ao salvar continua sendo global (qualquer grupo/tipo): `applySsmaDescaracterPermissionGate` usa `ssmaMemberCanDescharacterizeAccident`, que responde true se o usuário tiver coluna Descaracterizar em qualquer tag/equipe (e também para admin). Ou seja, alguém marcado só para ROS consegue gravar `descaracterizado=1` num acidente pessoal via requisição direta mesmo sem a coluna AP, e a validação server de Sim/Não + comentário só existe para AP. Recomendo passar o tipo no gate e reusar `memberCanDescharacterizeForType`, e repetir a validação obrigatória para os outros tipos."
Is this too overlapping with #1/#2? #1 is about the controller dropping the old auto-liberation for admin/manager etc. #2 about the service ignoring team config. This new one is about server enforcement missing per-type authorization, on the write path. Distinct enough, and important (feature intent is permission per type; without server enforcement the feature is security theater).
Wait — actually is it a *new* problem, or pre-existing and just not part of the feature? Before the PR, permission wasn't per-type in the UI either (AP-only with global aggregate server gate; ROS/QA/AM/AA had no descaracter fields at all). Now the PR claims to implement per-type flags, but leaves server gate global and validator only for AP. So the new feature code (UI-only gating) fails to enforce its own restriction. That's a new issue for the feature: new code doesn't enforce server side. Good to report.
Finding 7 (validation): The new per-type blocks for ROS/QA/AM/AA now make fields where comment required (*) but server-side no Sim/Não+comment obligation exists. This is a data integrity issue; could combine with Finding 6, but the two are separate concerns (authorization vs mandatory field validation). Maybe keep both but not too long.
Let me also consider reporting a maintainability/performance N+1 note on the service (low).
Also potential: index.html.twig/occurrence_view.html.twig default context var fine.
Let me also double-check `_ev_descaracter_suspect_block.html.twig`'s CSS class `.ev-type-descaracter-yesno` etc. matches JS references. Yes `.ev-type-descaracter-yesno`, `.ev-type-desc-btn`, `.ev-type-descaracter-comment`, `.ev-type-descaracter-suspect`.
Wait, check naming mismatch in the JS change handler: `yesNo.classList.toggle('d-none', !chk.checked)` uses `chk` var, correct.
And root click handler toggles active class via `SsmaShared.toggleYesNo`, if the library handles classes like `active`. Let's confirm SsmaShared.toggleYesNo works with valueAttr & buttons having data-descaracter-val; but careful: For AP injured card `.ev-inj-descaracter-btn` handler earlier uses maybe similar. Given that the same function is used for other buttons (js-ev-immediate-risk-opt). Acceptable.
Now potential NEW issue: For the AP injured cards that are cloned from the hidden template — when the user does NOT have AP flag, the descaracter block in the clone template is removed entirely. This makes sense after #3. But wait: Because `evReadCardInjuryData` sets descaracter fields from the card's `.ev-inj-suspect-chk` and `.ev-inj-descaracter-comment`. Without flag, no block. If the event already has descaracter_comment/descaracterizado persisted from previous versions (flag was removed later), those details could be silently overwritten/cleared if the card is saved. For AP, this is a form of data loss when admin has not flagged. However #3 covers the whole hidden block change; not need separate.
Now, on `occurrence_view` reading an event with descaracter fields shown to user with the flag only — is there a non-editable display for un-flagged users who merely view the detail? The event's view table probably renders details badges (like `descaracter_suspect` alert) elsewhere, maybe in the "view only" area independent of this modal. Check search for 'descaracter' in occurrence_view template. We should confirm that at least the detail view (not modal) still shows suspect alert to un-flagged users. Actually those are the SSMA alert listing rows etc. Not needed.
Let me now decide the final list of additional comments to add, respecting not to duplicate #1-#5:
I'll add:
1. (security/authorization, medium/high) Server-side gate for descaracterização save remains type-agnostic/aggregate (uses ssmaMemberCanDescharacterizeAccident), while UI now restricts per type. Anchor in SsmaController around new code lines. Actually better anchor on service memberCanDescharacterizeForType since the file is in review list and represents the mismatch. But the server gate usage is in SsmaController (unchanged lines 25312 etc.) — cannot anchor there because unchanged code not allowed (must anchor to newly added code). I'll anchor on controller new block 12534-12540 and explain.
2. (bug, medium) The new per-type UI for ROS/QA/AM/AA marks Sim/Não and comentário como obrigatórios, mas backend só valida isso no ACIDENTE_PESSOAL. Anchor on the new partial include or template lines 887-890 (or the block include for ROS). Better to anchor in `_modal_event.html.twig` new include for AM or in the new partial `_ev_descaracter_suspect_block.html.twig` where the asterisk is. I'll anchor on partial's `<label class="small mb-1">Comentário <span class="text-danger">*</span></label>` in the new file. Wait, that file is in review_files. Yes.
Hmm but this comment overlaps in nature with finding #6? They're both "server doesn't know about the new per-type descaracter fields." #6 focuses on auth gate (someone can set descaracterizado for a type without permission). #2 focuses on missing validation for Sim/Não+comment for those types. Both real.
Let me reflect: Is it possible the Sim/Não + comment obligations for the new blocks were intended to be validated only when there is a future feature? But UI shows asterisks and the same backend fields are being used. Reasonable finding.
3. Performance N+1 note (low) on the service's getDescharacterizeFlagsByType doing repeated queries: anchor at foreach in service lines 765-773.
Let me reconsider: is #6 (server auth gate mismatch) already effectively in #1's text? #1 states the controller now derives flag from new per-type map only and abandons old auto-liberated cases (super admin/manager/gestor adm/team config). The primary angle is the UI flag lost those cases. #6 is about save endpoint still trusting old aggregate method, which would actually *accept* exactly the same set as the UI denied (inconsistent). I'd keep #6 but word it carefully so it's clearly about the save gate being out of sync with the new per-type restriction, i.e., authorization is only UI-level for per-type restriction.
But careful: If the server gate remains broad (granting to anyone with any flag), then effectively *any* descaracter-permission user can descaracterize any type; the per-type restriction from the UI is not real security, merely display restriction. And for those without any flag, the server forces '0'. So overall the actual enforced rule is still "global Descaracterizar flag → can mark Não on any type" and not per type. If product intends per-type, they must update save gate. If product intent is only UI per-type restriction (i.e., "coluna Descaracterizar da tag daquele tipo decide se mostra o bloco"), then server mismatch matters because users flagged only for AP still can alter ROS data through requests — moderate.
I'll present as medium severity, category security (authz incomplete). Because this PR claims per-type permission ("hotfix/permission-descaraterzacao-ssma"), enforcement incomplete is blocking? Rule says "Autorização nega por padrão... esconder no Twig não protege a rota." The route/gate isn't changed. The new restriction in UI is bypassable. Severity: medium.
Also there's a check I should verify before claiming the write route doesn't already enforce per-type for the descaracter fields elsewhere, like in updateEvent after gate there might be a per-type validation using the new map? Search in updateEvent for memberCanDescharacterizeForType or getDescharacterizeFlagsByType; the service method is new and only called at 12534 (controller SSR data). So no.
Let me also verify that `applySsmaDescaracterPermissionGate`'s `$can` is indeed evaluated using global `memberCanDescharacterizeAccident`. Yes at 27415.
Now #2 (validation for non-AP) anchored at partial: I need to ensure I don't overstate: for ROS/QA/AM/AA, if user with the permission checks suspect but leaves Sim/Não unset and comments empty, frontend finalize still sends payload; backend doesn't reject (no aprofundamento requirement), saving incomplete data — and even the automations that react on `descaracter_suspect` and `descaracterizado` might treat events as "descaracterizado?" With descaracterizado missing (empty), automation at SsmaAutomationService 647-655 uses descaracterizado string (could be '' → no matches) etc. Data inconsistency. OK.
But wait: does the ROS/QA/AM/AA flow finalize with these descaracter fields only when the user has the type flag; otherwise, no blocks and payload doesn't include descaracter fields at all (evApplyTypeDescaracterPayload returns early because root missing). So incomplete-data scenario only for flagged users who ignore the UI. Since asterisk says comment required, but if user writes comment but no Sim/Não: backend accepts descaracter_comment without descaracterizado. The important inconsistency: The mandatory Sim/Não and comment are required by the UI only; the server can save suspect=1, no answer, no comment. Because finalize would be blocked server side? no. So a user can finalize leaving the Sim/Não unanswered. This is a real hole but small.
Given the reviewer guidance to favor precision and to avoid too many speculative ones, maybe I'll report #1 (server authz not type-aware) and #3 (per-type missing server mandatory validation) both anchored properly, plus performance low note on the service. Hmm. Two security-ish comments anchored in two different files.
Let me also verify the claim that comment is required when Sim/Não selected but no comment: In the partial, the "Comentário" label has `*`. The AP validator requires comment when hasSuspect and descVal set. For non-AP the validator doesn't. So yes.
Now, an additional detail: For the type-based block, when a user DOES have the flag and selects suspect but leaves Sim/Não unset and comments empty then saves a draft (not finalize), it's fine. On finalize, no server reject. Data stays incomplete but since draft/finalize states are tracked by aprofundamento_complete... could still finalize. OK.
Now let me decide severity and categories:
- SsmaController comment #6: security, severity medium.
- SsmaOccurrenceTypeConfigService comment about performance N+1: performance, severity low.
- partial/new-file or modal comment #7 about missing validation: bug/other, medium? Possibly.
Let me also reconsider whether to add a note about UI blocks appearing for all types but not clearing `ev_descaracterizado` on uncheck (stale Sim/Não across suspect toggle). It's concrete and small; but adjacent to #4. I'll skip to avoid noise.
Now, before finalizing, let me double-check the claim that the four new per-type blocks ARE only reachable when user can descharacterize for that type. `_ev_descaracter_suspect_block.html.twig` checks flag. yes.
And that there's no server per-type enforcement; verified by search that memberCanDescharacterizeForType used only in SSR data controller and service; applySsmaDescaracterPermissionGate uses memberCanDescharacterizeAccident. Yes.
Let me write the comments in Portuguese following format: (1) what changed + practical impact; (2) why it matters; (3) what to do. First sentence without jargão.
Now compose comment #6 anchored at SsmaController:
Existing code (new lines):
```
$ssmaCanDescharacterizeAccident = (bool) ($ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false);
```
Content (pt-BR): "A nova restrição por tipo vale só para a interface: ao salvar o aprofundamento, a checagem de autorização no servidor continua sendo global (quem tem a coluna Descaracterizar marcada em qualquer grupo/tipo pode gravar Sim/Não em qualquer tipo de ocorrência). Na prática, um usuário marcado apenas para ROS consegue enviar `descaracterizado=1` num acidente pessoal por uma requisição direta, mesmo sem ver o bloco na tela — e o contrário também vale para os demais tipos novos. Como o objetivo da PR é justamente a permissão por tipo, recomendo passar o tipo da ocorrência para o gate de permissão no momento do save (reusar `memberCanDescharacterizeForType`) em vez de manter `ssmaMemberCanDescharacterizeAccident`/`applySsmaDescaracterPermissionGate` inalterados."
Severity: medium (or high? Not full data exposure; medium). Category security.
Hmm but "applySsmaDescaracterPermissionGate" & "ssmaMemberCanDescharacterizeAccident" are old; the controller diff replaced UI usage. Our comment anchored on the diff lines that introduced per-type map; acceptable.
Comment #7 anchored in the new partial file `_ev_descaracter_suspect_block.html.twig`:
Existing code line: `<label class="small mb-1">Comentário <span class="text-danger">*</span></label>`
Content: "Esse bloco novo vale para ROS, quase acidente, material e ambiental, mas a obrigatoriedade de Sim/Não + comentário quando há suspeita é validada no backend apenas para acidente pessoal (`validateAcidentePessoal`). Resultado: quem marca a suspeita nesses tipos consegue finalizar o aprofundamento sem responder Sim/Não ou escrever o comentário obrigatório — o servidor aceita e grava dados incompletos. Como a tela agora exibe o campo como obrigatório, incluir a mesma validação nos validadores dos outros tipos (ou em um validador comum) nesta PR."
Severity: bug? Data integrity. category bug, severity medium.
Comment #8 performance (low) anchored in SsmaOccurrenceTypeConfigService:
Existing code: `foreach (SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS as $typeKey) { $out[$typeKey] = $this->memberCanDescharacterizeForType(...); }`
Content: "A cada leitura das páginas de listagem/detalhe de ocorrências isso executa uma consulta por tipo (5× `findBy` de tags + leitura da config), onde antes havia uma única leitura agregada. São ~6 consultas extras por request em tela de uso frequente do módulo. Recomendo carregar as tags da empresa em uma única consulta e ler a config uma vez, calculando as 5 flags em memória."
Severity low, category performance.
Let me reconsider whether comment #7 and #6 both hold enough strength, or whether they might be seen as duplicates of each other. They're distinct:
- #6: authorization gate by type missing server-side.
- #7: mandatory Sim/Não and comment not enforced server side for the non-AP types.
Both good.
Let me make sure comment text begins with plain-language, no method names first.
Also possible another notable bug: When no flag for ROS but flagged for AP... In create mode, user chooses ROS type; the new ROS block won't render for them, meaning descaracterização hidden for ROS (probably intended since they aren't flagged for ROS). Then saving the ROS event; because the event general step for ROS (step 1) is required (only ROS/QA/AM/AA don't have the AP medical approval), aprofundamento by the technical specialist etc.
I think we have enough. Let me also quickly confirm there is no test added anywhere in the diff (no test files in the list). According to service rules, new business logic requires automated tests. We might mention "falta teste" maybe optional. Not necessarily.
Let me now confirm the anchoring lines for each comment actually appear as added lines in the diff.
For SsmaController.php, added lines:
```
+ $ssmaCanDescharacterizeByType = ($company instanceof Company && $currentMemberForExport)
+ ? $this->ssmaOccurrenceTypeConfig->getDescharacterizeFlagsByType(
...
+ $ssmaCanDescharacterizeAccident = (bool) ($ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false);
```
Yes.
For partial new file, all lines are added. Use existing_code e.g., line `<label class="small mb-1">Comentário <span class="text-danger">*</span></label>` must be added lines - it's new file, all lines added. Good.
For service new method getDescharacterizeFlagsByType: lines added:
```
+ public function getDescharacterizeFlagsByType(Company $company, int $memberId): array
+ {
+ $out = [];
+ foreach (SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS as $typeKey) {
+ $out[$typeKey] = $this->memberCanDescharacterizeForType($company, $memberId, $typeKey);
+ }
```
Good.
Now let me weigh whether comment #6 risk of being duplicate of confirmed #1. #1: "flag de descaracterização passou a ser derivada apenas do novo mapa por tipo... abandonando os casos que o helper antigo ... liberava automaticamente". That is precisely about the read-side UI flag regression (cases previously true now false). It doesn't discuss the write-side gate. So comment #6 (write side not type-aware) is the mirror but distinct (UI denies but server allows per type). I think it's fine and valuable.
Let me also double check comment #6 claim of a user flagged only for ROS being able to send `descaracterizado=1` on AP: gate uses `$can = ssmaMemberCanDescharacterizeAccident(...)` true if member in any group's Descaracterizar list regardless of type (memberCanDescharacterizeAccident aggregates across tag: & team: keys, and the ROS tag would be included since new UI stores flags for tag:{id} where tag's occurrenceTypeKey is ROS). Wait: could the config have 'tag:{id}' for the ROS tag where ROS id is in aprofundamento_descaracter list. memberCanDescharacterizeAccident scans all values and returns true. Yes. So AP request would be allowed.
Now compose final answer with these comments and then task_done.
Let me phrase comments carefully in pt-BR with proper structure.
For comment #6, I should avoid leading with function names. Then detail after.
For comment #7, wording.
For comment #8 performance, wording.
I want to be certain there's nothing else regarding index/occurrence_view files where a variable could be missing in contexts; templates include the modal and pass var but no new issue.
One more check: The two files index/occurrence_view now pass `ssmaCanDescharacterizeByType` to `_modal_event.html.twig`. But `ssmaCanDescharacterizeByType` as defined in controller's SSR context, which is also used in templates for the `{% set %}` of partial includes directly? Those partial includes within _modal_event use context var default {} fallback, so without passing it would still render? Yes, but not from other contexts.
Time to finalize.
Analisei os quatro arquivos PHP/Twig do grupo de revisão, li o contexto do service (config `aprofundamento_descaracter`, gate de permissão no save, validadores por tipo) e confirmei os achados já registrados. Encontrei três problemas novos, não cobertos pelos achados anteriores.
Tool Calls (1)
code_comment
Show Details
Arguments
{"comments": [{"content": "A nova restrição por tipo vale apenas para o que aparece na tela: na hora de salvar o aprofundamento, a autorização no servidor continua global (quem tem a coluna Descaracterizar em qualquer grupo/tipo passa a poder gravar Sim/Não em qualquer tipo de ocorrência). Na prática, um usuário marcado só para ROS consegue enviar `descaracterizado=1` num acidente pessoal via requisição direta — o bloco nem aparece para ele, mas o servidor aceita — e o mesmo vale para os demais tipos novos; o gate no save usa `ssmaMemberCanDescharacterizeAccident`/`applySsmaDescaracterPermissionGate`, que não recebem o tipo. Como o objetivo da PR é justamente a permissão por tipo, é preciso passar o tipo da ocorrência para o gate de save e reusar a checagem por tipo (a mesma lógica de `memberCanDescharacterizeForType`) em vez de deixar a restrição só no Twig.", "category": "security", "severity": "medium", "existing_code": " $ssmaCanDescharacterizeAccident = (bool) ($ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL'] ?? false);", "path": "src/Controller/SsmaController.php"}, {"content": "Esse bloco novo vale para ROS, quase acidente, acidente material e ambiental, mas a obrigatoriedade de Sim/Não + comentário quando há suspeita é validada no backend apenas para acidente pessoal (`validateAcidentePessoal`). Resultado: um usuário que marca a suspeita nesses tipos consegue finalizar o aprofundamento sem responder Sim/Não nem preencher o comentário que a própria tela marca como obrigatório — o servidor aceita e grava dados incompletos (suspeita sem desfecho), o que depois afeta exibição/exportação/automações que leem esses campos. Vale incluir nesta PR a mesma validação nos validadores dos demais tipos (ou num validador comum) em vez de depender só do asterisco na tela.", "category": "bug", "severity": "medium", "existing_code": " <label class=\"small mb-1\">Comentário <span class=\"text-danger\">*</span></label>", "path": "templates/ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig"}, {"content": "Cada abertura da listagem/detalhe de ocorrências agora executa uma consulta por tipo fixo: dentro de `getDescharacterizeFlagsByType` o laço chama `memberCanDescharacterizeForType`, que faz um `findBy` de tags e ainda relê a config da empresa por chamada — antes havia uma única leitura agregada. São cerca de 6 consultas extras por request em tela de uso frequente do módulo. Sugiro carregar as tags da empresa em uma única consulta, ler a config uma vez e calcular as 5 flags em memória, mantendo o mesmo contrato de retorno.", "category": "performance", "severity": "low", "existing_code": " foreach (SsmaPermissionTagRepository::FIXED_TECHNICAL_OCCURRENCE_KEYS as $typeKey) {\n $out[$typeKey] = $this->memberCanDescharacterizeForType($company, $memberId, $typeKey);\n }", "path": "src/Service/Ssma/SsmaOccurrenceTypeConfigService.php"}]}
Result
(async)
Request #71
deepseek-v4-flash
P:115.14K C:304 CR:115.07K CW:0
3440ms
Revisão concluída para os sete arquivos do grupo. Além dos cinco achados já confirmados, registrei três problemas novos:
1. **SsmaController.php** — a permissão por tipo só é aplicada na interface; o gate de gravação do `descaracterizado` continua global no servidor, então a restrição por tipo é contornável via requisição direta.
2. **_ev_descaracter_suspect_block.html.twig** — para ROS/quase acidente/material/ambiental, a obrigatoriedade de Sim/Não + comentário (marcada com `*` na tela) não existe no backend, permitindo finalizar aprofundamento com suspeita sem desfecho.
3. **SsmaOccurrenceTypeConfigService.php** — o cálculo das 5 flags por tipo gera ~6 consultas por página de listagem/detalhe; vale carregar tags e config uma única vez.
Os arquivos restantes do grupo (index.html.twig, occurrence_view.html.twig e as demais mudanças de template) apenas repassam a nova variável de contexto e não apresentam problemas adicionais além dos já confirmados.
Tool Calls (1)
task_done
Show Details
Arguments
{"state": "DONE"}
review_filter_task
Request #1
deepseek-v4-flash
P:8.31K C:791
6520ms
Reasoning
Let me analyze each comment against the diffs.
c-0: On SsmaController.php. Claims the new code derives the descaracterization flag only from the new per-type map, abandoning cases that old helper `ssmaMemberCanDescharacterizeAccident` liberated: ROLE_SUPER_ADMIN/ROLE_MANAGER, "Gestor Administrador" tag, config by team. This is about behavioral change — a protected subject (behavioral/compatibility change). The subject concerns an authorization behavioral change. We must approve due to protected-subject veto. Actually even if we could verify... it's about behavioral change, so approve.
c-1: On SsmaOccurrenceTypeConfigService.php. Claims new per-type check only considers tag:{id} links with occurrenceTypeKey exactly matching type while memberCanDescharacterizeAccident walks entire aprofundamento_descaracter config including team:{id} links. Also concerns behavioral/authorization change and references code in the same service not fully shown in diff. Protected subject (behavioral change). Approve.
c-2: On _ev_injured_person_box.html.twig. Claims the block for suspicion of personal accident disappears for those not marked in the Descaracterizar column of the tag — behavioral/UI change. Also references behavior. Protected subject (behavioral/compatibility change)? It concerns UI visibility change. The diff indeed wraps the whole block including suspicion checkbox inside `{% if ssmaCanDescharacterizeByType['ACIDENTE_PESSOAL']|default(false) %}`. The comment says previously any AP specialist could mark suspicion and only Sim/Não was restricted. Whether that's true from diff... It's a behavioral change claim. Protected subject → approve.
c-3: On _modal_event.html.twig. Claims four per-type blocks write Sim/Não into a single global hidden field (ev_descaracterizado) and this payload reads that global field regardless of type being saved; potential leak when switching type. Behavioral change/protected? It's about runtime behavior. Also claims editing saved record, Sim/Não not visually restored per type. This is behavioral. Approve due to veto.
c-4: On _modal_event.html.twig. Style/architecture suggestion — extract JS into public/js/. This is not protected subject; it's a refactoring/architecture suggestion. Is what it states true? It states the template already has ~7.8k lines and PR adds new screen logic inside it. From the diff we see additions of JS in this template. Ground A/B? The comment's claim — template is large with a big script block, adding new logic. That's true as far as the diff shows (diff adds many JS lines). It's an architecture/style suggestion, and what it states is true. Value veto applies → approve.
So all approved. Let me double check Ground A/B for each.
c-0: targets code present in diff (ssmaCanDescharacterizeByType). Central claim: behavior restriction change relative to old helper. Diff does show replacement of old helper usage with new per-type map. Cannot refute. Approve.
c-1: code present. Claim about team:{id} links divergence — not visible fully. Approve.
c-2: code present. Claim about behavioral change. Approve.
c-3: code present in _modal_event.html.twig diff — yes, evApplyTypeDescaracterPayload reads global field. Claim central is a potential cross-type leakage. It's a behavioral concern. Approve.
c-4: style/architecture, statement true.
All approve. Call approve_all_comments.
Tool Calls (1)
approve_all_comments
Show Details
Arguments
{}
Request #2
deepseek-v4-flash
P:7.55K C:629 CR:1.92K CW:0
5622ms
Reasoning
Let me analyze each comment.
Comment c-0 (SsmaController.php): This is about server-side authorization not being per-type — that saving deeper analysis still uses a global gate (`ssmaMemberCanDescharacterizeAccident`/`applySsmaDescaracterPermissionGate`). This concerns behavioral/compatibility or authorization behavior. This is about behavior in code files the agent saw (controller and service, which are present). The claim is about missing per-type gating server-side. I can't verify from diff alone; also it's behavioral/authorization concern — protected? "Behavioral or compatibility change" — it's about a security/authorization gap. Actually the subject is about a behavioral matter. It's not something the diff proves wrong. The diff shows controller change adding per-type flags only used for display. The service adds memberCanDescharacterizeForType but the diff doesn't show the save gate being changed. This seems plausible. We cannot prove it wrong. Approve.
Comment c-1 (SsmaOccurrenceTypeConfigService.php): Performance concern about N queries per request. Claims getDescharacterizeFlagsByType loops calling memberCanDescharacterizeForType which does a findBy and re-reads company config each call. This is a performance/behavioral claim requiring knowledge of code not visible (getAprofundamentoDescaracterMemberIds, em->getRepository findBy). Can't verify; not proven wrong by diff. Approve.
Comment c-2 (_ev_descaracter_suspect_block.html.twig): Claims mandatory Sim/Não+comment validated in backend only for acidente pessoal via validateAcidentePessoal; for the new types no backend validation, so users can submit without. This is about code not visible (validators). Not proven wrong by diff. Approve.
None of these comments is proven wrong by the diff. The subject files' diffs don't contradict. All are about server-side behavior/validation that isn't visible in the diff, requiring chain of reasoning or files unseen. Approve all.
Let me double check ground A: each comment targets code present in its subject file diff? c-0 targets SsmaController.php which is in diff, and describes the new code and claims save gate not per-type. The code described is present. Not Ground A. c-1 targets service file, code present. c-2 targets new template, present.
Ground B: Does any diff line literally contradict central claims? c-0's central claim: server-side save gate remains global, doesn't receive the type. The diff doesn't show the save gate at all. No contradiction visible. c-1: performance claim, no diff line contradicts. c-2: backend validation missing for new types, no diff line contradicts (actually diff only shows the twig rendering, no backend validation). Approve all.
So call approve_all_comments.
Tool Calls (1)
approve_all_comments
Show Details
Arguments
{}
Review Comments (8 findings)
src/Controller/SsmaController.php 2 comments
src/Service/Ssma/SsmaOccurrenceTypeConfigService.php 2 comments
templates/ssma/occurrence/partials/_ev_descaracter_suspect_block.html.twig 1 comments
templates/ssma/occurrence/partials/_ev_injured_person_box.html.twig 1 comments
templates/ssma/occurrence/partials/_modal_event.html.twig 2 comments
No comments match this filter.