Timothy

Hello, I have another possible issue during checkout when using the universal module. I have setup a single product with two addon products. I remove the primary product during the checkout review screen. This removes the primary product and the first addon only. It does not remove the secondary addon. Basic setup: 1: Create 3 products with the universal module. 2: Add 1 product to a standard group 3: Add 2 products to 2 different addon groups. 4: Add the two addon groups to the standard group 5: Create a order form referencing the standard product. Reproduce bug: Go to the order form and add the primary product and select both addon products. Follow the screens until you reach the review screen at step 4. Remove the primary product. This will remove the primary product and the first addon product. It leaves the secondary addon product still on the screen and available for checkout. The expected behavior is to remove all addon products when the primary is removed. This issue was originally noted as part of http://www.blesta.com/forums/index.php?/topic/1144-the-parent-service-id-already-exists-as-a-child-to-another-service . Server setup: Freebsd 9.2 Nginx 1.4.2 PHP 5.4.20 - PHP is run through php-fpm. Mariadb 5.3.12 Can anybody else replicate this or have any ideas?

Thank you Paul.

Sorry, forgot to list my setup. Freebsd 9.2 Nginx 1.4.2 PHP 5.4.19 - PHP is run through php-fpm. Mariadb 5.3.12 Tested with Blesta v3.0.4 and Blesta 3.0.3. I have not tested with 3.0.2 or 3.0.1.

It appears there is a issue between the renewal date action and product service fields. I am attempting to change the renewal date on a client service through the administrative back-end. This generally works without issue. However, if the the referenced product has a service field that is set to required, you are no longer able to change the service renewal date. Instead you receive a error stating "Field Name is required." Replace field name with your actual field name. General setup: Universal module with products. Products have required service fields. Steps to reproduce. 1: Create a universal module product and set a service field to be required. In this case, I am using 'Domain Name' as the required field. 2: Create a standard package referencing the above product. 3: Go to a client page. I am assuming you already have a client for simplicity. 4: Add a new service to the client referencing the product created above. Set it to not invoice and follow all the steps to apply the service to the client. Bug trigger: Now the service has been added, click on the manage link for that service on the client page. Under Actions, select 'Change Renew Date'. Change the date and hit save. You will receive a error such as "Domain Name is required" in a red box and the service date will not change. The issue only happens when the there is a required field on the product. I believe there is a related bug at http://www.blesta.com/forums/index.php?/topic/975-cant-change-service-renewal-date/ . However that post indicates it is using the Cpanel module where I am using the universal module. Is anybody else able to reproduce this?

If there is anything else I can do to help, I'll be more then happy to. Thank you

Since I use Mariadb 5.3 instead of Mysql, I went ahead and installed Mysql 5.5 and did clean install of 3.0.3. Unfortunately I still have the same error. Everything else is the same from my previous posts. Ideas?

As a test, I changed the two addon products to use the same addon group which is then assigned to the standard group. This makes the order form show the two addon products as 'or' options. I can select one or the other, but not both. Doing it this way does not show the error during checkout. If I have the two addon products in separate addon groups with both addon groups assigned to the standard group, then the products show up as a 'and' option. I am able to buy addon products in any combination associated to the main product. This is what I am trying to achieve and the error shows when doing it this way. Any addons past the first selected one do not appear to be linked to the primary product. This can be demonstrated on the product review screen by removing the primary product. Only the first addon product is removed with the primary. Additional addons are not removed. Should multiple addons to a single product work as stated above? Is there a different way to achieve selling multiple addon products associated to a single parent product? Is there anything else I can do to test, or information I can provide to help solve this?

I may not understand fully, but I do not think I am doing that. I have the groups setup like this. Standard group (parent) - Addon group1 (child of standard group) - Addon group2 (child of standard group) Then I have the 3 packages. Each package goes to only one group. The order form then references the standard group. The order form looks correct and appears to function correctly until the final steps of the checkout where I receive the error. Is there something else I should be looking for or a different way to set it up?

Sorry, I forgot to add the server setup I am using for testing. Here it is. Setup: Freebsd 9.1 Nginx 1.4.2 PHP 5.4.19 - PHP is run through php-fpm. Mariadb 5.3.12

