Jump to content

Cody

Blesta Developers
  • Posts

    1,574
  • Joined

  • Last visited

  • Days Won

    74

Everything posted by Cody

  1. Really not sure how you could get that. You should only get the unknown status if the local license data can not be decrypted. When you receive the unknown status, what do you have stored for the license data on the client side? It should be the same data both before and after the client changes location before the next call home.
  2. I see the issue. In some cases LicenseManager::decryptData can't decrypt the data, so it returns null. When null is unserialized it returns boolean false. Added CORE-1643. We'll work on a fix. Thanks!
  3. The expired status will only be provided if the last call-home is date is more than $ttl seconds past. Where $ttl is passed into LicenseManager::validate(). You'll only receive a suspended status if the service for the license is suspended in Blesta, and the client makes a call-home to fetch this update. This is one reason why you should perform at least a daily call-home. The invalid_location status is given if the IP, path, or domain of the client no longer matches the value stored in the encrypted license data stored on the client.
  4. I think you are referring to LicenseManager::validate() on line 155 of license_manager.php. That method only returns a status of unknown if no license data is given, or the license data signature is invalid.
  5. That is the desired behavior of the License Module. The license_module_status field will only contain "reissue" if the license is in a reissue state. If not in a reissue state, then it contains no data.
  6. Also worth pointing out, the script I posted in this thread showed there was an issue. PHP is unable to set the include path if the include path is defined in an Apache conf file. Why that is, I'm not sure. Bug with PHP? So far haven't seen any reports of this issue with people running PHP 5.5+.
  7. Cody

    Release 3.4.3

    Version 3.4.3 is now available. You can download it in the Client Area. This is a patch release that corrects issues with 3.4.0. Patching Blesta See Patching Blesta in the User Manual for instructions. Release Notes See Blesta Core - Version 3.4.3. See all Change Logs.
  8. Simplest option is to add a few settings under "Display on Invoice" in [settings] > [Company] > [billing/Payment]: [ x ] Date Due for Drafts [ x ] Date Due for Standard Invoices [ x ] Date Due for Pro forma Invoices
  9. My guess is there was whitespace in the username somewhere, which you failed to enter during the login attempt. Blesta doesn't care if you use numbers, letters, symbols, or any combinations of those.
  10. I wouldn't suggest putting much effort in modifying the admin interface. Since it sees so much activity each release, it will be a pain to keep up to date.
  11. So back to Paul's question... What if the proforma invoice is paid late? Then changing the date billed to be the date paid would mean that the date billed is greater than the date due. For example: Proforma date billed: 2015-02-01 Proforma date due: 2015-03-01 Proforma date paid: 2015-03-15 Now becomes: Invoice date billed: 2015-03-15 Invoice date due: 2015-03-01 Invoice date paid: 2015-03-15
  12. If you want a 2-digit year just change the invoice format: FA15{month}A{num} Yes you have to update it manually each year, but that's much easier and safer than modifying files. As for zero padding. That's something we want to do. If that's truly some sort of EU compliance requirement, and you can document it as such, we'd be much more inclined to push that to the top of our queue.
  13. Well, you can't even install Blesta without phpseclib working correctly, so I don't think that an additional check in the installer is necessary. The error displayed in that case is actually quite specific. Moreover, the issue is not with CentOS per se, as we have dozens of installs of CentOS and this is not an isuse for any one of those. Just because php can't find a particular resource being requested on the include path doesn't mean the php.ini file is configured incorrectly. While it may be the issue if you are running exactly CentOS 6.5 with php 5.4 and nginx, it is not definitively the reason. Also, CentOS 7 has been out for quite a while, has anyone been able to duplicate there? We haven't, just FYI.
  14. Cody

    Release 3.4.2

    Version 3.4.2 is now available. You can download it in the Client Area. This is a patch release that corrects issues with 3.4.0. Patching Blesta See Patching Blesta in the User Manual for instructions. Release Notes See Blesta Core - Version 3.4.2. See all Change Logs.
  15. I see. So while Signapore does have ISO 3661-2 subdivisions codes, those codes are not used in addressing.
  16. Change output from PHP internal functions, such as date(), requires setting environment locale settings, which are not thread safe.
  17. Cody

    Release 3.4.1

    Version 3.4.1 is now available. You can download it in the Client Area. This is a patch release that corrects issues with 3.4.0. Patching Blesta See Patching Blesta in the User Manual for instructions. Release Notes See Blesta Core - Version 3.4.1. See all Change Logs.
  18. That could be an option, but it wouldn't resolve the issue of code changes related to authentication. If we're going to add an option to the config, we might as well add a token, and simply prompt users for this token when they wish process an upgrade through the web interface. That way the user can simply change it at any time via SFTP, and it doesn't rely on the authentication system matching the db schema.
  19. That would be simple for us, but most users don't know their license number, and a lot would have difficulty finding it.
  20. A user MUST be able to upgrade from version 3.0.0 to any future version. Any upgrade could completely change the database schema. So having the code expect one database schema but have a different one actually running is unstable. It's impossible to ensure backwards compatibility with a previous version's database schema, especially with EVERY previous version, as you imply with this authentication requirement. So we have no intention of even trying that. It's a waste of time.
  21. Since this is the intended result of this feature, I've moved to feature requests. A few things to note: Don't upload files until after you've already made a backup. The upgrade can not proceed unless the files uploaded are for a different version than the one currently installed. If you've done step 1, it doesn't matter who processes the upgrade. If we were to allow only 'authenticated upgrades' it would mean either: Upgrades can only be processed through CLI, OR Blesta would need to automatically handle the upgrade (download files/process upgrade) It's way too risky to force someone to be authenticated in order to process an upgrade when the system is in an unstable state (i.e. the files are for a different version than the database).
  22. I guess I don't understand the request. Can you provide an example usage?
×
×
  • Create New...