[17.0][ADD]edi_notification_related_record_oca: configurable per-action related-record notifications - #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?
47cb50b to
0ce38b4
Compare
|
@simahawk any thoughts on this? |
simahawk
left a comment
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.
The related-record note is posted with no indication of which exchange action it comes from, so a module wanting to filter those notes per action has no way to tell them apart. Pass the originating action down, leaving behaviour unchanged: edi_oca itself still notifies on every one.
Every exchange logged a note on the business record when its data was generated and again when it was sent, two entries a non-technical reader cannot act on and that bury the chatter entries which matter. Make each of the four notes configurable per exchange type rather than dropping them, since they are useful while a flow is being set up. All toggles default to enabled, so installing the module changes no existing database.
0ce38b4 to
09bb480
Compare
OCA-git-bot
added
the
mod:edi_notification_related_record_oca
GuillemCForgeFlow
changed the title
@simahawk I've created a new module to handle the initial proposal, it lives now under a new one and not |
|
@GuillemCForgeFlow thanks for your proposal. AFAIU your final goal is to - for instance - avoid having a message "Exchange record generated" followed right away by a "Exchange record sent". Correct? I'd like to summarize the use cases that we have here and in the current implementation of edi_notification. UC
Do you see any other use case? |
No, exactly as you described. the final goal is what drove me to have this new module implemented so that we can let the user manage the settings and have more granularity on what to show. do you think that makes sense? |
4 participants
Makes the chatter notes
edi_ocaposts on an exchange record's related recordsconfigurable per exchange type and per action.
Why: every exchange logs a note on the business record when its data is generated and
again when it is sent — two near-redundant entries for a non-technical reader, and the ones
that matter end up buried. They stay useful while setting a flow up, so rather than
dropping them, which events are surfaced is left to configuration.
What
[IMP] edi_oca—_notify_related_recordnow receives the action the note comesfrom (
generate/send/process/receive, orNonefor acknowledgements). It carriesno behaviour in core; it is there so an override can decide per action.
[ADD] edi_notification_related_record_oca— addsnotify_related_record_on_{generate,send,process,receive}onedi.exchange.type,gated in a single override, with a Related Record Notifications page added to the
form via
inherit_id(no existing element is moved). All four default toTrue, soinstall changes nothing and no migration is needed. Unticking one suppresses the note
only: the record still advances, keeps its state and errors, and still triggers events.
On the
processtoggle: deliberately not filtered by direction.exchange_processisinput-only, but an output record's "processed" note comes from the
checkcomponentresolved in
edi_backend._exchange_output_check_state(e.g.edi_storage_ocapolling aremote
done/errorfile), which also calls_notify_done/_notify_error.Acknowledgements are not bound to an action and have no toggle (
readme/ROADMAP.md).Tests: the default note, each of generate/send/process disabled, that disabling one
action leaves the others posting, and that an action with no toggle still notifies.
cc @ForgeFlow