[piruin]

Closes #174

Stray Meeting activities (root cause of mail_activity growth)

When a service event is created from the patient form, the context carries active_model = "ni.patient" and active_id = <patient>. ni.service.event uses _inherits from calendar.event, so calendar.event.default_get turns those keys into res_model/res_id. calendar.event.create then adds a Meeting mail.activity on the patient. That is how mail_activity grew to millions of rows.

ServiceEvent.create() now calls super() with active_model=False, active_id=False. default_* keys from the action still apply, and ni.service.create_event() (default_res_model = "ni.service") is unaffected. Covered by test_create_from_patient_form_adds_no_activity_on_patient, which fails without the fix.

Indexes

Every name matches production exactly. Odoo skips an existing index by name, so -u on production builds nothing.

Index	Definition	Module	How
calendar_attendee_event_id_index	calendar_attendee (event_id)	ni_service	event_id field override, index=True
calendar_event_id_filter_idx	calendar_event (id) INCLUDE (active, start, stop, allday, start_date)	ni_service	raw SQL in init()
ni_service_event_message_main_attachment_id_index	btree, WHERE ... IS NOT NULL	ni_service	index="btree_not_null"
ni_service_event_displayed_image_id_index	btree, WHERE ... IS NOT NULL	ni_service	index="btree_not_null"
calendar_event_message_main_attachment_id_index	btree, WHERE ... IS NOT NULL	ni_service	index="btree_not_null"
ni_patient_message_main_attachment_id_index	btree, WHERE ... IS NOT NULL	ni_patient	index="btree_not_null"
res_partner_message_main_attachment_id_index	btree, WHERE ... IS NOT NULL	ni_patient	index="btree_not_null"
ir_attachment_original_id_index	btree, WHERE ... IS NOT NULL	ni_patient	index="btree_not_null"
survey_user_input_message_main_attachment_id_index	btree, WHERE ... IS NOT NULL	ni_questionnaire	index="btree_not_null"

• mail_activity_user_id_date_deadline_id_idx and mail_activity_id_res_model_res_id_idx are intentionally not declared. The plan is to drop them on production after the activity cleanup.
• ir.attachment.original_id comes from web_editor. ni_patient already depends on it through portal, so there's no new dependency.

After deploy (ops, per database using ni_service)

1. Delete the Meeting activities on ni.patient that are linked to a calendar event. Match on res_model = 'ni.patient', activity type category meeting, and calendar_event_id IS NOT NULL. Delete in batches at night, then run VACUUM (ANALYZE) mail_activity.
2. After that, drop the two mail_activity_*_idx indexes with DROP INDEX CONCURRENTLY.

Verification

• A fresh install of ni_service,ni_questionnaire creates all 9 indexes, and each indexdef matches the issue. No mail_activity_*_idx index is created.
• Running -u ni_patient,ni_service,ni_questionnaire on that database left every index OID unchanged, so nothing was rebuilt or duplicated.
• Tests for /ni_patient,/ni_service,/ni_questionnaire: 0 failed, 0 errors of 80.
• Not checked: EXPLAIN of the query shapes. A small local database won't pick these indexes, so this has to be checked on production.

Related: nirun-life/nirun-dop#70 (create_uid indexes in ni_community_care).

[piruin]

Decision: index message_main_attachment_id per model, not on mail.thread.

Overriding the field once on mail.thread would index every mail-thread table. We keep the per-model overrides for three reasons:

1. Upgrade stays a no-op on production. Production has these indexes only on the tables listed in [Task] ni_service and related modules: declare production indexes and stop unwanted Meeting activities #174. Overriding mail.thread would make -u ni_patient run a plain, write-blocking CREATE INDEX on every other mail-thread table: Odoo core models, ni.encounter, ni.appointment, ni.medication*, ni.procedure, ni.device*, ni.goal, and the nirun-dop models. None of those has been measured.
2. Only large tables need it. The ON DELETE SET NULL check on an attachment delete is only slow on tables with millions of rows. Small tables scan cheaply, and an extra index only adds write cost. The list follows what pg_stat_statements showed.
3. Forward-port. In 17.0, message_main_attachment_id moved from mail.thread to the mail.thread.main.attachment mixin, so an override on mail.thread would break on 17+.

If another table (for example ni_encounter) grows large later, confirm on production first, then add the index on that model under the name production uses.