This ticket list is broken and it is duplicated with Panel View anyway.

   This information is duplicated with Panel View anyway, no reason to keep it

   Be consistent and also search for a Remote Node, since it can also contain Compute Partitions.

   Otherwise, whenever you run the tests multiple times, it ends up failing by selecting the wrong one on the listbox.

  Accountant should create the proper document rather them use this workarround action.

   Let the site administrator configure proper accounting instead.

   Business Process are mandatory for Trade Condition, so this process covers
   manual accounting.

  This helps to emulate payments, so we can test outcome before/after payment to wechat

  Only launch caucase when needed.  Not all tests need
  caucase, this saves a bit the overhead to run it

slapos_accounting: a single payment transaction can be used to pay multiple invoices with different destinations

Define the source_project on the newly created Sale Trade Condition

slapos_subscription_request: cancel existing subscription request if a new trade condition is detected

Do not crash if subscription could not be created anymore

slapos_upgrader: do not fixup instance tree virtual master if one software instance is in the same virtual master

Ensure people can see projects they used to see before migration

  Whenever the allocated shared (slave) instance is destroyed or stopped, isn't included on the getComputerInformation, so the timestamp can eventually go back in time (so partition skips process).

  This ensures that the partition information gets a newer timestamp (larger them the previous one).

   All timestamps parameters should be int, and be consistent accross
   the parameters.

   The client compare previous/fetched as float, so use string can break
   later on if we introduce a non-numeric value on returned dict.

    Check if bang_timestamp is consistent and updated
    accordingly by the normal usage.

    Whenever an instance is allocated the partition must
    update its bang_timestamp.

    Ensure the implementation is consistent with the precision (1e6) otherwise partition modification date will never
    ever be larger, when compared.

  This ensure that timestamp is updated, and enforces that cache is updated