Jump to content

Cody

Blesta Developers
 View Profile  See their activity

  • Posts

    1,574

  • Joined

  • Last visited

  • Days Won

    74

 Content Type 

Posts posted by Cody

  1. License Manager Plugin: Lisence Check Status

    in Bugs

    Posted

    Just tested, and it's the "unknown" status returned client side when location changed

     

    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.

  3. License Manager Plugin: Lisence Check Status

    in Bugs

    Posted

    Regarding the license manager plugin & "client trials" case,

    at doing a lot of test, I can see the license "status" echo on client side can only be :

    - "valid"   if valid

    or

    - "unknown"  if other than valid

    And real cases like, "expired licence", "suspended", "invalid_location" (when being ticked in blesta licence module), are only giving at client side an "unknown" status

    So in my script integration & my custom actions after license check, I'm only using "valid" case status or different of "valid" case status

              

     

    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. License Manager Plugin: Lisence Check Status

    in Bugs

    Posted

    ok, thank to Vetal confirmation, I found strange no other found the same.

     

    I even saw the place in the code where I think it's wrong, it's the way a conditional is doing, it's will be always giving  the default "unknown" answer when license Key is not "active" VS giving a detailed status like expired, etc..

     

    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. License Manager Plugin: Lisence Check Status

    in Bugs

    Posted

    I think what I reported above is maybe in connection to:

     

    in Blesta Table service_fields, for column "key" equal  "license_module_status"

     

    - column "value" equal  "reissue....." after the Blesta general cron when the order/service passed to active status.

     

    - column "value" equal  EMPTY  after the licence have been checked & validated by the licence check.

     

    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.

  9. Eu (Proforma) Invoicing Critical Bug

    in Bugs

    Posted

    2. Do not display date due on invoices converted from proforma.

     

    On #2 I think some more discussion is required. There are a couple ways to do this:

     

    1. Have an invoice settings option to disable the display of due dates on all invoices. This may be useful for those who do not use proforma as well.

    2. Do not display due dates on invoices that were created from paid proforma invoices. If we do this, we need to store more information on the invoice that indicates that it was previously a proforma invoice, possibly another field in the table.

     

    Thoughts on #2? Thoughts on CORE-1605, CORE-1561, or CORE-1287?

     

    EDIT: Also, to add, it would be simple to remove display of the due date on invoices that are not proforma with a little code. So, while we come up with the best solution, you could make this change now to affect all invoices (but not pro forma).

     

    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

  12. Eu (Proforma) Invoicing Critical Bug

    in Bugs

    Posted

    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

  13. Eu Invoicing ? Proforma Yes But Not Eu Complient ?

    in Pre-Sales Questions

    Posted

    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.

  14. Critical: Keep Getting Call To Undefined Function Crypt_Random() When Trying To Install Blesta

    in Support

    Posted

    May I suggest the developers to take this problem seriously and include the "test for the session path"  onto the installer? It will save a lot of time to people who comes from a VPS trying to install blesta onto CentOS (which is the OS of choice for hosting).

     

    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.

     

    Since CentOS clearly set this session path wrong, it should be mandatory to test for this to work properly before installing the software, this will avoid weird error messages (like the one I had) and the debugging should be much more easy then.

     

    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.

  21. Upgrade Accessible For All Visitors

    in Feature Requests

    Posted

    What about an option in the config, that would restrict upgrades to authenticated users or CLI only? This would allow us to keep things working as they do now, for usability, but provide a way by which users could restrict the ability to run upgrades as suggested by making a minor change to the configuration file.

     

    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.

  23. Upgrade Accessible For All Visitors

    in Feature Requests

    Posted

    I am not sure why you wouldn't be able to authenticate the user in this case still?  You are most likely never changing the username/email and password fields in the database for users which means running a query against that shouldn't be much of an issue.  On top of that you control the upgrade script, that means you know that schema version (not sure if you track this or not as I haven't checked) which means you should be able to craft a query for any version of the users/groups/permissions tables if they did change.

     

    I am most likely missing something though and probably should just look at the code at this point (which is my favorite thing about Blesta).

     

    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.

  24. Upgrade Accessible For All Visitors

    in Feature Requests

    Posted

    Since this is the intended result of this feature, I've moved to feature requests.

     

    A few things to note:

    1. 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.
    2. If you've done step 1, it doesn't matter who processes the upgrade.
    3. If we were to allow only 'authenticated upgrades' it would mean either:
      1. Upgrades can only be processed through CLI, OR
      2. 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).

×
×
  • Create New...