Is your feature request related to a problem? Please describe.
Currently, when a user creates a fieldmap, they are able to use the WordPress ID field as one of the mapped fields. Nothing prevents them from telling the plugin to save a value into that field, even though this is rarely a good idea, and maybe is never a good idea.
On the Salesforce side, we don't allow the ID field to be written to, although we do allow it to be read.
Then we have a note: "Note: when mapping Salesforce fields, a 🔒 in the field name designates a locked Salesforce field. This means you can pull data from that field but you cannot push data to it."
Describe the solution you'd like
I'm wondering if we should treat the WordPress ID the same way. That is, it can be read but not written. Users who need to change the ID in some way would need to do it via a developer hook, because if there's ever a good reason for doing that it would certainly be a more technical use case.
Describe alternatives you've considered
I wonder if we could put the lock on it and give a warning that in the future it will be technically enforced. That is, recommend that nobody write into it for now and warn that in the future they'll only be able to do it with a developer hook.
Is your feature request related to a problem? Please describe. Currently, when a user creates a fieldmap, they are able to use the WordPress ID field as one of the mapped fields. Nothing prevents them from telling the plugin to save a value into that field, even though this is rarely a good idea, and maybe is never a good idea.
On the Salesforce side, we don't allow the ID field to be written to, although we do allow it to be read.
Then we have a note: "Note: when mapping Salesforce fields, a 🔒 in the field name designates a locked Salesforce field. This means you can pull data from that field but you cannot push data to it."
Describe the solution you'd like
I'm wondering if we should treat the WordPress ID the same way. That is, it can be read but not written. Users who need to change the ID in some way would need to do it via a developer hook, because if there's ever a good reason for doing that it would certainly be a more technical use case.
Describe alternatives you've considered
I wonder if we could put the lock on it and give a warning that in the future it will be technically enforced. That is, recommend that nobody write into it for now and warn that in the future they'll only be able to do it with a developer hook.