Hello there,
I have a bit of a situation which I've only just noticed after using this software for 2 years!
When we migrated from HighRise to EspoCRM, my import script used the previous ids provided by the export from Highrise. I didn't generate the 24 character hash ids.
Now I realise this was a terrible decision but it seemed like a good idea at the time. I've just noticed a few places where is_string( ) is used to check whether a variable contains an ID or not. With an integer ID, this check fails. This was causing a call to RDB::relate() to fail.
I'm not sure what the best solution is. Either improve those checks so they don't expect alpha chars to confirm validity of an id, or process ALL of the references to the thousands of integer ids out of the database - prone to lots of potential mistakes.
Any suggestion would be appreciated..
I have a bit of a situation which I've only just noticed after using this software for 2 years!
When we migrated from HighRise to EspoCRM, my import script used the previous ids provided by the export from Highrise. I didn't generate the 24 character hash ids.
Now I realise this was a terrible decision but it seemed like a good idea at the time. I've just noticed a few places where is_string( ) is used to check whether a variable contains an ID or not. With an integer ID, this check fails. This was causing a call to RDB::relate() to fail.
I'm not sure what the best solution is. Either improve those checks so they don't expect alpha chars to confirm validity of an id, or process ALL of the references to the thousands of integer ids out of the database - prone to lots of potential mistakes.
Any suggestion would be appreciated..
Comment