Changing Module In Package Settings Does Not Update Module_Row_Id Of Existing Services

[Max]

1) you are using the "universal module" first.

2) later you install a proper module for the service you are selling, and update the "package settings" of the existing package so that it is using the new module.

 

Expected behavior:

 

If the module is changed to a totally different one, I would expect existing services to be updated, and module_row_id to be set to the new one selected in the package settings.

 

Actual behavior:

 

When the client views a service purchased before the change in the client area, it does is shown the tabs of the new module. However they will not work, as the module is unable to obtain its module row.

Calling $this->getModuleRow() inside the module returns boolean false. Database table "services" shows the existing services still have a module_row_id belonging to the universal module.

 

 

 

Related threads:

 

http://www.blesta.com/forums/index.php?/topic/3891-remove-module/

http://www.blesta.com/forums/index.php?/topic/572-dedicated-servers-vps-module/?p=28549

[mrrsm]

+1 I was just coming to make this post

[Tyson]

Expected behavior:

 

If the module is changed to a totally different one, I would expect existing services to be updated, and module_row_id to be set to the new one selected in the package settings.

 

If the module is changed to a totally different one, the services would not be usable whether the module_row_id were propagated to each one or not. The service fields would no longer be valid and there is no method by which to automatically determine what values they should contain. The fields for each service would need to be updated manually. So the module_row_id propagation would be necessary, but not sufficient.

 

Short of creating a mapping system whereby changing a package's module subsequently requires you to manually update the fields for every service that uses that package, I don't think it's possible to maintain services from a package whose module is changed.

 

There is no easy solution to accommodate a package module change. You could cancel all existing services and re-add them; add a separate package for the different module, and maintain the use of both packages; or manually update each service's fields manually, which is not always possible through the interface, depending on the module.

[Max]

If the module is changed to a totally different one, the services would not be usable whether the module_row_id were propagated to each one or not. The service fields would no longer be valid and there is no method by which to automatically determine what values they should contain. The fields for each service would need to be updated manually. So the module_row_id propagation would be necessary, but not sufficient.

 

But at least the service fields could be updated manually in the service's setting then, while keeping the other information like the service's expiration/renewal date.

 

 

 

 

 

or manually update each service's fields manually, which is not always possible through the interface, depending on the module.

 

Our module does allow changing the service's fields.

But that currently doesn't work, because the module_row_id is wrong.

 

If you disagree with updating the module_row_id, at least prevent the user from changing the module of a package that has active services tied to it.

The current situation in which you do allow changing the module, and do show the tabs belonging to the new module in the admin and client area, makes it appear like the module can be changed.

[Paul]

If you disagree with updating the module_row_id, at least prevent the user from changing the module of a package that has active services tied to it.

The current situation in which you do allow changing the module, and do show the tabs belonging to the new module in the admin and client area, makes it appear like the module can be changed.

 

Preventing a module change on a package with existing services is probably the first step in a multi-step solution to improve this overall. Perhaps allowing modules to be changed and providing a process of "migrating" existing services over. CORE-1568 will prevent the module from being changed for packages with existing services. It is currently private and it has been assigned to part of an Epic for 4.0.0.