Paul

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

Version 4.2.2 is now available. Please see the announcement. This is a patch release that corrects issues with 4.2.0. Be sure to run /admin/upgrade after uploading the patch or full versions. We strongly recommend applying this patch if you are running 4.2.0 and have pro rata enabled for any of your packages. It resolves an issue where invoices for renewing services may, under certain circumstances, be incorrect. The patch may be applied if you are running 4.2.0 or 4.2.1. Patching Blesta See Patching Blesta in the User Manual for instructions. Release Notes See Blesta Core - Version 4.2.2. See all Change Logs.

It really depends how Authorize.net has designed it. Some gateways (like PayPal, and other non-merchant gateways) make an IPN call back to Blesta with status changes. Merchant gateways like Authorize.net don't do that, or typically even have that ability, though it's possible some might. I'm just speculating, but my guess is that Authorize.net would want Blesta to periodically check the status of the transaction.. so this would be initiated on our end, and not their end. There is no mechanism built into the merchant gateway system to make automatic API calls to check the status of transactions, so *if* Authorize.net supports this, it would require a change both to the merchant gateway system and the gateway module.

The domain manager plugin will require a new version of Blesta that implements some supportive functionality, but we are using as much existing functionality as we can. The domain pricing grid is set within and handled by the domain manager plugin, not the module.

I suggest using IMAP, and marking messages as read. This way, if someone says they emailed support and you didn't get a ticket, you can login to the mailbox and see if their email was received. It also serves as a good place to keep/archive all incoming emails for the department.

For invoice merging, are you talking about only within the same client? So this option would appear on the client profile page as an admin only? Add an additional bulk option for Invoices called "Merge Invoices" below "Void Invoices" A field will appear where you enter the invoice number to merge the selected invoices into The line items are copied (not moved) to the destination invoice, and the selected invoices are voided Does that sound right? Thoughts?