Paul

Yes, we used the self signed cert that vestacp makes. We don't have much to go on, and we can't duplicate with our vestacp server. There may be an issue with TLS negotation, CURL, networking, or something else. All I can suggest is to try enabling error reporting and see if you get anymore details. To enable error reporting, edit /config/blesta.php and change Configure::errorReporting(0); to Configure::errorReporting(-1); You may also wish to enable System Debug. To do so, change Configure::set("System.debug", false); to Configure::set("System.debug", true); Be sure to change these settings back when you are done.

Not a bad idea. I wonder how much demand there would be for this. - Ask for email for out of stock items - Save email, linked to package - On Package edit, if item quantity available > 0, send email Pretty logical.

You can restrict it so that only clients (email matches a client) can open tickets. Do you want to ban clients from opening tickets by email? Because even if clients are banned from opening tickets my email, they can login and open tickets. To allow only clients to open or reply to tickets, edit the department (Support > Departments) and check the box: "Allow only clients to open or reply to tickets", and save.

Normal spam email filters tend to work best, like Barracuda, and then only clean email makes it to your ticket system. We would consider adding a blacklist section where you could blacklist specific email addresses or domains from opening tickets. I assume you want non-clients to be able to open tickets? If not, you can make it so only clients can open a ticket, which should reduce any spam.

Can you provide details? 4.3 will have a feature that allows you to permanently delete tickets. For spam, do you mean some way to auto detect it? And a blacklist to prevent certain email addresses from opening a ticket?

We definitely don't want to assume, since packages can belong to multiple groups, even if most people don't assign them that way. If there is only one group, then maybe the dropdown can default to that so there's no extra effort required. Anyway, created CORE-2627 to address.

When a service is added, the package group is known. In the case of the order form, the client selects the Package within the Package Group. In the case with Staff, it's listed underneath the Package Group name in the package selection drop down. If you are changing it using re-assign pricing, any package of like module can be selected, regardless of Package Group. And the Package could belong to one or more package groups. I think we need to add a second drop down menu after selecting the package / pricing to select the package group. I don't know if there is a need for using packages without being assigned to a group, since these cannot typically be ordered. See attached screenshot. Reassign pricing has the package as the label. Adding a service has the Package Group as the label.. so when re-assigning pricing, we do not know what the package group should be.

Looooooooooking good Mike.

You want to increase the admin session timeout right? There's a "Remember Me" checkbox on the login page, if you check it during login, then it won't log you out so soon. I just wonder why you don't use that, instead of increasing the session timeout? It might not be very involved to have a different session TTL for clients vs admins, I'm not sure, but so far I'm not convinced that it's something we should change. There's already an option for keeping the session open longer. What am I missing?

You could use a package with a price of 0 and then use config options to set the amount of time that's being purchased. Some people just keep track of time, and bill at the end of the month. Doing it that way, you'd create an invoice for the time manually and you can use fractions for quantity to represent the time.. for example: Website design -3hrs 45min QTY: 3 45/60 AMOUNT: $50 Where 3 45/60 is the quantity in hours/minutes, and $50 is the hourly rate. Ultimately what you're asking for I think would be the ability to order items that are not services.

Why not just check the "Remember Me" box, and logout when done?

There are 2 different packages for PHP 7.0 available to you.. rh- and sclo-. It sounds like you are running rh-php70 so you should not install packages from sclo-. You may be able to install sclo-php70 packages alongside rh-php70, and select it under PHP Versions in Virtualmin but I have not tried this myself and I don't know if it will create any conflicts.

On CentOS 7 / Virtualmin, PHP 7 can be installed from different repositories. You just need to install the packages. Run this: rpm -qa | grep php Do your php 7 packages start with rh-php70-php? If so, then you'd run: yum install rh-php70-php-gmp I don't see packages specifically for imap or mcrypt, so they might be part of something else.. you can run: yum search php70 to get a full list of matching php7 packages you could install. For mailparse you may be able to install with: pecl install mailparse .. and you may need to add to php.ini for mailparse.

How do we know what package group to assign it to? The new package could belong to 1 or more groups.. or maybe this should be an option in the UI when reassigning pricing? We have a Package/Term option, maybe we should populate a Package Group option for all package groups the selected Package is part of, and you can choose.

Sounds like a separate issue than the merge error. We have CORE-2598 already to address a display issue with the bulk updater dialog box in the bottom right. Some have reported it missing entirely, which I have not been able to duplicate. Does the CSS fix shown in the screenshots of this task resolve it for you? If not, what did you do specifically? What Blesta.Store recommended?

We are looking into a similar issue where a one-time coupon is used. This might be related. In your example, is a coupon used?

In the video they don't belong to the same client. Is the issue primarily that you can't merge tickets that do not belong to a client into a client ticket? Essentially assign an unassigned ticket to a client?

Yes https://dev.blesta.com/browse/CORE-2463

Term changes only take affect at next renewal. Going from a package with 1 year to a package with 3 year will mean that it will renew for 3 years at the end of the current term.

Thanks for the update and glad you figured that out. When there is an issue, most of the time it points back to something weird in the data set.

CORE-2616 Question is whether we should allow only merging invoices into a new invoice or existing invoice or both. [ Merge Invoices ] -- New Invoice -- Invoice #1234 -- Invoice #3456 -- Invoice #7890

CORE-2612 Let me know if you have anything to add. My biggest concern is that we may not be able to calculate the display renew date on the fly, as we'll have to look at all invoices associated with the service ID and it could cause performance issues. Maybe we need to store it in a new column for services.

I've bumped it up toward the top of the backlog, and we'll take a look at it soon. Does the code snippet you posted above still work for you?

Are you planning to import emails to tickets? If not, mailparse isn't needed. I'm not very familiar with Ubuntu but here's another guide https://serverpilot.io/community/articles/how-to-install-the-php-mailparse-extension.html

See CORE-2610