Skip to content

[18.0][ADD] mgmtsystem_event: New Module#787

Draft
diggy128 wants to merge 6 commits into
OCA:18.0from
diggy128:18.0-mgmtsystem_event
Draft

[18.0][ADD] mgmtsystem_event: New Module#787
diggy128 wants to merge 6 commits into
OCA:18.0from
diggy128:18.0-mgmtsystem_event

Conversation

@diggy128

@diggy128 diggy128 commented May 17, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor
  • Copy of mgmtsystem_nonconfirmity
  • Remove i18n directory
  • Rename all nonconformity -> event
  • Incorporate changes by maintainer-tools

This is the starting point of refactoring mgmtsystem_nonconformity as talked about at #786

@diggy128
[ADD] mgmtsystem_event: New Module
f6b1508 
- Copy of mgmtsystem_nonconfirmity
- Remove i18n directory
- Rename all nonconformity -> event
- Incorporate changes by maintainer-tools
@diggy128 diggy128 marked this pull request as draft May 17, 2026 16:14
diggy128 added 2 commits May 17, 2026 20:21
@diggy128
First form redesign
c214c6a 
- Reduce required fields to facilitate fast entry from all users. Required fields are now name, description
- Redesign event form. Keep only essentials in top part. Move some fields to separate Triage page
@diggy128
Add fields, tracking and subscription
ef96895 
- Added event_type, opened_date, deadline_date
- Rename closing_date -> closed_date
- Set tracking=True for most fields in Triage
- Auto subscribe Responsible user, Manager User to event
- Add Rejected stage
@diggy128

diggy128 commented May 17, 2026

Copy link
Copy Markdown
Contributor Author

@etobella @mymage This is the first batch of changes.
Since I have a very volatile schedule, the changes will come in random order. I'll commit often, keeping the module in a working state so that I can get your feedback.
Once we are done, I'll squash the commits.

Next up is changing state in stage_id. As is now, It is of no use as it is a one-to-one duplicate of stage_id data.
I'll change state and keep: draft, open, closed

diggy128 added 3 commits May 24, 2026 20:17
@diggy128
mgmtsystem_event: minor changes
0ba6dca 
- Change hardcoded default method to lambda
- Add res_ref reference field to show record link in view
- Change icon in chatter to more generic dot-circle (similar to issue in
 GH) since events can also be improvement suggestions
@diggy128
mgmtsystem_event: add mgmtsystem.event.tag
43d7931 
- Add add mgmtsystem.event.tag
- Clean up views (add optional in list view, remove icon in search view)
@diggy128
mgmtsystem_event: Replace procedure_ids -> document_ids
f7efe5b 
Replace procedure_ids with document_ids. Replace document_page_procedure dependency with document_page
Now any document can be linked in the event (domain to allow only documents and not categories).
This allows fine-grained analysis over the source of the event (process, procedure, work order, etc) regardless of the document hierarchy / complexity.
@max3903 max3903 added this to the 18.0 milestone May 31, 2026
@diggy128 diggy128 mentioned this pull request Jun 16, 2026
Open
@max3903 max3903 self-assigned this Jun 27, 2026
@max3903 max3903 changed the title [ADD] mgmtsystem_event: New Module [18.0][ADD] mgmtsystem_event: New Module Jun 27, 2026
@diggy128

diggy128 commented Jul 5, 2026

Copy link
Copy Markdown
Contributor Author

Currently Stage_id and state have the same values.
Stage_id is used for the kanban view and state for the functional part of the form view (readonly and invisible).
Is that separation needed?

I am thinking of merging the two and keep only state.

What do you think @max3903 @etobella @mymage ?

@etobella

etobella commented Jul 6, 2026

Copy link
Copy Markdown
Member

You probably need states, because it is the way to know if a field should appear or not. stage tables is interesting for allowing users to change the behavior, but we need to force somehow the appearance of fields.

@mymage

mymage commented Jul 7, 2026

Copy link
Copy Markdown
Member

Hi all, I will try to share my opinion but be aware of my imperfect English and coding limitation.

Event_type in event: for me "immediate" (something related to time) is not coherent with other terms (related to the reason). What do you think to use 'fixing' or 'repairing'?
Other question, do you think that will be better to let user define his own types? Because in the origin discussion I used other values as "near miss", "nonconformity", ...

Stage and State.
I agree to @etobella note, my only doubt (because i don't know all management system types) is if all system managed is covered by the actual states defined.
For stages if I understand well, when I define some stages these are available on every system managed.
If so I'm not sure that if I define two different management system in a company, both must have the same stages.

PS: curiosity: I tried the green runboat but it doesn't work, why?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

@max3903 max3903

Labels

enhancement mod:mgmtsystem_event Module mgmtsystem_event needs fixing needs review series:18.0 work in progress

Projects

None yet

Milestone

18.0

Development

Successfully merging this pull request may close these issues.

5 participants

@diggy128 @etobella @mymage @max3903 @OCA-git-bot