[17.0]edi_oca: configurable per-stage related-record notifications + form cleanup - #317
Conversation
| <group name="config"> | ||
| <field name="exchange_filename_pattern" /> | ||
| <field name="exchange_filename_sequence_id" /> | ||
| <field name="exchange_file_ext" /> | ||
| <field name="exchange_file_auto_generate" /> | ||
| <field name="ack_type_id" /> | ||
| <field name="ack_for_type_ids" widget="many2many_tags" /> | ||
| <field name="partner_ids" widget="many2many_tags" /> | ||
| <field name="job_channel_id" /> | ||
| <field name="quick_exec" /> | ||
| <field name="encoding" /> | ||
| <field | ||
| name="encoding_out_error_handler" | ||
| invisible="direction == 'input'" | ||
| /> | ||
| <field | ||
| name="encoding_in_error_handler" | ||
| invisible="direction == 'output'" | ||
| /> | ||
| <field | ||
| name="allow_empty_files_on_receive" | ||
| invisible="direction == 'output'" | ||
| /> | ||
| </group> |
There was a problem hiding this comment.
Please don't do this: this architecture might be inherited and customized by third-party modules, and this change might break the view's inheritance mechanism (even though I personally agree a page in the notebook yields to a better UX).
There was a problem hiding this comment.
I see, thanks for pointing out. what I've done now is still keep the name="config" attribute on the main group in the view. I understand there's still a chance that will can break current installations. do you think we should perhaps note this to be done in the next migration?
Move the exchange-type configuration fields out of the header and into a dedicated 'Configuration' notebook page, grouped by nature (File, Automation, Acknowledgement, Scope). The header keeps only the base identity params (backend, backend type, code, direction).
Add per-type toggles (notify_rel_rec_on_generate/send/process/receive, default True) on edi.exchange.type controlling whether a chatter note is posted on the related record for each exchange stage. The gate lives in the single funnel edi.exchange.record._notify_related_record, which now takes the stage action and consults edi.exchange.type._notify_related_on; generate/send/receive thread it via notify_action_complete, process via _notify_done/_notify_error. Defaults preserve the previous always-notify behavior.
47cb50b to
0ce38b4
Compare
|
@simahawk any thoughts on this? |
simahawk
left a comment
There was a problem hiding this comment.
@GuillemCForgeFlow Thanks for your contrib!
I don't think this should stay core.
I would add a new module or add this to edi_notification_oca.
How
Tests
Adds coverage in test_backend_output.py: with notify_rel_rec_on_generate = False, generate posts no note while send still does; default behavior unchanged.
cc @ForgeFlow