Jump to content

codym

Members
  • Posts

    21
  • Joined

  • Last visited

Everything posted by codym

  1. I don't see a custom edit to the Blesta installation happening. Too much of a headache... especially when we upgrade in the future. You're totally right. The easiest way on dev side would be to fix the encoding on ServiceChanges::getPresenter(), since that should return everything needed so that I can manually create an invoice for a service upgrade/downgrade. The easiest thing for the customer (me) would be for Services::edit() to automatically create a prorated invoice for the change. However, you said previously that is a purposeful design consideration. Possibly for admin functions? I'm not sure. If that's the case, then having an endpoint we can hit that returns the prorated differences according to line item (in JSON encoding) would be the most helpful. In that case, I could easily create a manual invoice from that using the Invoices::add() endpoint. However, (as I haven't gotten this far in testing yet) I'm not sure if the subsequent recurring invoice (1 month after the edit) would include the service update (assuming the Services::edit() function is used to change the service). Again, that would all require testing and I'm not quite as experienced with this system as you.
  2. I see why ServiceChanges::getItems() endpoint was deprecated... it sucks. I can't really use it at all to calculate the prorated charges for a service change and create an invoice unless I write a bunch of regex to match descriptions for each possible configurable option. I'm not sure why this endpoint doesn't return actual line items with corresponding config options, must have been in use to have service changes in a pretty format for Blesta invoices huh?
  3. @Jono Thanks for looking into it. Is there any way we can get a hotfix pushed that allows that endpoint to be JSON encoded? Otherwise we can't interface with that endpoint as it will return a PHP serialized object.
  4. @Jono I've upgraded to the newest release and am still receiving the same behavior with the getPresenter endpoint
  5. @Jono any response regarding this?
  6. Here is a 'GET SERVICE' for the service ID I used in the getPresenter function: and here is the response from getPresenter using that ID:
  7. So I think I found what you're talking about, which is app/controllers/admin_clients.php::editService. This function, when editing a service, uses the service_changes::getPresenter function to retrieve the prorated invoice details to generate an invoice for the service. So, the entire question circles back around to my reply right before your first reply where I am attempting to use the service_changes::getPresenter function to get prorated line items for an upgrade/downgrade to a service to manually create the invoice. I am receiving a 200 OK but empty response from that function, just as in that reply.
  8. What is the name of the function I should look at? I'm on 4.4.1
  9. Jono, So, there is weird behavior with the Services::edit endpoint. When editing a service, all configurable option data and field data that is not included in the edit is deleted. Is this intended? As well, a prorated invoice is not generated for the service.
  10. Thanks for the reply Jono! I think Services::edit would do what I want.... I'll play around with it and see what happens. I did some initial testing with it but it wasn't generating the prorated invoice for me. I'll get back to you on that.
  11. I have made some progress by reading through the app/controllers/client_services.php file. I see that Blesta is using various private functions to pull together the data it needs to GET the endpoint service_changes/getPresenter. This endpoint is what is providing the array of 'difference' data to create the invoice needed for the service change endpoint. However, once again documentation is sparse regarding this endpoint. I can successfully post to it and get a 200 OK, but the response is just an empty object. Assuming the service has no custom fields, this is what the post should look like and which gives me a 200 OK: The following values were pulled from the services/get endpoint with the service_id of '9', which is referred to as 'service': vars[pricing_id] = service.package_pricing.id vars[qty] = service.qty vars[configoptions][5] = service.options[option_id].qty vars[configoptions][6] = service.options[option_id].qty vars[configoptions][7] = service.options[option_id].qty vars[configoptions][9] = service.options[option_id].qty These are the only 4 configoptions which are available to this package and are all the correct IDs and within their defined ranges. This is confirmed by using the package_options/getAllByPackageId endpoint, just as Blesta has done under the Review() function of the app/controllers/client_services.php file. Finally, vars[use_module] = true in the screenshot below as that is set in the Review() function of the blesta code, however is not mentioned in the documentation. With or without this variable still gives me a 200 OK empty response.
  12. Since this post I've also tried: supplying the next available invoice_id without an invoice attached supplying the last invoice issued for the target service Both of which also gave an 'Invalid invoice ID.' error. I assume that I somehow need to manually create an invoice with the prorated data and the new options prorated as well?
  13. Hello everyone, I have a service with multiple configurable options. These configurable options are range-bound quantities. The client should be able to edit the quantities of these configurable options per-service. I am able to complete this task in the portal just fine and everything works as it should on both admin and client-side. I am trying to reproduce this behavior programmatically via the API but am running into some issues. Specifically, there are three variables which must be defined on the service_changes/add endpoint: service_id invoice_id vars I'm having trouble specifically with the invoice_id. (One would think the service_change endpoint would automatically create an invoice for the difference, but I digress!) I attempted to provide the endpoint with an invoice generated from the service I was attempting to modify, invoices/createFromServices, however I receive error 400: 'Invalid invoice ID.' What should I be doing here? Should this be a blank invoice? If so, how do I create a blank one? Additionally, I should be able to include my configurable option ID and the new quantity under vars once I have the invoice ID working properly, correct? Like so: vars[configoptions][config_option_id]=10 Here is a screenshot of my postman attempt: Thank you for your time!
  14. I actually just got it to work. Even though all of the vars[] are shown to be required in the docs, if it has a null value it is not to be sent in the request. Specifically, vars[date_last_renewed], vars[date_suspended], and vars[date_canceled] were all fields throwing the error I reported by passing null to them. Additionally, vars[coupon_id] and vars[parent_service_id] were also throwing errors due to null values after I fixed the others. The documentation should be updated to show which vars are actually optional and which are not. Lastly, the raw string is the correct format to be passed as a parameter. No quotes and no URI encoding.
  15. The data set I am passing is as follows: I have one error that exists in my directory, but I don't think it has anything to do with this issue as it is from days before:
  16. Thanks for your reply Tyson. I edited my above question to include examples of the DateTime value I am passing. In regards to: I am passing the date_added and date_renews as dates, and the other three date options as null. Surely those must not be defined as those actions have not happened on this service, which was newly created. Additionally, the services/get endpoint returns those three values as null so I don't believe those three are the issue.
  17. Hello, I'm working on the services/edit endpoint, in an attempt to add a configurable option to a clients' existing service. I am defining all of the following parameters as follows: parent_service_id = PSID package_group_id = PGID pricing_id = PricingID client_id = ClientID module_row_id = 1 coupon_id = null qty = 1 status = pending date_added = "2019-11-02 17:14:08" date_renews = "2019-12-02 18:14:08" date_last_renewed = null date_suspended = null date_canceled = null use_module = true configoptions = [currentConfigOptions, newConfigOption] I am using the services/get endpoint to retrieve the service by ID and then plugging those values directly into the edit endpoint, except for adding a single configurable option (which is my intended change). When sending the request, I get the following error: { "message": "An unexpected error occured.", "response": "DateTime::__construct(): Failed to parse time string (null) at position 0 (n): The timezone could not be found in the database" } I've taken the following steps to troubleshoot this: ensured the timezone is set in Blesta tried URL encoding the DateTime string that comes out of the get endpoint 2019-11-02%2017%3A14%3A08 passed DateTime string in quotes "2019-11-02%2017%3A14%3A08" passed null in DateTime null Any suggestions? Thanks!
  18. codym

    Delete client

    Crud. I didn't even see the getByUserID method. Thank you!
  19. codym

    Delete client

    I'm trying to use the Blesta API to delete a client. First, I used the users/delete endpoint to attempt to delete the user but received the error: So I assume that I should delete the client associated with the user first, correct? When looking through the documentation I can't find a method for getting the client ID by any user information, such as ID or username. What is the proper way to go about deleting clients with their user ID?
×
×
  • Create New...