gutterboy Posted May 16, 2014 Report Posted May 16, 2014 Just wondering what happens if you try to add an invoice for a non-existant client via Invoice:add(). Does it automatically create a client account for them or should I always check if the user exists first and then if not create an account for them via Client::create() ? ...or should I use Client::add() or User:add() - what is the difference, do you need to call both? Ideally I would like them to use a client or user id that matches their user id in our main system. Quote
Tyson Posted May 16, 2014 Report Posted May 16, 2014 Just wondering what happens if you try to add an invoice for a non-existant client via Invoice:add(). Does it automatically create a client account for them or should I always check if the user exists first and then if not create an account for them via Client::create() ? You can't create an invoice for a client that doesn't exist. The client ID is required to create the invoice, and errors are generated for any missing or invalid fields. So yes, you would need to create a client first with Clients::create(), or use one that already exists. Ideally I would like them to use a client or user id that matches their user id in our main system. You're not going to be able to tie the system-level client or user IDs to your main system unless you integrate a solution where adding a user to either system adds them to both, and they both auto-increment from the same value, and there are never any errors that occur which prevent creating a user on one system when it was created on the other--in other words, it's not going to happen. Not sure why you would need that anyway, though. Quote
gutterboy Posted May 16, 2014 Author Report Posted May 16, 2014 You can't create an invoice for a client that doesn't exist. The client ID is required to create the invoice, and errors are generated for any missing or invalid fields. So yes, you would need to create a client first with Clients::create(), or use one that already exists. You're not going to be able to tie the system-level client or user IDs to your main system unless you integrate a solution where adding a user to either system adds them to both, and they both auto-increment from the same value, and there are never any errors that occur which prevent creating a user on one system when it was created on the other--in other words, it's not going to happen. Not sure why you would need that anyway, though. Well not sure how else you can keep track of what invoices belong to which user on our main system unless they are mapped via their main site id somehow. Looking at the Client::add() method can't you need to pass in a user_id within the data array - why can't you pass in the user id of the user there? Though still not sure how Client::create() and Client::add() differ; from what I can tell from the system, users can be anybody (clients or staff) and then extra info is stored either in the clients table or the staff table depending on their role within the system; so trying to understand in which case you would use Client::create() and which you would use Client::add() ? Quote
Tyson Posted May 16, 2014 Report Posted May 16, 2014 You would use Clients::create() to do everything--create a client user, create a client, set client group custom fields, setup client settings, add a contact, setup contact settings, and send a registration email. Basically everything that you can do through the admin interface when creating a new client. Clients::add() is simply to create a new client, and that's it. No contact, no settings, all of which are required for proper use in the system. You would need to add that additional information separately, but Clients::create() already takes care of it, so that would be the simpler way to go. It sounds like you need to design a solution that works in your main system for what you're trying to do. If you just need to know which user in your main system corresponds to which user in Blesta, then you can add a new database table, `user_mapping`, that contains two primary fields, `client_id` and `main_system_user_id`. Then insert into that table everytime a client is created. Query it from the main system to determine the Blesta client ID, and use Blesta's API to fetch anything else you need based on that client. Quote
gutterboy Posted May 16, 2014 Author Report Posted May 16, 2014 Great - thanks! Yeah, that was the route I was probably going to go with if they couldn't have the same id. Is the id of the user contained within the returned object you get from Clients::create() ? Quote
Tyson Posted May 16, 2014 Report Posted May 16, 2014 The client returned is from Clients::get(), so yes, it does contain the user_id. Quote
NetworkJack Posted August 6, 2014 Report Posted August 6, 2014 I'm trying to migrate from a old home-grown FileMaker Pro system over to Blesta 3.2. I'm working on using the API to perform that migration and I would really like to keep the same client ID. From I can see, I might be able to use ::add, but not ::create to do so, unless... I made this patch to ::add in Clients model: $calc_next_id_sql = "IFNULL(GREATEST(MAX(t1.id_value),?)+?,?)"; if (!empty($vars['client_id'])) { $calc_next_id_sql = '?'; $values = array($vars['client_id']); unset($vars['client_id']); } $sub_query->select(array($calc_next_id_sql), false)-> so if I pass client_id in to the method, it will get used instead of auto-calculated. Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.