Xavier Morel a046cf2f7c [FIX] *: UX around fw=no ... The UX around the split of limit and forward port policy (and especially moving "don't forward port" to the policy) was not really considered and caused confusion for both me and devs: after having disabled forward porting, updating the limit would not restore it, but there would be no indication of such an issue. This caused odoo/enterprise#68916 to not be forward ported at merge (despite looking for all the world like it should be), and while updating the limit post-merge did force a forward-port that inconsistency was just as jarring (also not helped by being unable to create an fw batch via the backend UI because reasons, see 10ca096d86). Fix this along most axis: - Notify the user and reset the fw policy if the limit is updated while `fw=no`. - Trigger a forward port if the fw policy is updated (from `no`) on a merged PR, currently only sources. - Add check & warning to limit update process so it does *not* force a port (though maybe it should under the assumption that we're updating the limit anyway? We'll see). Fixes #953		2024-09-17 11:31:20 +02:00
..
changelog	[ADD] *: changelog entries I forgot	2023-08-14 09:28:19 +02:00
data	[IMP] *: trigger-ify task queue type crons	2024-08-02 15:14:50 +02:00
migrations	[CHG] *: rewrite commands set, rework status management	2024-05-23 07:58:46 +02:00
models	[FIX] forwardport: cron create prototype	2024-09-16 12:46:44 +02:00
tests	[FIX] *: UX around fw=no	2024-09-17 11:31:20 +02:00
__init__.py	[ADD] mergebot, forwardbot: changelog	2021-10-20 15:16:48 +02:00
__manifest__.py	[CHG] *: rewrite commands set, rework status management	2024-05-23 07:58:46 +02:00
controllers.py	[FIX] forwardport: count next to users should be the fwport	2024-06-28 08:18:34 +02:00