Paul

I would post each change you want made to DA to Feature Requests. Please open a new thread for each item as they would be considered individually.

I agree, a cron task with settings to specify how long a client has had no activity, however that is defined (active services, open invoices, etc), could mark a client inactive. Limited client area access would be difficult and we would have to have some type of ACL permission schema admins can define for this purpose. Probably not going to happen. A different login error message due to their status is a good idea.

An option to force email address as the username (default) and not allow clients to set a different username would be necessary. The problem is that some users may necessarily have multiple accounts that use the same email address, which wouldn't be possible under such a schema so we'd have to let admins decide how they want to handle it. Plus, backwards compatibility.

Let me know what you think of this CORE-2222 It includes a provision for an additional functionality change whereby new customers will not have access to the client area until their order is approved. Having a 4th status makes this possible.

There's 2 or 3 that actually need to get done for beta. We're working on it, will be done soon. Updating minPHP and a couple other tasks were really involved, and required some refactoring and creation of new libraries. So, taking longer than expected, but almost there

Yep, it's called damage control, and it's shady. People miss it, and don't change their password at other sites if they used the same one. It made me reset my password today but I couldn't log in on the page it directs you to, totally broken. Probably why not many people logged in right now.

We were able to duplicate the issue, and have someone working on it.

Thanks, I created a task, CORE-2221 and linked it in the other thread. We'll take a look.

Thanks SSy, I have created CORE-2221 so we can investigate. We have not tried to duplicate this yet, but it sounds plausible.

We have a task that would make this part of the core, and observed by the support system and other areas. See CORE-737. Do you think this would cover our bases?

Pending invoices are not created automatically, so for these you would have had to manually create the invoice and select a future bill date. If pending invoices are included in the total, I'll create a task so we can address this in a future release.

Settings > Company > Emails: - Staff Ticket Updated - Staff Ticket Updated (Mobile) Here's the default Staff Ticket Updated HTML Here's the default Staff Ticket Updated TEXT Here's the default Staff Ticket Updated (Mobile) HTML Here's the default Staff Ticket Updated (Mobile) TEXT

Probably because there is so much time between replies (10 minutes). You may have to sneak into that mailbox and delete the message before it gets imported into Blesta to kill the loop. I'd like to implement a blacklist that you can add domains and addresses to to ignore.

Do the emails show up in the mail log under Tools > Logs > Email? Also check the staff email support templates under Settings > Company > Emails (Under the Plugins section). Did you modify any of these? If so, if there is an invalid tag, the email won't be sent because of an error.

Blesta has some rate limiting built in, if you're using piping then it should not respond after, I believe the 5th email or so within a given period of time, which will kill the loop. Don't you love it when someone signs up with an email address that goes to their support system, and then opens tickets?

Can you provide steps to duplicate? What version of Blesta and the cPanel module are you using? Can anyone else duplicate this behavior? Deleting pending services should never issue a cancel command with the module. As for duplicate orders, the best way to go is to cancel those unpaid orders. @naja7host weren't you working on a plugin to cancel incomplete orders after a period of time? I believe we have plans to add this natively as well. For now, staff can perform this action manually.

Deleting a pending service deletes it within Blesta only, and does not make a module call to perform a cancel action. Whenever performing actions on a service, look for the "Use Module" option. If it exists, you can uncheck it to ensure that the action isn't made via the API. This does not exist for deleting pending services though, and will not delete the service on WHM/cPanel.

Yes, you could have these packages in another normal package group, and assigned to the order form in the multi-select. The user will be able to see all packages from all package groups assigned and order as primary services. When the add one to cart, they should see an order more items option that will take them back to the overview listing all packages from all assigned groups. They can repeat this until they've added everything they want to their cart.

Are we talking about pending orders, or pending invoices? Pending invoices have a bill date in the future. Pending orders have services that are in the in-review status, and may have open invoices.

Are all of your staff set up under Support > Staff, with "All Day" selected for the schedule, and Receive Ticket Emails for all priorities checked? Blesta will not send out a notice if it falls outside of the staff member's schedule, or does not match a ticket priority.

Addons should work for this, because Addons in Blesta are normal services with the exception that they are child services to whatever is being ordered. SSL and Website Security services fit the description well for an Addon for a hosting service. You would want to add all your SSL packages in a single addon group, and all of your Website Security packages in a single addon group. Then, when purchasing hosting, customers will be able to select from these addons during checkout.

You would have to run an email server on the same installation. If it's not possible to point MX for your domain to that server, you could use a subdomain. Departments can override the from address as defined on the ticket, or not. If you only have 1 department, then you can disable the override on the department and mask the subdomain from the client. For example: support@domain.com -> forwards to support@blesta-server.domain.com. This would be the Email set for the department, but the email templates would use support@domain.com and the department will not override the from address. That is only useful if there is 1 department. If you need more than 1 department that will accept email, then you can still forward email from your primary domain, but the from address must be overwritten on the department or replies will not make it back. In this case, a customer may email support@domain.com, or sales@domain.com, and get a reply from support@blesta-server.domain.com, or sales@blesta-server.domain.com. For most people, this is not an issue. It may even be preferable to use a subdomain, or a different domain for tickets. You could use something like @companynamesupport.com for your ticket emails. I hope that makes sense.

I would suggest using piping for email tickets if possible. You could use a subdomain if necessary, like support@department.domain.com, and possibly even forward email to this address. Blesta will not process any task more frequently than every 5 minutes. This has, in part to do with race conditions and other potential issues. We may revisit this in the future. Piping is instantaneous though, so even better than every 1 minute.

Contract terms are something we definitely would like to add, it's come up a few times. If you want to stop billing on a service after 12 months, you could scheduled a cancellation date. On that date, the service would be cancelled and no longer invoiced. This would, of course have to be set manually after the service has been activated. You say they would have to "renew once the year is up", but how would that work exactly?

+1