I believe that extending cpd_importParticipant to update existing record is a better option.
Still, that feature could share some code with cpd_updateParticipants, which indeed, seems important.

If have to choose only one, then, theorically, cpd_updateParticipants seems more important as it is a more basic component.
Then that function could be reused by a script to do an import/update.
But still, both seems good additions to the API

public function cpd_importParticipants($sSessionKey, $aParticipants, $update = false) {...}

PR coming soon

I also vote to extend the existing function by using a new parameter with default $update = false. If set to true, we can easily extend the function to update existing data sets. That will make it easy for the common user already using the same function to update data sets if needed by just changing the new parameter value.

@c_schmitz, can you please let us know if the suggested approach ("extend the existing function by using a new parameter with default $update = false") is fine with you?

I already think we need a 'Update participant' (for token, no CPDB, but CPDB can need same) in GUI too ....

But we need a way to know how the update must be found (same with RC and CPDB):

1. default by token (if not empty), participant_id for CPDB
2. Can be a single column : (email or an attribute)
3. Can be a multiple column (firstname + lastname)
4. Did we allow to update ALL participant with same data : Example Attribute_1 is "Company" and the company update Name : you need to put the new Company name in all token with the prevous company name.

Updating cpd_importParticipants with update = true : What is the participant to update (how you finds already exists record ?) : only if participant_id is set.

actually I only need to update the status blacklisted yes or no.

Then by userid or email ?

To add this in LS3, there needs to be acceptance tests and some kind of specification, preferably in scenario form. I will give more details later (also per email with bismark).

Some manual links:

https://manual.limesurvey.org/Regression_and_unit_tests

https://manual.limesurvey.org/How_to_contribute_new_features

feature_workflow.png (40,374 bytes)   

feature_workflow.png (40,374 bytes)   

The new acceptance test should be in a folder containing the Mantis ticket number and a short description, as in this case: https://github.com/LimeSurvey/LimeSurvey/tree/master/tests/functional/acceptance/15532-em-warnings

Here's an example on how to test the remote API: https://github.com/LimeSurvey/LimeSurvey/blob/master/tests/helpers/RemoteControlTest.php

To add this in LS3, there needs to be acceptance tests and some kind of specification, preferably in scenario form. I will give more details later (also per email with bismark).

Then we can add new feature in 3.X if there are

1. Manual acceptance test
2. Specifications and usage scenario
3. Unit tests

I think new feature is only for 4.X

@DenisChenu I'm trying to reach a compromise that works for everybody. Yes, new features only in dev branch would be best, but now so many half-finished things are merged into dev that it's impossible to release a stable version (yet). We choose to accept this new feature in LS3, since it is small and assuming it complies to a more strict workflow than before to reduce the risk of instability. If it still leads to instability, then yes, we have to rethink our position.

The acceptance tests should be automatic when possible, but manual QA and code-review is also a requirement before merging.

Ok , it's an information ;)

Client NEED a new feature in less than one month : 1 hour for new feature + 1 day for acceptance test ;)

Yes, writing tests is costly, but not writing tests is even more costly (long term). ;)

:) :+1:

https://github.com/LimeSurvey/LimeSurvey/pull/1361