Idea ID: 2705849

ESM - Version History for Rules & Filters

Status: Waiting for Votes

Waiting for Votes

See status update history

Please create a code-repository for  Rules and Filters, so that it is possible to have a version history.





  • This is most definitely something we believe is important to the future of rules development.  I do not yet have an ETA for when we'll deliver this critical functionality however it is very near the highest of user-submitted feedback.  I will absolutely keep this group posted as we make progress.

  • anything you can share... I mean this has reached >40 votes.

  • Hey  ... can you give some insights, if you thing about implementing this?

    Seems the community thinks its a good Idea.



  • Hi Jeremy, 

    the how... and what:

    I think a version control of rules should store all actual rule filters, aggregaten settings, variables, etc.  

    How many versions backwards... I think there should be somthing like a soft and a hard "definition of a new version" - so for example if you are developing a  rule, there might be a lot of changes, tweaking going on, before the rule is in a "version 1 state".  Therefore  you should have the choice to just save a rule (no new version is created), or save it as a new version - so a little bit like a commit in github. and why not put some possibility to put a comment. And for sure a rule gets saved as a new version, if there was no change after ~60 minutes or something like that. 

    sure this will be get complicated, because auf dependencies... i.e. you have a "building-block" filter in a rule - should this filter be stored together with the version, or not - i would say no, as if you have code and use a library from "a third party" you dont store the complete library - however you might hava a note that it worked/tested/somthing like that, with this version of that filter.... so i think there should be something like a version warning or so. that keeps track with which version a rule was working with . However i think thats something MF as s software developing  house should have some experience with already.


    I also think keeping only 2 version of a config is way to less, as a misthake normaly gets not spotted within one version. at least that's my experience - i would keep at least 5 versions - with the possibility of unlimited versions.


    Having a "diff view" of rules/filters would be great - i think as a MVP beeing able to have one "editor window" with the latest version and another editor window with older versions would be already a very good enhancement. 

    Deleting versions.... no not really -  as this would be against the "audit" principle that tha comes with this feature --- hence the unlimited storage for rules and filters.

    Going back to a version... i would define it like use this "old version" as "new version"  - this makes easier to review and also for auditing purposes i would not just delete the versions that were created after the "old version".


    I think both rules and filters should be treated in the text above internchangable...

    I think thats already a lot of thoughts - if any questions, just come back and ask .








  • Well, It's a very great idea to save time for lots of people. But, if it needs to keep old configuration, need to reduce maximum number of history&data. If not, it will make additional management point.

    V.1.0 - just make the history of changes by whom
    V.2.0 - Just keep 2 configurations for each version.