Api Model Logic Inconsistency And Related Issues.

[EmptyMind]

While using the API I've come across, what may not be a bug.. per se.. but it should certainly be changed.

 

When adding a new contact using the API, the DEFAULT 'contact-type' is set to 'primary'. So if you make the call and 'forget' to set the 'contact-type' (which in the docs is listed as 'optional' btw), the contact is set to 'contact-type' = 'primary'. 

 

Now this is where the problems start to occur. The API call for 'DELETE' contact REFUSES to delete a 'primary' contact, making the assumption of course that there is only ONE.

 

Additionally the additional primary contacts appear to cause further issues in pulling up the services list as the call pulls up a service for each contact thats marked primary in the array, even though its the same service. I assume this is due to the way the 'get service list' sql is written.

 

This problem also cascades into blesta proper, where the 'clients' list actually shows additional CLIENTS with the same ID, but different names, corresponding to the additional primary contacts.  Also affected appear to be the support ticket list (showing multiple copies of the same ticket). In the blesta client portal the 'delete contact' function returns the same 'cannot delete primary' obviously, since its referencing the same code as the api, thus leaving the only way to 'clean-up' the error being directly editing the database and removing the 'erroneous' entries. 

 

I can work around this on my end for now.  But this should probably be addressed in the model. Similar to the DELETE function refusing to remove the primary contact, The ADD function should refuse to add more than 1 primary contact, I'd also suggest changing the 'default' for ADD contact, to something other than 'primary', perhaps 'other' would be a better default?.

 

Alternatively, the other functions should be checked to ensure that they work with multiple primary contacts, and the delete function should only refuse to remove the LAST 'primary' contact.

 

Initially tested against 3.0.2, updated to 3.0.6 to verify that the issues still exist. (they do)

 

James

 

[Cody]

While using the API I've come across, what may not be a bug.. per se.. but it should certainly be changed.

 

When adding a new contact using the API, the DEFAULT 'contact-type' is set to 'primary'. So if you make the call and 'forget' to set the 'contact-type' (which in the docs is listed as 'optional' btw), the contact is set to 'contact-type' = 'primary'. 

 

Now this is where the problems start to occur. The API call for 'DELETE' contact REFUSES to delete a 'primary' contact, making the assumption of course that there is only ONE.

Thanks for the report. Added CORE-888 to enforce that only one 'primary' contact type can be added per client_id.

 

Additionally the additional primary contacts appear to cause further issues in pulling up the services list as the call pulls up a service for each contact thats marked primary in the array, even though its the same service. I assume this is due to the way the 'get service list' sql is written.

 

This problem also cascades into blesta proper, where the 'clients' list actually shows additional CLIENTS with the same ID, but different names, corresponding to the additional primary contacts.  Also affected appear to be the support ticket list (showing multiple copies of the same ticket). In the blesta client portal the 'delete contact' function returns the same 'cannot delete primary' obviously, since its referencing the same code as the api, thus leaving the only way to 'clean-up' the error being directly editing the database and removing the 'erroneous' entries. 

 

I can work around this on my end for now.  But this should probably be addressed in the model. Similar to the DELETE function refusing to remove the primary contact, The ADD function should refuse to add more than 1 primary contact, I'd also suggest changing the 'default' for ADD contact, to something other than 'primary', perhaps 'other' would be a better default?.

The default contact will remain as 'primary' per the schema as the most common use for a contact is for a client record. There should logically only be one primary contact per client, and I agree the system should enforce it through input validation.

 

Alternatively, the other functions should be checked to ensure that they work with multiple primary contacts, and the delete function should only refuse to remove the LAST 'primary' contact.

Superfluous.

[Cody]

CORE-888 fixed in 3.0.7.