Partially fixed issue 363: Add missing parameters for path interface bridge and interface bridge port

[FelixRicke]

SUMMARY

Add missing parameters to path interface bridge and interface bridge port

Partially fixes issue #363.

ISSUE TYPE

• Feature Pull Request

COMPONENT NAME

• _api_data.py

ADDITIONAL INFORMATION

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.85%. Comparing base (0b2dc61) to head (d7f76b9).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #423   +/-   ##
=======================================
  Coverage   85.85%   85.85%           
=======================================
  Files          30       30           
  Lines        4094     4094           
  Branches     1003     1003           
=======================================
  Hits         3515     3515           
  Misses        405      405           
  Partials      174      174           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[FelixRicke]

Hi @felixfontein,

I am not currently working with older versions of RouterOS (nor am I familiar with them),
so I cannot say when a path was assigned new parameters or default values.
And to be honest, I don't really have the time to check every version or every release note (which, in my opinion, often do not provide direct information).
So what do you think would be the best approach? Should I always add the changes as versioned_fields?

[felixfontein]

I am not currently working with older versions of RouterOS (nor am I familiar with them), so I cannot say when a path was assigned new parameters or default values. And to be honest, I don't really have the time to check every version or every release note (which, in my opinion, often do not provide direct information). So what do you think would be the best approach? Should I always add the changes as versioned_fields?

That's a very good question, and something I've been wondering about as well. The RouterOS documentation is really bad about such things... I wish there would be some (automatically generated / machine readable) API docs that could be used as a basis for the API modules in this collection, but there don't seem to be any.

Simply adding the new fields with the "current" minor version - as you did in this PR - sounds like a good idea; if someone is using an older version and notices that something is different there, they can create a bugfix to fix the version numbers. If nobody is using them, well, then it doesn't matter anyway :)

[felixfontein]

@FelixRicke thanks for improving the modules!