Jonathan Posted June 8, 2015 Report Posted June 8, 2015 When trying to change renew date I get "One of the configurable options selected is not valid for the service." no matter what. I can change term, package, configurable options, etc. without issue, but cannot change the renew date. FWIW this is with "prorate" ticked and "use module" unticked.
Jonathan Posted June 8, 2015 Author Report Posted June 8, 2015 It only seems to occur when "prorate" is ticked so I guess the flaw is potentially somewhere in the proration logic here. Proration works on configurable optoin changes just fine.
Tyson Posted June 8, 2015 Report Posted June 8, 2015 The behavior you described doesn't seem correct. If you encounter that error, it should occur whether or not the prorate checkbox is checked. However, the rule that generates that error should never be triggered anyway because the change of renew date action does not include any config options from which to validate. Have you made any modifications to the service management page, or are you trying to perform this action over the API?
Jonathan Posted June 8, 2015 Author Report Posted June 8, 2015 I didn't think that error should be getting generated either. It's via the admin GUI. I can click "manage service", ONLY change the renewal date, save, error.
Tyson Posted June 8, 2015 Report Posted June 8, 2015 I don't encounter that issue, and I'm not seeing where this logic would occur unless the page has been modified. It might help to see screenshots of the service and its options. You could also check the POST data being submitted when editing the service renew date to see if it contains a 'configoptions' field (it shouldn't). Is the service an old service that perhaps contains old configurable options that are not valid any longer? For instance, in 3.4 it was possible to change a service's package/term without any config options being changed. So if you changed the service to a different currency/term that a config option doesn't support, then that option would no longer be valid. Attempting to change them in the future might result in the error you mentioned.
Jonathan Posted June 10, 2015 Author Report Posted June 10, 2015 It does happen even with "pro-rate" ticked. Here's what the page is POSTing: _csrf_token <redacted> action change_renew cancel term date_canceled 2015-06-10 date_renews 2015-06-18 section action Old renew date: 7/17/15 New renew date 6/18/15 Pro-rate not ticked. There is no cancellation set, nor am I trying to cancel this one. Not sure why that's getting passed. date_canceled in the database for this service is NULL.
Tyson Posted June 10, 2015 Report Posted June 10, 2015 The cancellation date is included because it's in the same form, but it is ignored when changing the renew date. The POST data looks normal. I think the issue may then be related to what I mentioned before with old service config options still being set on the service. Does that service happen to have a config option that no longer exists as a Package Option, or that may have changed term/currency to one that no longer coincides with the service term/currency?
Jonathan Posted June 10, 2015 Author Report Posted June 10, 2015 Would changing a config option and clicking "edit/save" not fix this in theory, or at least trigger the same error? Does that not do the same type of checking?
Tyson Posted June 10, 2015 Report Posted June 10, 2015 Yes, I believe saving the service again with its config options would perform the same validation check (on the given config options rather than the current config options) if the upgrade is not being queued. Then the config options for the service would be updated to remove any that are invalid. Do you experience this issue on any other services, or just one in particular? Is it possible to create a new service and encounter this issue?
Jonathan Posted June 10, 2015 Author Report Posted June 10, 2015 Doing that save doesn't seem to do the validation check, or proves that the error is indeed erroneous in it's return as I can do any other task on the page except change renewal date. It's hit or miss and I can't figure out why. If there were legitimately an invalid option, I shouldn't be able to change options and save without getting this same error, but I can change options, save successfully, try again to change renew date and it still fails. I can't change every single option listed on the page to something else, save that successfully, try again, still fail with the error.
Tyson Posted June 10, 2015 Report Posted June 10, 2015 Sounds like an interesting issue. Can you check the database to see if there are some out of place config option records on that service? Fetch all config options on the service by service ID: SELECT * FROM `service_options` WHERE `service_id` = 'SERVICE_ID'; Do the number of records listed match the number of config options on the manage service page? New config options and config options of quantity 0 would still be shown on the page, but would not have a record.
Jonathan Posted June 10, 2015 Author Report Posted June 10, 2015 There are 13 possible options in the GUI. There are 10 database rows. I can successfully "edit" any of these options and save the service. Renew date change fails. Out of the 3 options: 3 are dropdowns 7 are checkboxes 2 are quantity with a max (slider) 1 is quantity with no upper limit so it's raw number input
Tyson Posted June 10, 2015 Report Posted June 10, 2015 1 is quantity with no upper limit so it's raw number input If you set an upper limit for that option, can you then change the renew date without error?
Jonathan Posted June 10, 2015 Author Report Posted June 10, 2015 Nope, but here's something interesting. Order of events: Set configurable option limit on that item. Load service pageAttempt date change - failreload pagesave with all existing options (no pro-rate, no use module) - successdatabase drops from 10 to 9 rows for this server.attempt date change again - failconvert back to unlimited quantity load service's manage page.save with no changes (no pro-rate, no use modules) - successdatabase drops to 8 rows related to this service attempt date change again - fail The quantity of this field is 1 for whatever it's worth. The two that already have a cap and are sliders have a quantity of 0. The 8 rows in the database all have a quantity of "1". Knowing that only 3 of the fields are of type quantity, shouldn't there still be 10 rows with a value of 1 for the dropdowns/checkboxes? Some checkboxes are checked, some are not. 1 of the 7 is checked.
Jonathan Posted June 10, 2015 Author Report Posted June 10, 2015 On a whim I did this. Load the service's manage page with all options set as they are. Delete from service_options where service_id=<serviceid> Save the page thus setting these options back. Now there are 5 rows, and the date change works. Why is this error only thrown by date changes and not any other change? It seems as if something getting removed in the GUI isn't getting removed properly in the DB when saving the page.
Tyson Posted June 11, 2015 Report Posted June 11, 2015 The renew date change validates the current service fields that already exist while the upgrade/downgrade evaluates the options submitted from the page. It seems that some old records existed that probably shouldn't have, but I'm not sure why they weren't removed automatically. Based on what you described, it sounds like you should indeed have 5 config option records for that service, and it's odd that you had 10/9/8 before you removed them manually. Out of the 3 options: 3 are dropdowns 7 are checkboxes 2 are quantity with a max (slider) 1 is quantity with no upper limit so it's raw number input 3 dropdowns + 1 (of 7) checkboxes checked + 0 (of 2) quantity sliders + 1 (of 1) quantity input = 5 records
Recommended Posts