Hello, I am trying to build a order form to sell a single product plus multiple addon products. I have run into some errors and I'm hoping you guys can tell me what I'm doing wrong or confirm this as a bug. I have created 3 basic product definitions with the universal module. I then created the groups, packages and order form as follows. 1: Group Creation: Create Standard group called standard_example. Create two Addon Groups called addon_example1 and addon_example2. Add the two addon_example groups to the standard_example group. 2:Package Creation: All 3 packages used different products from the universal module. Create a package and call it 'example_product'. Assign the package to the 'Standard_example' group. Create a package called example_addon1 and assign it to the addon_example1 group. Create a package called example_addon2 and assign it to the addon_example2 group 3:Order Form Creation: Add a order form and call it 'Example_order'. I left all options at default for this test and added the 'Standard_example' to the assigned group field. 4: Testing. I have tried 3 test cases. Buy the example_product with no addons. Buy the example_product with 1 of the two addons selected. Buy the example_product with both addons selected. 5: Results Case 1 and 2 work fine. In the case of test 3 the system has the error 'The parent service ID already exists as a child to another service.' This blocks checkout from happening. Additional Notes: When on the review order screen, you can click to remove the primary product and it will remove the first selected addon with it. This leaves the second selected addon product still on the order screen. I would think that if you remove the primary product, all addons would go with it. The error happens independently of the payment module. I've tried with no payment module and stripe. Same error either way. I have tested this on 3.0.1, 3.0.2, and 3.0.3. The issue is identical on all 3. This is the same error as indicated at http://www.blesta.com/forums/index.php?/topic/1020-child-exists-to-another-service. However, in my case it only happens with multiple addon products. Is anybody else able to shed any light on this issues?

I did not enter anything in the service option area as there are no service options to the product. Do I need to have service options in v3.0.3? Versions 3.0.1 and 3.0.2 does not show a error with no service options.

I did a clean install of each of the last 3 versions using setup 2 from my original post. Versions 3.0.1 and 3.0.2 work without error. The 3.0.3 version has the error. Is anybody else able to confirm this?

I am also running in to this. In my case, I have to select at least two addon products on the order form for the error to show up. If I only use a single addon product the order goes through. I have also noticed that if you remove the base product from the review screen, it removes the first addon product with it but leaves the second addon product still in your cart. Is anybody else seeing this?

I added a service field with the name and label called 'examplename' and 'examplelabel' and then set it to hidden. This allows me to proceed to step two of the checkout stage without throwing a error. The configurable option still shows with the 'examplelabel' visible. I have also tested this with addon products and have the same error if the addon products do not have service fields. Adding even a single service field to each product does allow checkout to continue. Thank you for your help.

Unfortunately, that does not help. I removed the example package and product and then uninstalled the universal module. A repeat of the steps as outline in my first post brings up the error again. Honestly, I'm really confused as to what could be causing this. Is there any other information I can provide that would help narrow down possible causes?

This was brand a new install. I will try doing what you suggested.

Hello everybody. I am running into a odd issue with a very basic universal module setup. Attempting to check out with a product that does not have any service options on it fails with a error. Steps to reproduce: 1: Do a clean install of v3.0.3 2: Enable the universal module 3: Create a product in the universal module. Give it a name and leave all fields blank 4: Create package group 5: Create a package using the universal module product and assign it to the package group. 6: Create a order form and select the same package group. I left all the options either blank or at default unless otherwise stated. To trigger the error, all you have to do is select the product on the order form. This brings up the following error. Fatal error: Cannot access empty property in <path removed>/public_html/components/modules/universal_module/universal_module.php on line 868 Oh noes! Cannot access empty property on line 868 in <path removed>/public_html/components/modules/universal_module/universal_module.php Configuration settings: I have tested this on two different server setups. Setup 1: Freebsd 9.1. Apache 2.2 PHP 5.3.27 - PHP is run as fastcgi through suexec. Mariadb 5.3.12 Blesta v3.0.3 Setup 2: Freebsd 9.1 Nginx 1.4.2 PHP 5.4.19 - PHP is run through php-fpm. Mariadb 5.3.12 Blesta v3.0.3 I do not believe I was having this issue with v3.0.1 Other then that, I'm really hoping somebody can tell me what I am missing, or least a pointer in the right direction.