alertFilter documentation could use some clarification

Describe the bug
The ZAP daemon analyzes traffic from contract tests in the pipeline and produces a report. We are getting some "false positives" or defects that are already in WIP and would like to declassify them to informational threats.
The alert filter gives a "request: ok" but the filter is not afting the report in any way, ergo, it is not working.

To Reproduce
Steps to reproduce the behavior:

1. Have in a repository a gitlab-ci file with a stage for ZAP, and ZAP running as a GitLab service
2. Set up an infrastructure where you run contract tests or e2e tests, and use a proxy variable to divert traffic to ZAP Daemon
3. After everything is set up, add a script file, before the tests, to configure the filter
4. Add a script with CURL request to save the report
5. Check the report to see that there is no change or affection due to filter alerting

Expected behavior
The alert filter should impact the results of the report and reclassify a threat. In my case, I wanted to classify this threat as False Positive.
The request (with fake URL):
curl -X -4 --retry 2 --retry-connrefused --retry-delay 3 http://zap:8090/JSON/alertFilter/action/addGlobalAlertFilter/?ruleId=10098\&newLevel=-1\&url=https%3A%2F%2Famazonaws.com%2Fapi%2Fv1%2Fpings\&parameter=Cache-Control\&enabled=true\&evidence=
Screenshots

Software versions

• ZAP: Docker stable:latest and/or weekly:latest images (same problem for both)
• Add-on: standard
• GitLab - Pipeline
• Usage: Docker as Gitlab service (reference)

Errors from zap.log file
The zap.log file is not accessible. Reason. I don't have a personal Docker coitaniner running, but I'm pulling a new image every time (since I'm using it a service).
For debugging I am using config "api.incerrordetails=true".

Additional context
My findings:

1. with the error reporting option I only got: missing parameter "newLevel". After hours of troubleshooting I found that actually the problem was escaping (the parameters were concatenated with &, I just added "\ &")
2. I first passed the affected url with the escape, no result. I passed it in "clear" text, no result. So it seems to accept both (or not correctly interpret both)
3. In the local daemon, with my pc, i can choose between get and post methods. So I tried sending a CURL POST request, as a url and as a JSON. Both returned an error ({"code": "content_type_not_supported", "message":"!api.error.content_type_not_supported!"}
4. I'm working with the global filter. I also tried context-based but it requires a real context id which I don't know.
5. From the code of ZAP, it seems that only 2 parameters are actually required: ruleID and newLevel
6. With the Weekly-Relase the report looks different. There is a new field called "parameters" and a new section for false positives. Due to the loss of documentation, I can't figure out if the alert filter is based on the stable image or the weekly image and how to properly set the new parameters.

**Would you like to help solve this problem?
This seems to be a really strange behavior and it would be very important for me to get it working, so yes, I would also like to help if I can.

Start with the alertFilter addGlobalAlertFilter endpoint and compare the stable and weekly behavior described in the issue; no repository file or test is named. Clarify the required parameters, escaping, alert levels, URL and parameter handling, and the expected effect on reports, with examples for the documented ZAP versions.