[API] preconfirm_subscriptions is ignored for PUT requests

[marcinkunert]

Version:

• listmonk: v2.0.0
• OS: Docker/Debian

Description of the bug and steps to reproduce:

1. Create a subscription (status: confirmed)
2. User unsubscribes (status: unsubscribed)
3. Send API PUT request to /subscribers/:id with preconfirm_subscriptions set to true

Expected behavior:
User is set back to confirmed status

Actual behavior:
Status of the subscription doesn't change.

Workaround:
Let's say the ID of the target list is 4.

1. Send API request to sign the user to any other list (e.g. 1)
2. Send API request to sign the user to the target list (4)

Concerns

Let's say the user is signed up to multiple lists:

1 - newsletter - status: unsubscribed
2 - marketing - status: unsubscribed

To use a specific part of my service, the user has to agree to receive marketing emails. Currently, there is no option to change only one of these statuses. It's either change them all (by using the workaround I've described) or none. Even if the behavior with preconfirm_subscriptions would change that would mean that the user will be subscribed to both list.

Possible solutions:

• change the API so instead of receiving only a list of IDs for target lists it would also get the expected status. In such case preconfirm_subscriptions would be no longer needed. This solution would break the current API
• add an API for managing lists for given subscriber. E.g. /api/subscribers/:id/lists/

[knadh]

add an API for managing lists for given subscriber. E.g. /api/subscribers/:id/lists

I think this is the best approach. preconfirm_subscriptions is only meant to apply to new lists that are being added, which is the current behaviour. I'll push a patch soon.

[knadh]

curl 'http://localhost:8080/api/subscribers/lists' -X PUT \
      -H 'Content-Type: application/json;charset=utf-8' \
      --data-raw '{"action":"add", "status": "confirmed", "target_list_ids":[2],"ids":[1]}'

Added status=confirmed|unconfirmed|unsubscribed to the existing bulk list modification API.

Just realised, this long forgotten API's URI + fields are a bit awkward and not consistent with the rest of the APIs.