Jump to content


Blesta Developers
  • Content count

  • Joined

  • Last visited

  • Days Won


Tyson last won the day on August 5

Tyson had the most liked content!

About Tyson

  • Rank

Profile Information

  • Gender
  • Location
    Anaheim, CA

Recent Profile Visitors

974 profile views
  1. Graph caption doesn't support unicode letters

    Html::_ is desired because it prevents XSS while Html::ifSet does not. However, nvd3 does not render the HTML-safe characters correctly. If nvd3 could render HTML-encoded characters correctly that would be great. Another solution could be to use HTML::ifSet but strip any quotes out first to avoid the possibility of the name breaking the JSON format and introducing its own JS via XSS. The graphs failing to load sometimes is a separate issue. The JS for d3/nvd3 could not be loaded before the widget since they are defined and used from inside the widget. I don't see that as a workable solution in any case because it could end up causing a race condition (e.g. maybe the widget loads before the JS loads anyway) that leads to the same issue, assuming the race condition is the issue in the first place. The JS is already set to load in its required order of (1) d3 (2) nvd3 (3) generate graphs.
  2. Disable Ajax from Pagination

    So you're using it in a plugin? Most plugins make a call to AppController::setPagination($get, $settings, $ajax) to load and set the pagination from the config. The Blesta.pagination_ajax value in the config is used when the third argument, $ajax, is true. This value does not get overridden. If you want to override the AJAX pagination behavior, don't call AppController::setPagination. Instead, load and set the pagination yourself. // Load pagination $this->Pagination = $this->getFromContainer('pagination'); // Set GET params $this->Pagination->setGet($this->get); // Your pagination settings merged with your custom pagination settings $this->Pagination->setSettings(Configure::get('Blesta.pagination')); // Make Pagination available to the view $this->view->Pagination = $this->Pagination;
  3. Disable Ajax from Pagination

    I tested updating the Blesta.pagination_ajax config value to remove the ajax class (i.e. changed from 'class' => "ajax" to 'class' => ""), and observed the Invoices widget on a client profile to no longer load via ajax when clicking any of the pagination links. Do you not encounter this behavior? I'm using v4.1.
  4. Disable Ajax from Pagination

    What you have would work to disable AJAX for numerical pagination links, but not the current page, first, last, previous, or next links. I assume you updated the Blesta.pagination_ajax config file values for this?
  5. 4.1.0 SSL Store

    No, those module changes have not been tagged, so they were not pulled in for v4.1.0 of Blesta.
  6. set date received vs applied date

    Yes, we could have the applied date be set to the Date Received when recording a payment, but I'm not sure if that alone would satisfy this feature request.
  7. client ID incremental wrong value

    It sounds like someone may have been trying to create thousands of accounts in Blesta from the order form. Creating a client happens in a database transaction, but when that transaction is rolled back the records will not exist in the database, but the auto-increment primary keys will still increase.
  8. windows required error in universal module

    It sounds like your Universal Module product has a Package Option called "windows", and when you went to edit the price on the package that uses it, you didn't have a value set for the "windows" field under the Module Options section.
  9. set date received vs applied date

    Is this request primarily for an option to manually set the transaction amount applied date? Would this be desired when creating the transaction and applying it to invoices, or at any time afterward? There are two dates associated with transactions: The date the transaction was created (Date Received) The date any amounts from the transaction are applied to an invoice in Blesta (Date Applied) The applied date is not editable since Blesta knows itself when you apply a transaction amount to an invoice, and the invoice may change status (e.g. to closed) once the transaction payment is applied. If you could set the applied date to a past or future date after it had been applied, then the date the invoice was closed and the date the transaction was applied to the invoice may not align.
  10. I'm glad to hear you were able to finally discover what the issue was!
  11. Are there any invoices that have a line item associated with the service where: the invoice has not been closed (i.e. has a null `date_closed` value) the invoice status is active or proforma the invoice has a due date in the past If all those criteria are met, then the service could be suspended. It sounds like the data in the database is fine, yes. Did the service get suspended? If the invoice `date_closed` is set to 2017-07-28 08:26:59, then it should not be suspended --unless-- there is a different invoice for the service that is past due. If the invoice is not in the list, a payment notice email would not be sent for it. If some are still being sent, it is very peculiar and I wonder if something strange is going on.. do those payment notice emails ever get sent from custom code or a custom plugin, or maybe a separate Blesta installation altogether that is using the same database?
  12. The email logs can be deleted over time based on your rotation policy under System -> General -> Basic Setup. Are you sure those payment notice emails are not just so old that they were deleted from the logs? Are you sure the invoice has a `date_closed` set in the `invoices` table? Payment notices can go out for open invoices, e.g., invoices in this list (where the date is the current timestamp UTC): SELECT `invoices`.*, REPLACE(`invoices`.`id_format`, '{num}', `invoices`.`id_value`) AS `id_code`, `invoice_delivery`.`date_sent` AS `delivery_date_sent`, REPLACE(`clients`.`id_format`, '{num}', `clients`.`id_value`) AS `client_id_code`, `contacts`.`first_name` AS `client_first_name`, `contacts`.`last_name` AS `client_last_name`, `contacts`.`company` AS `client_company`, `contacts`.`address1` AS `client_address1`, `contacts`.`email` AS `client_email`, invoices.total-IFNULL(invoices.paid,0) AS `due` FROM `invoices` INNER JOIN `clients` ON `clients`.`id`=`invoices`.`client_id` INNER JOIN `client_groups` ON `client_groups`.`id`=`clients`.`client_group_id` INNER JOIN `contacts` ON `contacts`.`contact_type`='primary' AND `contacts`.`client_id`=`clients`.`id` LEFT JOIN `invoice_delivery` ON `invoice_delivery`.`date_sent` IS NOT NULL AND `invoice_delivery`.`invoice_id`=`invoices`.`id` WHERE `invoices`.`date_closed` IS NULL AND `invoices`.`status` IN ('active','proforma') AND `invoices`.`date_billed`<='2017-08-07 21:38:49' AND `client_groups`.`company_id`=1 GROUP BY `invoices`.`id` If you run that query, does the invoice you're referring to appear in the list?
  13. Plesk Module?

    There will be options for 12, 12.5, and 'Latest' in the updated module for v4.1 but the Plesk API is backward-compatible with older versions, so it should work just fine selecting 11.5 on the module when you're using Plesk Onyx.
  14. Shared Login Plugin

    Does that occur for an expired token? Typically, failures to validate a legitimate token are assumed to be due to malicious intent on behalf of the requestor (e.g. brute force attack) and no accommodations are made in that case. If legitimate requests can receive a blank page, then yes, we'd like to redirect/cause an error.