Jonathan

Bump

I see this missed 5.3. Think we can get it in 5.4? It's desperately needed.

Bump @Paul

There's currently an event for contacts.edit which is great but we need one for when an email address for a contact is successfully verified as well for other systems that might need to be updated by plugins for a user's new email address but only need to happen upon the successful validation of the address.

Thanks. This has become a daily need for us and I'm tired of dicking around in the DB and being the only one that can (safely) do it.

Bump.

This is a desperately needed core feature.

Any thoughts? Pretty basic nicety for module development...

It's the same one, just with some updates from Blesta.

Presently there's no way to access the suspension reason within the suspendService() method in modules. Looking at the source in app/models/services.php this is because the updated suspension_reason isn't set until after suspendService() runs, thus the suspension_reason field in the $service object is incorrect (ie it's the old/previous reason, if any). It would be great to be able to pass this value along to modules which may have their own methods of notifying customers, taking actions, etc.

Yes and no. There's not active work being done on it right now but also there are no known major bugs, but it could use some TLC. I've been inundated with work as of late on some big datacenter moves so I've not given it any love in a while. As far as I know @NETLINK is still around as well. I've been in talks with Blesta for a while on sponsoring them (read, paying them) on adding some features to it and taking the whole thing under their wing so to speak but they've not been very responsive.

Some modules take several minutes to activate a service and they don't create a lock of any sort when starting activating to prevent another process, be it cron or human, from duplicating the action. I've seen multiple instances of an order getting entered, a staffer clicking "activate" on the service to go ahead and provision it and either the cron was already running, or starts running while the staff-induced activation is still running and two services are setup, two activation emails are sent, but only one record exists in blesta so you end up with a totally orphaned service. A simple fix for this is to use locks in the database during provisioning.

@NETLINK have you heard/seen anything new about a JSON version of their API? Last I talked to them it was supposed to be getting worked on. I think moving to JSON and away from bad XML parsing would significantly help this module.

I need to know what page you were getting that error on about link_buttons. All errors I knew of related to that were fixed in 1.8.4. The "Audit Domains" and "Sync renew dates" pages are very heavy on the API and if you have low values for PHP timeouts it's quite possible the pages will simply fail to function. Sadly to improve these pages I need help from Namesilo and thus far they've refused to improve their API in a way to let me make the page more efficient.

Will be publishing 1.8.5 soon with quite a few bug fixes. If you'd like to try it out early here's the beta: https://github.com/NETLINK/Blesta-Namesilo/tree/v1.8.5-beta List of fixes are at https://github.com/NETLINK/Blesta-Namesilo/blob/v1.8.5-beta/CHANGELOG.md