BitcartCC is a platform for merchants, users and developers which offers easy setup and use.

Overview

BitcartCC

Github All Contributors CircleCI Codecov Python versions

BitcartCC is a platform for merchants, users and developers which offers easy setup and use.

Linked repositories

Our ecosystem consists of a few packages, this is our central repository.

It is recommended to propose feature requests to BitcartCC ecosystem as a whole on that repository.

Full list of our repositories:

https://github.com/bitcartcc/bitcart - BitcartCC Core Daemons and Merchants API

https://github.com/bitcartcc/bitcart-admin - The admin panel of BitcartCC

https://github.com/bitcartcc/bitcart-store - BitcartCC ready store

https://github.com/bitcartcc/bitcart-docker - Docker packaging, base for all deployment methods

https://github.com/bitcartcc/bitcart-sdk - Python library for coins connection

https://github.com/bitcartcc/bitccl - The BitCCL scripting language for checkout flow automation

https://github.com/bitcartcc/bitcart-docs - BitcartCC documentation

https://github.com/bitcartcc/bitcart-site - BitcartCC official site

Docs

Docs are available at https://docs.bitcartcc.com or in our docs repository

Contributing

See our contributing guidelines for details.

Contributors

Thanks goes to these wonderful people (emoji key):


MrNaif2018

🚧 💻 📖 🎨

tomasmor42

💻

Yağız Değirmenci

💻

Weidong Sun

💻

kartecianos

💻

CYBORG

🎨

Saksham Singh

🎨

Orestis Charalampakos

🎨 💻

TobyAsE

💻 🎨

Shadman Ahmed

🎨

Karol Trzeszczkowski

💻

This project follows the all-contributors specification. Contributions of any kind welcome!

Copyright and License

Copyright (C) 2019 MrNaif2018

Licensed under the GPLv3+

Issues
  • [FEATURE] Please consider a copyright license that protects the users of this software.

    [FEATURE] Please consider a copyright license that protects the users of this software.

    Your project is labeled to use the MIT license, which is an open source license but it has the strict allowance that code under this license can be re-released by anyone later as closed source.

    The direct effect is that while todays release is open source, there is no way to know that next month your organization does not decide to relicense to a closed source version. We just have your promise to not do that.

    This is a huge risk to merchants. Merchants that would use this product want to receive updates, may want to pay someone to build features and generally want to make sure that they don't lock themselves into a dead-end project.

    Maybe also relevant for your own motivation is that any competitor can come and fork your project and compete against you with a closed source project using your own code as a basis.

    Describe the solution you'd like

    Please consider relicensing your project to use a so called "copyleft" license which disallows you or anyone else from using this code against the userbase. I personally prefer GPLv3 for this.

    Additional context

    In Bitcoin Cash we had several cases where companies did follow the route I explained, which cost the community a lot.

    The first is that the company nchain has relicensed their fork of one full node to no longer be open source. Code that goes in there can not be copied by others, they had some rule about the code being limited to their chain only.

    The second is that the Bitcoin,com wallet was forked from another and after a year of development and getting a lot of people using their product, they stopped posting sources. They effectively made it closed source.

    Neither of these actions is possible with any of the GPL licenses. Please consider protecting your users by adopting a GPL license.

    enhancement 
    opened by zander 22
  • Add authentification to API

    Add authentification to API

    Our bitcart backend API is written in fastapi. It is located in main.py file andapi/ folder. Currently it is accessible by everyone. We should add authentification, either Token, or JWT, or some other kind of auth. Some useful links: https://fastapi.tiangolo.com/tutorial/security/intro/ https://fastapi.tiangolo.com/tutorial/security/get-current-user/ https://fastapi.tiangolo.com/tutorial/security/first-steps/ https://fastapi.tiangolo.com/tutorial/security/simple-oauth2/

    The user model is defined in schemes.py(pydantic validation for output in API), and database model in models.py. Also, when user is logged in API should be restricted to displaying only those wallets, store, products, invoices that user have. User has is_superuser value, if it is True, then all data should be displayed. If user is not superuser, users list might not be accessible at all, or there should be a new endpoint added: /users/current Or /profile Returning logged user info.

    help wanted Community decision hacktoberfest 
    opened by MrNaif2018 19
  • [FEATURE] Making contributions easier

    [FEATURE] Making contributions easier

    First of all congrats @MrNaif2018 and @xiaoxianma :tada: :rocket: it is been a long time since i glanced at Bitcart, but it looks really stable and neat right now. But i have a one concern, repository having a lack of documentation, especially for contributors, setting up environment manually and a poor CONTRIBUTING.md could be frustrating for newcomers.

    But i think it can be imrpoved easily. What do you guys think about this?

    enhancement 
    opened by ycd 9
  • Add alembic migrations to the project

    Add alembic migrations to the project

    Bitcart backend API uses gino orm(kind of orm), which is executing sqlalchemy core queries via async database driver. But there are no migrations yet, so user data might be broken if we won't add migrations. All is needed is to setup alembic with that project, and add applying migrations code somewhere in docker-entrypoint.sh. But as bitcart is using async orm, we might need to find alternate solution for that if it is possible. Also any ideas on using a better orm are appreciated. In future we might switch to edgedb at all.

    help wanted hacktoberfest 
    opened by MrNaif2018 8
  • Add alembic

    Add alembic

    #77

    opened by tomasmor42 7
  • Resolves bitcartcc#121 Get rid of namedtuples in tor extension

    Resolves bitcartcc#121 Get rid of namedtuples in tor extension

    I also changed TorService class into dataclass but I am not sure if that's what you wanted #121

    refactor 
    opened by kartecianos 5
  • Bump drf-yasg from 1.16.0 to 1.16.1

    Bump drf-yasg from 1.16.0 to 1.16.1

    ⚠️ Dependabot is rebasing this PR ⚠️

    If you make any changes to it yourself then they will take precedence over the rebase.


    Bumps drf-yasg from 1.16.0 to 1.16.1.

    Release notes

    Sourced from drf-yasg's releases.

    1.16.1

    • FIXED: fixed DRF 3.10 compatibility (#408, #410, #411)
    • IMPROVED: better enum type detection for nested ChoiceFields (#400)
    Changelog

    Sourced from drf-yasg's changelog.

    Changelog

    1.16.1

    Release date: Jul 16, 2019

    • FIXED: fixed DRF 3.10 compatibility (408, 410, 411)
    • IMPROVED: better enum type detection for nested ChoiceFields (400)

    1.16.0

    Release date: Jun 13, 2019

    • ADDED: added reference_resolver_class attribute hook to SwaggerAutoSchema (350)
    • ADDED: added operation_keys attribute to SwaggerAutoSchema, along with __init__ parameter (355)
    • FIXED: fixed potential crash on issubclass check without isclass check

    1.15.1

    Release date: Jun 13, 2019

    • IMPROVED: updated swagger-ui to version 3.22.3
    • IMPROVED: updated ReDoc to version 2.0.0-rc.8-1
    • FIXED: fixed an issue with inspection of typing hints on Python 2.7 (363)
    • FIXED: fixed an issue with inspection of typing hints on Python 3.7 (371)

    Python 3.4 support has been dropped!

    1.15.0

    Release date: Apr 01, 2019

    • ADDED: added is_list_view and has_list_response extension points to SwaggerAutoSchema (331)
    • IMPROVED: updated swagger-ui to version 3.22.0
    • IMPROVED: updated ReDoc to version 2.0.0-rc.4
    • FIXED: ListModelMixin will now always be treated as a list view (306)
    • FIXED: non-primtive values in field choices will now be handled properly (340)

    1.14.0

    Release date: Mar 04, 2019

    • IMPROVED: updated swagger-ui to version 3.21.0
    • FIXED: implicit ref_name collisions will now throw an exception
    ... (truncated)
    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Note: This repo was added to Dependabot recently, so you'll receive a maximum of 5 PRs for your first few update runs. Once an update run creates fewer than 5 PRs we'll remove that limit.

    You can always request more updates by clicking Bump now in your Dependabot dashboard.

    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot ignore this [patch|minor|major] version will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it). To ignore the version in this PR you can just close it
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
    • @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

    Additionally, you can set the following in your Dependabot dashboard:

    • Update frequency (including time of day and day of week)
    • Pull request limits (per update run and/or open at any time)
    • Out-of-range updates (receive only lockfile updates, if desired)
    • Security updates (receive only security updates, if desired)

    Finally, you can contact us by mentioning @dependabot.

    dependencies 
    opened by dependabot-preview[bot] 4
  • Bump gunicorn from 19.9.0 to 20.0.0

    Bump gunicorn from 19.9.0 to 20.0.0

    Bumps gunicorn from 19.9.0 to 20.0.0.

    Commits

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language
    • @dependabot badge me will comment on this PR with code to add a "Dependabot enabled" badge to your readme

    Additionally, you can set the following in your Dependabot dashboard:

    • Update frequency (including time of day and day of week)
    • Pull request limits (per update run and/or open at any time)
    • Out-of-range updates (receive only lockfile updates, if desired)
    • Security updates (receive only security updates, if desired)
    dependencies 
    opened by dependabot-preview[bot] 3
  • Store invoice paid currency on successful checkout

    Store invoice paid currency on successful checkout

    Currently, when invoice is paid, there is no way to check in what currency customer has paid. A new paid_currency field should be added, which will be filled in in tasks.py on successful checkout. This also requires an edit to invoice page headers in admin panel to add a new field

    enhancement good first issue 
    opened by MrNaif2018 3
  • Bump pip-tools from 5.5.0 to 6.0.1 in /requirements/deterministic

    Bump pip-tools from 5.5.0 to 6.0.1 in /requirements/deterministic

    Bumps pip-tools from 5.5.0 to 6.0.1.

    Release notes

    Sourced from pip-tools's releases.

    6.0.1

    Bug Fixes:

    • Fixed a bug with undeclared dependency on importlib-metadata at Python 3.6 (#1353). Thanks @​atugushev

    Dependencies:

    6.0.0

    Backwards Incompatible Changes:

    Features:

    Bug Fixes:

    • Fix a bug where pip-compile with setup.py would not include dependencies with environment markers (#1311). Thanks @​astrojuanlu
    • Prefer === over == when generating requirements.txt if a dependency was pinned with === (#1323). Thanks @​IceTDrinker
    • Fix a bug where pip-compile with setup.py in nested folder would generate setup.txt output file (#1324). Thanks @​peymanslh
    • Write out default index when it is provided as --extra-index-url (#1325). Thanks @​fahrradflucht

    Dependencies:

    Changelog

    Sourced from pip-tools's changelog.

    6.0.1 (2021-03-15)

    Bug Fixes:

    • Fixed a bug with undeclared dependency on importlib-metadata at Python 3.6 (#1353). Thanks @​atugushev

    Dependencies:

    6.0.0 (2021-03-12)

    Backwards Incompatible Changes:

    Features:

    Bug Fixes:

    • Fix a bug where pip-compile with setup.py would not include dependencies with environment markers (#1311). Thanks @​astrojuanlu
    • Prefer === over == when generating requirements.txt if a dependency was pinned with === (#1323). Thanks @​IceTDrinker
    • Fix a bug where pip-compile with setup.py in nested folder would generate setup.txt output file (#1324). Thanks @​peymanslh
    • Write out default index when it is provided as --extra-index-url (#1325). Thanks @​fahrradflucht

    Dependencies:

    Commits
    • f49b3fa Merge pull request #1354 from atugushev/release-6.0.1
    • ad2f308 6.0.1 changelog
    • 079058f Declare pep517 dependency (#1353)
    • 3fa72d0 Enable disallow_untyped_defs for mypy (#1350)
    • 852edf8 6.0.0 changelog
    • 77aa19b Add typings for the scripts.compile module (#1322)
    • 20d873d Fix a bug where pip-compile setup.py would fail with URL deps (#1347)
    • fe6dd97 Prefer dict over OrderedDict
    • 264cc84 Remove unused PyPIRepository cache directories
    • 866afb6 Complete type hinting of piptools.repositories package
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    dependencies 
    opened by dependabot[bot] 3
  • Migrate tests to anyio

    Migrate tests to anyio

    null

    opened by MrNaif2018 0
  • Setup tests parallelization with pytest-xdist

    Setup tests parallelization with pytest-xdist

    Our test suite is independent, each test can work on a empty db assuming tables were created. It wasn't always so. Before tests were running fast but were unreliable. Now they are reliable but a bit slow. We could parallelize the test execution with pytest-xdist. The only requirement is that each distributed worker needs it's own database. This means we need to switch database used during tests, so maybe some refactor is needed, see #247

    See this comment about how approximately this should work. Test database should be created only once, and worker databases are created from main (empty) test db as a template. This will be fast. Of course after tests databases need to be cleaned up (note: we don't need posix ipc use as in the comment, just the approximate flow of db creation)

    enhancement help wanted hacktoberfest 
    opened by MrNaif2018 0
  • Refactor the code to initialize event loop only from async functions

    Refactor the code to initialize event loop only from async functions

    The time has come. Python 3.10 is released which means that our old ways won't work, and new event loop would be created always. Recently our tests got broken because of fastapi 0.69.0 release, which uses anyio. We had many issues with too many concurrent operations in progress because of event loop mismatch, and are using some workarounds in pytest-asyncio to make everything use same event loop: https://github.com/bitcartcc/bitcart/blob/ac129fae929d0853137d327762ef7750537627b6/tests/conftest.py#L32-L34 https://github.com/bitcartcc/bitcart/blob/ac129fae929d0853137d327762ef7750537627b6/tests/conftest.py#L38 https://github.com/bitcartcc/bitcart/blob/ac129fae929d0853137d327762ef7750537627b6/tests/conftest.py#L44

    SDK might need to be refactored as well. settings.py should be refactored to a class, most initialization might be moved to other files, possibly Worker class could be introduced to initialize worker.py. Adding new scheduled tasks system could be refactored as well. redis pool and other connections need to be created on startup from async functions, not on import. Test suite workarounds should be removed and it should just work If everything works then we can probably remove asyncio.get_event_loop().run_until_complete in favour of asyncio.run

    bug enhancement help wanted hacktoberfest refactor release-blocker 
    opened by MrNaif2018 2
  • [BUG] SMTP notifications not working - port number interpreted as string instead of integer

    [BUG] SMTP notifications not working - port number interpreted as string instead of integer

    Describe the bug When using e-mail notification provider I got an error and no notifications sent.

    To Reproduce Steps to reproduce the behavior:

    1. Create a store,

    2. Add notification provider "email" with a custom mail server. My settings: Zrzut ekranu z 2021-10-05 15-49-23

    3. Make a purchase, go through checkout,

    4. The invoice changes to confirmed but the interface still waits for payment,

    5. There's a traceback in the log informing about notifiers error Error with sent data: '465' is not of type 'integer' apparently the port is taken as a string instead od as an int.

    Expected behavior Should have sent a notification and proceed with a success info

    Log

    2021-10-05 13:39:02,291 - [PID 17] - api.crud.invoices.create_invoice [line 20] - DEBUG - {'created': datetime.datetime(2021, 10, 5, 13, 39, 2, 274624), 'price': Decimal('0.1'), 'store_id': 'LTgKBHWfOBrQzRHWKUngyvdUDfdWVDyA', 'currency': 'mXRG', 'paid_currency': '', 'order_id': '', 'notification_url': '', 'redirect_url': '', 'buyer_email': '[email protected]', 'promocode': None, 'discount': None, 'status': 'pending', 'products': {'QKHVqXkmSCtseYBSpDeIpm': 1}}
    2021-10-05 13:39:02,346 - [PID 17] - api.crud.invoices.update_invoice_payments [line 123] - INFO - Started adding invoice payments for invoice VwKndOcShzfnNpQKKOxXQJ
    2021-10-05 13:39:02,400 - [PID 17] - api.crud.invoices.update_invoice_payments [line 133] - INFO - Successfully added 1 payment methods to invoice VwKndOcShzfnNpQKKOxXQJ
    2021-10-05 13:39:16,277 - [PID 1] - api.invoices.update_status [line 220] - INFO - Updating status of invoice VwKndOcShzfnNpQKKOxXQJ with payment method XRG to paid
    2021-10-05 13:39:16,302 - [PID 1] - api.invoices.update_status [line 220] - INFO - Updating status of invoice VwKndOcShzfnNpQKKOxXQJ with payment method XRG to complete
    2021-10-05 13:39:16,312 - [PID 1] - api.invoices.invoice_notification [line 173] - INFO - Invoice VwKndOcShzfnNpQKKOxXQJ complete, sending notifications...
    2021-10-05 13:39:16,323 - [PID 1] - api.utils.templates.get_template [line 28] - INFO - Template matching "notification" for store LTgKBHWfOBrQzRHWKUngyvdUDfdWVDyA: selected default template
    2021-10-05 13:39:16,339 - [PID 1] - api.utils.logging.log_errors [line 14] - ERROR - 
    Traceback (most recent call last):
      File "/app/api/utils/logging.py", line 12, in log_errors
        yield
      File "/app/api/invoices.py", line 132, in new_payment_handler
        await process_electrum_status(invoice, method, xpub, status)
      File "/app/api/invoices.py", line 111, in process_electrum_status
        await update_confirmations(invoice, method, confirmations=0)  # to trigger complete for stores accepting 0-conf
      File "/app/api/invoices.py", line 143, in update_confirmations
        await update_status(invoice, status, method)
      File "/app/api/invoices.py", line 223, in update_status
        await invoice_notification(invoice, status)
      File "/app/api/invoices.py", line 175, in invoice_notification
        await utils.notifications.notify(store, await utils.templates.get_notify_template(store, invoice))
      File "/app/api/utils/notifications.py", line 27, in notify
        notifiers.notify(provider.provider, message=text, **provider.data)
      File "/usr/local/lib/python3.7/site-packages/notifiers/core.py", line 365, in notify
        return get_notifier(provider_name=provider_name, strict=True).notify(**kwargs)
      File "/usr/local/lib/python3.7/site-packages/notifiers/core.py", line 303, in notify
        data = self._process_data(**kwargs)
      File "/usr/local/lib/python3.7/site-packages/notifiers/core.py", line 235, in _process_data
        self._validate_data(data)
      File "/usr/local/lib/python3.7/site-packages/notifiers/core.py", line 208, in _validate_data
        raise BadArguments(validation_error=msg, provider=self.name, data=data)
    notifiers.exceptions.BadArguments: Error with sent data: '465' is not of type 'integer'
    

    Desktop:

    • OS: Linux
    • Version BitcartCC v0.6.0.1
    bug help wanted hacktoberfest 
    opened by KarolTrzeszczkowski 1
  • Add theme_settings to stores

    Add theme_settings to stores

    As we are going to implement theming support in BitcartCC store, see bitcartcc/bitcart-store#319, we need to extend the API to allow storing css url. CSS url for the theme is just an url which will be loaded by the frontend. Ideally in the future we will allow to host css right on the server and use a permanent link to server storage, for that #161 and file storage support should be implemented, but that's for another issue To add theme_settings, we need a new JSON field for Store model. https://github.com/bitcartcc/bitcart/blob/712d7ffb829cfee517ffa95c056ab37310870a85/api/models.py#L266-L270 it should be marked as json field for our validators, see how checkout_settings field is implemented and referenced for guide on how to add it A new scheme should be added, which will only have store_theme_url and admin_theme_url variables (type str)

    After that, admin panel should be updated to allow editing new field. https://github.com/bitcartcc/bitcart-admin/blob/05350eac9daa926649aba3ab4d200b8ebdc0fa22/pages/stores.vue#L31-L41 Add it in a similar way to checkout_settings, with a new icon.

    enhancement good first issue hacktoberfest 
    opened by MrNaif2018 0
  • Hacktoberfest welcome

    Hacktoberfest welcome

    This month Hacktoberfest is held! We welcome all new and existing contributors, this issue is a list of all issues from BitcartCC projects (new features, bug fixes, etc.) If you have any questions regarding the project, open an issue on github or contact us in our communities. More information on the project itself is available on our official website and documentation

    We now have our roadmap set up for long-term BitcartCC development. You can check the issue lists from the roadmap and try implementing some of the tasks from them. Each task in a tasklist can be done in a separate PR, there are lots of things to do! The descriptions in the list are not always complete, if you want to start working on some feature and want a detailed explanation, comment on the selected task list and I will open a separate issue describing that task.

    Issue list:

    bitcart repository:

    • [ ] #247
    • [ ] #251
    • [ ] #105
    • [ ] #152
    • [ ] #160
    • [ ] #161
    • [ ] #162
    • [ ] #163
    • [ ] #164
    • [ ] #165
    • [ ] #166
    • [ ] #167
    • [ ] #168
    • [ ] #169
    • [ ] #174
    • [ ] #218
    • [ ] #235
    • [ ] #242
    • [ ] #244

    bitcart-admin repository:

    • [ ] Admin issue list bitcartcc/bitcart-admin#120

    bitcart-store repository:

    • [ ] Store issue list bitcartcc/bitcart-store#317

    bitcart-site repository:

    • [ ] Site issue list bitcartcc/bitcart-site#84

    bitcart-blog repository:

    • [ ] Blog issue list bitcartcc/bitcart-blog#111

    bitcart-docs repository:

    • [ ] Docs issue list bitcartcc/bitcart-docs#5
    enhancement help wanted good first issue hacktoberfest 
    opened by MrNaif2018 0
  • Plugins support

    Plugins support

    To make BitcartCC core light but be able to add any functionality, we need a plugin system

    Plugins should be able to customize almost everything: add new routes, possibly new database tables via migrations, new background tasks, new worker events, maybe register new templates/scripts and their settings. All of that is modifying existing merchants api code. Some plugins might need to add new UI features: this means modifying separate admin and store containers. With our separation of services it might be non-trivial to add plugins support. Plugins will probably be separated by a few types: backend plugins (extending merchants API), UI plugins (extending admin or store), service plugins (adding completely new services running in one-domain mode under some URL) and mixed plugins which could contain all previous types.

    Plugins must have their version set, name, description, and a set of requirements. Plugins may have requirements for BitcartCC version, if version doesn't match, plugin code shouldn't be loaded at all (so metadata should be separate from plugin code). Plugins might have specific library dependencies from pypi, or even require docker-compose services. The services and other requirements are specified in the metadata file. Plugins should be packed in a standalone file, possibly just a zip archive, with .bitcartcc extension. There are two approaches we may use: 1. Zip archive with source code BitcartCC will just execute needed commands to install the plugin, that means pip installing requirements, copying service files, re-generating docker-compose, applying database migrations, running build commands like yarn build for node.js parts This is good because this will work on any architecture and will be of minimal file size, as it just contains source code Disadvantages are that we will need to somehow isolate the dependencies to not break the main app, and also that installation times may take a long time 2. Binary file This will install dependencies during pack time and then bundle it all with pyinstaller or other tools The advantages are that everything is isolated and self-contained, instant installation Disadvantages are that we will need one binary per each architecture, and also I am not sure how to import from those files

    The code might need to be refactored to allow adding new features easily

    This is a complex task, so any ideas and help welcome

    After implementing that BitCCL could be added as a plugin

    enhancement help wanted hacktoberfest 
    opened by MrNaif2018 0
  • Cleanup pydantic schemes

    Cleanup pydantic schemes

    Currently our pydantic schemes weren't revised in a while. We should re-check if some of the validators in use are actually required, and possibly replace Optional[str] to str where needed

    help wanted hacktoberfest refactor 
    opened by MrNaif2018 0
  • Configure Renovate

    Configure Renovate

    WhiteSource Renovate

    Welcome to Renovate! This is an onboarding PR to help you understand and configure settings before regular Pull Requests begin.

    🚦 To activate Renovate, merge this Pull Request. To disable Renovate, simply close this Pull Request unmerged.


    Detected Package Files

    • .circleci/config.yml (circleci)
    • cli/go.mod (gomod)
    • requirements/daemons/bch.txt (pip-compile)
    • requirements/daemons/ltc.txt (pip-compile)
    • requirements/daemons/xrg.txt (pip-compile)
    • requirements/web.txt (pip-compile)

    Configuration

    🔡 Renovate has detected a custom config for this PR. Feel free to ask for help if you have any doubts and would like it reviewed.

    Important: Now that this branch is edited, Renovate can't rebase it from the base branch any more. If you make changes to the base branch that could impact this onboarding PR, please merge them manually.

    What to Expect

    With your current configuration, Renovate will create 3 Pull Requests:

    Update all non-major dependencies Docker tags
    • Schedule: ["at any time"]
    • Branch name: renovate/all-minor-patch
    • Merge into: master
    • Upgrade cimg/go to 1.17
    • Upgrade fastapi to <0.71.0
    • Upgrade github.com/joho/godotenv to v1.4.0
    • Upgrade uvicorn to <0.15.1
    Update circleci/postgres Docker tag to v12
    • Schedule: ["at any time"]
    • Branch name: renovate/circleci-postgres-12.x
    • Merge into: master
    • Upgrade circleci/postgres to 12-alpine-ram
    Refresh pip-compile outputs
    • Schedule: ["before 5am on monday"]
    • Branch name: renovate/pip-compile-refresh
    • Merge into: master
    • Regenerate lock files to use latest dependency versions

    ❓ Got questions? Check out Renovate's Docs, particularly the Getting Started section. If you need any further assistance then you can also request help here.


    This PR has been generated by WhiteSource Renovate. View repository job log here.

    opened by renovate[bot] 2
  • Migrate to sqlalchemy instead of gino as an ORM

    Migrate to sqlalchemy instead of gino as an ORM

    We have tried to upgrade from gino to sqlalchemy 1.4, but at least as of now (April 2021), it is not worth it.

    The only benefit of sqlalchemy that gino lacked was many to many relationship management to us, but migration process have shown that sqlalchemy has more issues.

    It is possible to migrate, but we would have to rewrite half of our system, introduce dozens of breaking changes and bugs for basically almost no benefit.

    Plus, sqlalchemy 1.4 is stable, but not yet as mature as previous versions. Also, async support is in beta. Maybe when it is stable too, we will reconsider the migration.

    We won't be migrating to sqlalchemy, but if someone provides a good PR which does the migration without breaking everything and if it works great and is easy to maintain, then we will switch.

    The problems we have met with when switching which need to be solved efficiently:

    • Database session management. Where to put it? Gino had a global Gino object which managed everything correctly. We tried two ways, one from https://github.com/mfreeborn/fastapi-sqlalchemy, but adapted to async, and another is implemented like in the coming example to fastapi, via dependency: https://github.com/tiangolo/fastapi/pull/2331 First way had problems with concurrency (another operation is in progress), another one seems to be fine, only that we must move session everywhere we need it and can't easily access it like before (also a question of how to use the dependency in worker tasks for example, outside of the fastapi context, is still there)
    • Relationship management. Main issue is there. Pre-loading a one to many relation is good to have, as we often need it, but in case of many-to-many relation not really. Performance implications are there, but that's not the most important thing. When in frontend and outside backend, we just use related objects id's. Because adding in full object and passing them via API is impossible as the requester can't know the full object sometimes. And in general it is not comfortable to operate with objects instead of ids. When in backend, sometimes we access those ids and fetch exact objects. But in most cases only a list of ids is required. If we still keep our add_related functions it will work, but then what's the point of using sqlalchemy if it doesn't help with the only gino's problem we had? Plus we would still have to control precisely what to return.

    Those two problems are essential, which stopped us from continuing. There are definitely more problems which we would have discovered, like the connection management and it's garbage collection (I saw warnings in console), plus other sqlalchemy bugs which might be there.

    If someone still needs it, I left my unfinished work at sqlalchemy-1.4 branch

    enhancement help wanted hacktoberfest 
    opened by MrNaif2018 0
Releases(0.6.0.1)
  • 0.6.0.1(Sep 21, 2021)

  • 0.6.0.0(Sep 21, 2021)

    Major update

    This update contains backwards-incompatible changes

    This time we have included the changes from all BitcartCC repositories since previous version

    Breaking: unifying data directory

    The app stores all it's data in one directory instead of separate directories within source code. This makes it work without permission errors.

    With docker deployment only the datadir volume could be backed up, also it's separated from source tree now

    This removes unnecessary volume mounts in compose dir, now all data is stored in named docker volumes. Also removes conf directory mounting and many fixes applied before, as it is actually not required now

    This means that logs and images are not moved into new directory by default.

    At docker deployment bitcart_datadir volume now stores all the data, bitcart_logs volume is removed, compose/images directory and compose/conf directory are not used anymore.

    Run contrib/upgrades/upgrade-to-0600.sh upgrade helper to move your existing logs and images if you need it

    Multiarch support (ARM images now available)

    Now we build all images for 3 architectures: amd64, arm32, arm64. This allows running BitcartCC on a Raspberry Pi and other portable devices.

    We have updated all our docker components, not only main BitcartCC parts

    bitcartcc/docker-gen gained arm support, updated with upstream changes to 0.7.7

    updated bitcartcc/tor to 0.4.6.5 with arm support

    bitcartcc/docker-compose was moved to bitcartcc/bitcart-docker-deps repo and updated to 1.28.6

    Usually building images for ARM takes a while when being run in a emulation, but we found a solution:

    We build amd64 image on amd64 machine without emulation, and in the same time arm64 machine on CI builds arm64 image without emulation and arm32 image with emulation, but this emulation provides minimal performance penalties, images are built in parallel with docker buildx. After that, images are united into one tag with docker buildx imagetools, so that when pulling a release the right image gets chosen.

    So if you are on a raspberry pi, same instructions as on regular servers apply, and everything will just work.

    Backups support

    The long-awaited feature is there! All deployments now have backup.sh and restore.sh scripts performing backup and restore operations

    Example:

    BACKUP_PROVIDER=scp [email protected]:backups ./backup.sh

    On another machine with ip someip:

    ./restore.sh 20210918-220925-backup.tar.gz

    Will restore the identical state of your instance.

    You can also perform manual backups from server management->backups page by just a click of a button. Backup settings, like provider and environment variables are also configured here.

    Current supported backup providers: local (save on local machine), scp (send via ssh to any machine), s3 (send to AWS s3)

    You can also schedule backups, by default it is off. They are performed in one of selected frequencies: daily, weekly, monthly.

    The app will store the remaining time by itself even after restarts.

    All backup operations are also logged to server logs.

    Electrum 4.1 upgrade and various core daemon refactors and improvements

    This is our scheduled upgrade of electrums from 4.0 series to 4.1 series

    Breaking changes in electrum:

    • Lightning gossip is not enabled by default as before, instead trampoline routing is used. You can enable gossip back by setting COIN_LIGHTNING_GOSSIP variable to true
    • When invoice is paid, it's status is no longer Paid, but Unconfirmed. Invoice becomes Paid after first confirmation. This allows us to implement transaction_speed setting in a better way

    Important changes in electrum:

    • Deterministic lightning keys added. This means that you can't run two nodes on the same server with same seeds, because node_id would be the same. Important note: deterministic node id is enabled only for native segwit wallets created/restored from electrum seed (xprv won't work).
    • Signet support added
    • All lightning commands now have l tag, which allows us to provide better exceptions for lightning methods

    Other changes related to electrum upgrade:

    • Added tests for lightning payments to ensure they also work
    • Improved handling of invoices, query only needed statuses, removed problem with first confirmation not always appearing
    • Hide logging errors from electrum when not in debug mode
    • Disabled rpc in electrumx and also removed ignore asyncio warnings in tests
    • Implemented graceful stopping for all daemons
    • Improved fee estimates handling

    Together with electrum upgrades, BCH-based coins have gained some more feature-parity with btc-based coins:

    • Removed lockfile creation for bch, it can now run in parallel with electron cash wallet
    • Added feerate support for bch-based coins

    Important: deprecated lunanode installer

    Our lunanode installer at https://launch.bitcartcc.com is deprecated. Use BitcartCC configurator instead, it is more feature-complete and can install BitcartCC on any server. We might add some hosting provider presets to configurator in the future/ The lunanode installer will be removed with the next BitcartCC major release: 0.7.0.0. It will then redirect to the configurator.

    Many core daemons and invoice processing improvements

    • Daemon refactor: it's settings are now passed as cli args. i.e. you can't use setconfig("lightning",False) and disable lightning if it was enabled via env var
    • Added new verified_tx event, called when tx got it's first confirmation
    • Experimental: get_tx SDK method (get_transaction daemon method) now supports use_spv flag to use SPV verification for getting confirmations, this works on all electrumx servers without verbose mode errors, but it is experimental because it is inefficient, we are waiting for electrum protocol 1.4
    • Use coingecko for btc with tor as it no longer blocks tor exit nodes
    • New getaddressbalance_wallet RPC method which gets address balance via local wallet balance and not network
    • It is now possible to override daemon exception spec in other coins to extend it with custom errors So there are now two specs: base spec, by default btc.json for all coins, and the current coin spec, if used. Changing base spec may be useful for adding coins like ethereum
    • WalletNotLoadedError is now properly raised by the daemon instead of not-easy-to-understand KeyError
    • Commands which require wallet are now properly checked
    • Fixed daemon xpub parsing
    • Daemons are now properly documented
    • Now BaseDaemon contains only base code common for all daemons, like config loading, and BTCDaemon contains code for electrum-based coins, it is useful for adding completely custom coins not based on electrum
    • Fixed rare bug with event processing order for sync clients
    • Fixed issue with IPN sending on transaction_speed >= 1 and added functional tests for it

    Added new coin: XRG

    Added Ergon (XRG, port 5005) via it's electron cash fork oregano: https://ergon.moe https://ergon.moe/prop-reward.pdf

    It is a fork with BCH with stable price. It is achieved by making the block reward proportional to the cost of producing a block. Earning a single unit of the currency by mining takes a fixed amount of effort.

    SDK improvements

    • Use current package version in SDK docs
    • SDK now doesn't crash on None rates
    • Emulate asyncio.run behaviour, allow starting/stopping websockets in idle unlimited number of times
    • Better error handling, no try/except required, all errors are logged instead, load_wallet can handle currencies case-insensitively

    BitCCL improvements

    BitCCL is getting prepared for being integrated into BitcartCC in following releases.

    Better, more secure compiler It can now be used without issues even with untrusted code which tries to bypass the passed context, export only needed functions

    Quality of life improvements

    The toolbar on admin panel is now unified. On desktop the left navigation bar doesn't open anymore, as it is replaced by main toolbar. On mobile the left navigation bar is now useful and contains links for navigation (before configurator link wouldn't fit in screen) When logged in, it shows same links as before. When not logged in it shows configurator (if allowed by server policies), login and register buttons Datatables are more responsive too now

    Other improvements:

    • Display fiat currency in balance stats instead of ephermal sum of balances, it is configurable in the profile page
    • Support for custom payment methods labels, this is configurable via label field of a wallet
    • Better reponsibility on mobile

    BitcartCC CLI is now included in docker deployments

    You can access it with bitcart-cli.sh script, like so:

    ./bitcart-cli.sh help

    It requires a running worker container

    Maintenance and other improvements

    • We have disabled dependabot (spammy) on all our repositories and enabled renovate instead. https://github.com/bitcartcc/renovate-config is our global config repository
    • Many improvements to circleci pipeline: now test results and artifacts are uploaded
    • Install bitcoind from PPA in CI for tests to improve build times greatly
    • Integrate pre-commit for better contribution experience, and to modernize and unify our codebase
    • https://github.com/bitcartcc/bitcartcc-orb created to reduce duplication across our repos, can be used by others in circleci to efficiently build multiarch images and not only that
    • Updated to Node 14 LTS in node-based images
    • Many package upgrades, fixing some security issues found in them
    • Added new tor-relay component allowing you to run your own tor relay as part of bitcartcc deployment and to support tor network
    • Our go cli now supports specifying custom daemon url instead of defaults, uses our spec to show more readable exception messages and is built by our CI now
    • Fix invoice products access control security issue
    • We now use batch inserts where possible to improve performance on e.g. stores with many wallets connected
    Source code(tar.gz)
    Source code(zip)
  • 0.5.0.0(Jun 4, 2021)

    Major update

    This update contains many backwards-incompatible changes

    This update is the biggest of all the time, with over 5000 line additions and deletions, more than 121 files changed.

    It has finished most of the parts of our Backend Improvements in our roadmap.

    There are lots of internal improvements, not all changes are user-facing, but there are lots of critical bug fixes and quality improvements.

    This update also fixes some not very critical, but security issues, upgrade is recommended to everyone.

    This update starts the era of refreshed, lighter and better BitcartCC. New features should now be added way faster due to amount of work done on improving maintenance work

    There should be no action required to upgrade, everything will be performed automatically. If it has failed, please let us know.

    This changelog contains quite a bit of additional technical information than usual due to the nature of this update.

    Major refactor of all our backend code

    We have re-organized all our code into their corresponding directories, so it is now less cluttered, even more readable and easier to add new features (i.e. crud.py into crud directory, utils.py into utils directory, utils are now split into files by their category)

    All the endpoints were re-organized into logical sub-urls. See breaking changes below for more information on how to migrate.

    Improved texts handling in the database

    All imports now use absolute names, code is more readable

    Added new utilities for database management and made all the code use it, it will allow easier database access from plugins (to be added later) and scripts.

    This allowed us to greatly reduce code duplication, and in the process we found and fixed many bugs.

    For example, loading related invoice's products, or store's wallets and notifications is now done automatically, as well as updating references in the database. Before it was duplicated and had some bugs.

    As all database access is now done by those functions, in the future we may add additional events or logs for those queries to be used by scripts

    In the future those refactors will allow us to batch insert needed data, greatly improving performance for stores with many wallets connected, for example

    Test suite rewriten from scratch, new regtest tests added

    Our test suite was rewritten from scratch, now each test doesn't depend on each other, which means that our tests are fully correct and can't pass while some issue still exists.

    So now if one test fails the whole test suite doesn't fail with it together.

    Improved tests helped us indentify many bugs.

    We now have added regtest functional tests which help us test the pay flow, here's how it is done:

    We run tests in an isolated environment (fresh database) in regtest network

    The test creates a store, then sets transaction_speed (we test all variants), creates an invoice, pays it from the full node

    Beforehand it starts a simple http server, sets notification_url to that server's url. Server on POST request just sends it's message later on, and then we check that two IPNs were sent in each case: paid status, and complete status

    That way the whole payment processing workflow is now tested

    We now test invoice response structure (i.e. payment methods) better

    We now test different validation we have better

    Improved CI testing process, it is now possible to publicly view test reports by anyone

    Our SDK is now tested in 3 python versions instead of one, with regtest tests running on the base BitcartCC version (currently python 3.7)

    Breaking: Unique string ID

    Now all objects IDs are strings.

    All previous IDs will remain the same.

    Newly generated IDs will be generated from a cryptographically secure source.

    This change is breaking, but has been requested for a while, because it greatly improves privacy. It is no longer possible to sequentically scan for all wallet's addresses by opening checkout pages with IDs from 1 to N. It is also not possible to know the exact number of invoices on an instance.

    Object id length is 22 for invoices and products, and 32 for other products.

    As IDs are now longer than few characters, in the admin panel, for object ids with length > 22 they will be truncated and it will be possible to copy them on click

    Payment methods order is now fully guaranteed by having a created date, existing data should be migrated automatically (but the created date of existing methods will not match the actual date)

    As All object IDs are now strings, not integers, you should remove integer checks and conversions in your calls to API.

    Existing ids will be returned as strings, so instead of id 42 you will receive id "42"

    All upgrades should be performed automatically

    As unique id is now in place, existing deployments will be unaffected, but on new deployments, the first created store by server admin becomes the default store at the store POS. Before that, store POS displays no store.

    Important security fixes

    Before it was possible to create a store with wallets current user doesn't own from API. It didn't leak privacy, but that was allowed. This issue is now fixed.

    There was added a check that ensures that all related objects (i.e. wallets connected to store, products connected to invoice, etc) are owned by the current user.

    Otherwise, a HTTP 403 Forbidden code is returned and operation is cancelled.

    Also, it was possible to create products on store current user does not own, and other similar issues. Unfortunately there were quite a lot of such.

    All access control issues were fixed, upgrade is recommended.

    We try our best to build the most secure software possible, but we need your help. The bigger our community becomes, the more developers will be available to audit our code and help us identify some issues quickly.

    As sometimes it's hard to find unpredictable behaviour in your own code.

    Tests were added to proove that no such issues will arise in the future.

    Quality of life improvements

    • Improved PATCH methods: to update objects from API no fields are required, there is no need to pass unnecessary fields (user_id, wallets) to just change store's name for example! Before it was impossible to update objects from API without additional API call to fetch those requires fields. Some fields required weren't required even on object creation. This shouldn't be an issue now.
    • Added IPN sending logs: on success it will say that sending IPN succeeded, otherwise it will log an error message to help diagnose issues
    • Added better pagination in admin panel to easily navigate between pages. The pagination buttons allow you to jump to the first, last page and some pages inbetween instead of constantly clicking "next" button.

    Breaking: removed PUT http method

    We have Removed PUT http methods because they weren't used and not tested enough, therefore they could lead to unexpected issues if used.

    Also see the PATCH method improvements

    Breaking: renamed endpoints

    Due to our refactors and re-organization, here's a list of renamed endpoints:

    /rate -> /cryptos/rate

    /fiatlist -> /cryptos/fiatlist

    /categories -> /products/categories

    /services -> /tor/services

    /updatecheck -> /update/check

    /crud/stats -> /users/stats

    /wallet_history -> /wallets/history

    Note: it is no longer possible to open /wallets/history/0 to get wallet history for all wallets on your account, added a new endpoint for that:

    /wallets/history/all

    Misc changes

    • Fixed search in admin panel in pages other than invoices page
    • Fixed objects template editing
    • Better logo rendering in dark mode
    • New SDK method: get_invoice to get lightning invoice data
    • Fixed rare bug with error on editing store checkout settings
    • Fixed an issue with wallet's xpub validation not always running when creating from API
    • PATCH: fixed issues with modifying store checkout settings from API, changes only changed settings, others remain unaffected (before they were reset to defaults)
    • Disallowed modifying invoice products after creation
    • When creating notification providers, we now validate that notification provider selected is supported, otherwise the operation is cancelled (to avoid issues with not-existing providers on invoice completion)
    • Fixed policies update endpoints' returning incorrect response data (fields not updated) sometimes
    • Fixed an issue where /wallet_history returned wallet history of all wallets on a server, not of current user
    • Fixed bitcart-cli builds
    Source code(tar.gz)
    Source code(zip)
  • 0.4.0.0(Apr 6, 2021)

    Major update

    This update contains backwards-incompatible changes

    Changing current instance's settings via admin panel

    It is now possible to change current instance's settings via admin panel's configurator.

    Editing current instance settings (and pre-loading them via configurator) is only available to server admins.

    By clicking on current instance mode, if you are server admin, your current settings will be loaded and filled in the form fields.

    The app will automatically connect to your server via SSH and apply new settings.

    Note: it is not possible to view deployment log when updating your current instance, as the process performing the update gets restarted.

    Note: for that to work you should have working SSH support, see below.

    Note that even though configurator should fit most use cases, if you are not using one-domain mode, or if you have some completely custom and complex use-case, possibly involving multiple deployments on the same server, you should better use setup scripts from CLI.

    Breaking: SSH support in setup scripts

    Old method of executing commands on the host (for maintenance purposes, like updating the server) is no longer used.

    It means that there will be no listener process started anymore.

    Instead, both maintenance commands and configurator's current instance mode use SSH support.

    When running ./setup.sh, BitcartCC configures itself to use system host keys.

    On first startup, it generates an SSH key, and adds it to the list of trusted keys in the host (usually ~/.ssh/authorized_keys)

    That way, it can connect to the host via ssh, which is a way better way of executing commands, which opens doors to new possibilities.

    Note: SSH support is only enabled when BITCART_ENABLE_SSH is set to true, by default it is so.

    Note: SSH support requires an ssh server (openssh-server/sshd) to be running on the host machine.

    IMPORTANT: For existing deployments, after updating, for future updates to work, you will need to re-run ./setup.sh

    Many improvements in the configurator

    In Remote deployment mode, there is now a button "Load settings", which will connect to the server via SSH and fill in it's settings in the form fields.

    Configurator should now be responsive and look better on mobile devices.

    Configurator now removes stale tasks data from redis (if it was created more than a day ago).

    Other improvements

    • Fix cleanup command
    • Fix bugs in configurator
    • Improve wallet loading logic in BitcartCC Core daemons
    • Added support for build-time environment variables to docker-compose generator
    • Maintenance updates for dependencies
    Source code(tar.gz)
    Source code(zip)
  • 0.3.1.1(Mar 9, 2021)

  • 0.3.1.0(Mar 7, 2021)

    BitcartCC Configurator now supports installing to remote servers via ssh!

    Added restart server management command

    Added ability to make email optional on store POS

    Improved additional components handling in the docker deployment, and added ability to preview settings

    Fixed stats refresh in the admin panel

    Made the tor services page more clear

    Source code(tar.gz)
    Source code(zip)
  • 0.3.0.1(Feb 27, 2021)

  • 0.3.0.0(Feb 21, 2021)

    Major update

    This update contains backwards-incompatible changes

    Completely improved docker deployment

    We now test if deployment works in our automated systems, so that it will always work

    Set up formatting and proper linting

    Major improvements to the setup scripts:

    New scripts:

    • restart.sh, to restart the server
    • changedomain.sh, to change domain (usage: ./changedomain.sh newdomain.tld)

    Added more validation to setup.sh (i.e. it is not possible to enter an invalid host anymore)

    Added ability to change the root path where service is running by setting BITCART_SERVICE_ROOTPATH (i.e. BITCART_STORE_ROOTPATH)

    Added new settings to configure nginx reverse proxy:

    • REVERSEPROXY_HTTP_PORT - the http port nginx is running on (default 80)
    • REVERSEPROXY_HTTPS_PORT - the https port nginx is running on (443)
    • REVERSEPROXY_DEFAULT_HOST - the host to be served by default from server ip (default: none)

    Overall generator refactor

    One domain support

    Existing deployments will be unaffected.

    If reverse proxy is enabled and BITCART_ADMIN_HOST and BITCART_STORE_HOST and BITCART_ADMIN_API_URL and BITCART_STORE_API_URL are all unset, one domain mode is enabled.

    For one domain mode, only one setting is used: BITCART_HOST.

    It will determine the only domain bitcartcc will run on.

    The 3 main services will run under different routes.

    There is a root service, running at domain root. The root service is selected in the following order (if available): store, admin, api

    By default, assuming BITCART_HOST was bitcart.local:

    • the store will run on bitcart.local
    • admin on bitcart.local/admin
    • api on bitcart.local/api

    Everything will be configured to work on one domain.

    To enable one domain mode for existing deployments:

    unset BITCART_ADMIN_HOST
    unset BITCART_STORE_HOST
    unset BITCART_ADMIN_URL
    unset BITCART_STORE_URL
    ./setup.sh
    

    Breaking change to improve readability

    The following environment variables were renamed to reduce confusion:

    • BITCART_ADMIN_URL -> BITCART_ADMIN_API_URL
    • BITCART_STORE_URL -> BITCART_STORE_API_URL
    • BITCART_ADMIN_ONION_URL -> BITCART_ADMIN_API_ONION_URL
    • BITCART_STORE_ONION_URL -> BITCART_STORE_API_ONION_URL

    Please set them in order for your deployment to work

    BitcartCC Configurator

    This release included an alpha version of BitcartCC Configurator.

    For now only manual deployment is supported.

    BitcartCC Configurator is an application in your admin panel, allowing to install new BitcartCC instances (via ssh or manual generated script) and to re-configure them with ease.

    Just enter needed settings and you will get a copiable script.

    By default it can be accessed by anonymous users.

    Added a new server policy to make it available for authorized users only (default: False)

    Source code(tar.gz)
    Source code(zip)
  • 0.2.3.1(Feb 12, 2021)

  • 0.2.3.0(Feb 11, 2021)

  • 0.2.2.0(Feb 7, 2021)

    This release is mostly a bugfix release, but with a few new features too.

    Full invoice tasks handling refactor

    Now there is only one expired task created for an invoice, instead of N (where N is the number of payment methods).

    It means that BitcartCC should use less RAM, and also there will be less edge cases and duplicate IPN sent.

    Also, to handle some rare cases if gunicorn workers are restarting, we have changed the way background tasks are handled.

    Technical details: The idea is to make every background task, and every asyncio task run in background worker, and not gunicorn ones.

    Background worker listens on a redis channel for events, and gunicorn workers publish messages to the channel. Worker parses messages and executes event handlers in separate asyncio tasks.

    Fixed local deployment

    Now local deployment via .local domains works as before, and it now modifies /etc/hosts in a clever way, avoiding duplicate entries

    Other changes

    • Admin panel now displays a helpful message when invoice has no payment methods connected
    • Fixed recommended fee in case it's unavailable.
    • Tor extension now doesn't log always, instead it logs only warnings if something was misconfigured.
    • Fixed IPN sending
    • Fixed logging in docker environment
    • Fixed pagination for id 0
    • Added ability to change fiat currency used in the /rate endpoint
    • Fixed websockets' internal channel ids clash sometimes
    Source code(tar.gz)
    Source code(zip)
  • 0.2.1.1(Jan 24, 2021)

  • 0.2.1.0(Jan 23, 2021)

    Fix image uploading

    Allow decimal values for underpaid_percent

    Multiple stores on one store POS instance - new /store/{id} URLs added to serve any store

    Default store served is still configured by server policies

    Source code(tar.gz)
    Source code(zip)
  • 0.2.0.2(Jan 22, 2021)

  • 0.2.0.1(Jan 22, 2021)

  • 0.2.0.0(Jan 22, 2021)

    Major update

    This update contains numerous changes, some of which are not backwards-compatible

    New payment statuses

    This update completely changes our status system, by adding new statuses: paid and confirmed.

    Pending status was renamed to pending

    New store setting, transaction_speed added, which controls when should invoice be marked as complete

    New transaction flow:

    Invoice created -> pending

    Payment received -> paid

    Payment has >= 1 confirmation -> confirmed

    Payment number of confirmations is >= transaction_speed of the store OR it is a lightning invoice -> complete

    Payment expired -> expired

    If payment was detected within the invoice time frame, and the payment expired, it won't be set to expired but instead wait for confirmations.

    For more details read this: https://docs.bitcartcc.com/guides/transaction-speed

    A lot of new store checkout settings

    • Underpaid invoices support. For example, if customer sends from an exchange wallet, it might deduct the fees from amount sent. This way you can accept customer's invoice.

      More details here

    • Custom logo support. Details

    • Dark mode support. Details

    • Recommended fee support. Recommended fee will be displayed in all onchain payments methods. Details

    Multiple wallets of the same currency support

    Before, it was disallowed to create an invoice with multiple wallets of the same currency (only one was picked).

    Now it is allowed, and in the checkout, payment methods will be indexed. For example, if you have 2 btc and 2 ltc wallets connected with lightning enabled, here's how it would look:

    • BTC (1)
    • BTC (⚡) (1)
    • BTC (2)
    • BTC (⚡) (2)
    • LTC (1)
    • LTC (⚡) (1)
    • LTC (2)
    • LTC (⚡) (2)

    A new name attribute was added to PaymentMethod's structure, which contains pre-formatted payment method name ready for display

    Maintenance

    All dependencies of packages has been upgraded, and two maintenance releases were made: of SDK, to make new release with a new license, and of BitCCL, to fix it's use together with SDK 1.0

    Quality of life improvements

    • By pressing enter in the edit dialog, it will be automatically saved (like in login page, enter to login)
    • Added new mark complete batch action, to be able to mark some invoices complete manually. All notifications, emails and scripts will be executed.
    • Added filters to admin panel, it is now possible to easily filter out paid or invalid invoices

    Misc changes

    • Fixed payment methods order being inconsistent sometimes
    • Fixed scrollbars in checkout page being shown on different screen resolutions
    • Tor extension logs are now DEBUG level instead of INFO (less log spam)
    • Fixed patch/put methods, it is now possible to completely disconnect notifications from store
    • Fixed stale expired invoices occuring in rare cases
    Source code(tar.gz)
    Source code(zip)
  • 0.1.0.2(Jan 3, 2021)

    Fixed html template rendering and product price is now properly formatted when using it in templates Fixed UI issues with the new checkout in Firefox. Details are now displayed differently in admin panel: The name of the field is on one line, and the actual data on the next line. Template's text is now hidden into item details.

    Source code(tar.gz)
    Source code(zip)
  • 0.1.0.1(Dec 25, 2020)

  • 0.1.0.0(Dec 25, 2020)

    Major update

    This update contains numerous changes, some of which are not backwards-compatible

    Lightning network checkout

    Lightning has been supported in BitcartCC Core Daemons for a long time, but not in our payment methods.

    Now BitcartCC fully supports Lightning Network as a checkout method too!

    Lightning Network is supported via BitcartCC daemons's lightning mode.

    It means that, there is still no need to install additional software, lightning is enabled just by one setting.

    To enable lightning, just run:

    export COIN_LIGHTNING=true
    

    For each COIN (i.e. BTC, LTC) where you want to enable lightning support.

    It will start a lighning gossip in the daemon, and enable the ability to perform lightning operations.

    Lightning is currently only supported in native segwit wallets (electrum implementation limitation).

    To enable lightning, visit wallets page, click on lightning icon, read all the warnings displayed.

    Currently there are lots of limitations and issues in the Lightning Network itself, and the Electrum implementation, so proceed only if you understand that you may risk losing your funds, as Lightning Network is experimental.

    But if you agree, press the green button, and lightning in the wallet will be enabled.

    Lightning network is supported individually in each wallet, so even non-admin users can utilize it!

    Each wallet can be considered an individual lightning node, or, better said, an account on the same lightning node.

    So for each wallet you will have to open new lightning channels.

    As lightning implementation is built-in in BitcartCC, it is not possible to use other implementations, and you will have to open channels from scratch.

    Please read the warning in the admin panel for more details.

    When enabled, and when creating an invoice, along with the regular currency checkout method, a lightning one will be created too.

    On checkout, the customer will be able to scan/copy lightning invoice, and your node id, if they need to open a channel with you.

    When paid, instantly you will see that invoice has been paid.

    As every wallet is a fresh node, you will need a way to manage your lightning channels.

    If you click on lightning icon near the wallet again, you will see a lightning management page.

    It will display your lightning balance, node id and your lightning channels.

    You are able to close or force-close channels from there.

    Also you can open a new lightning channel or pay an lightning invoice from your lightning node in that same page.

    When invoice has been paid, you will see the paid currency will have the lightning icon near it.

    Also, all paid currencies are now upper-case, your existing data will be migrated.

    To support lightning network, invoice data returned from API was changed.

    payments key is now a list, and not a dictionary.

    There are other changes to the API, please read the other release features below.

    Also, new endpoints were added:

    • /wallets/{wallet_id}/checkln endpoint to check if lightning is supported for a wallet. Returns False if not supported, node id otherwise

    • /wallets/{wallet_id}/channels endpoint, returning wallet's lightning channels

    • /wallets/{wallet_id}/channels/open endpoint, allowing to open a new lightning channel

    • /wallets/{wallet_id}/channels/close endpoint, allowing to close a lightning channel

    • /wallets/{wallet_id}/lnpay, allowing to pay a lightning invoice from your lightning node

    To support lightning network, the daemon now has a new method: get_invoice, to get invoice by it's rhash.

    Improved checkout page

    To support lightning, as there are now even more checkout methods, will have listened to your suggestions, so now, currency selection is not tab-like, but it's a select list.

    Changed the checkout modal layout, now it is more minimalistic and takes less space.

    The exchange rate is now displayed in a pretty rate, and formatted correctly.

    Added open in wallet button, which should launch user's application to automatically paste all the details to perform a payment.

    Instead of displaying qr code and texts at once, and, considering that lightning invoices are big, we now have split the checkout into two tabs: Scan and Copy.

    Scan tab will show a qr code

    and Copy tab will display the texts, but as lightning invoices are long, it will display only parts of it, and by clicking on the fields, the full text will be copied

    When on a lightning payment method, you will be able to switch between lightning invoice qr code and node id qr code.

    The checkout page in the store was changed in a similar way.

    Added help texts to some fields

    To help newcomers, some special fields now have a question mark icon near them, by clicking on which, user will be redirected to our docs.

    It should help to understand some basics without asking, right from your instance.

    Added ID field everywhere

    As requested, ID field was added to each datatable. It was possible to copy id before by clicking on copy icon, but now it's also displayed as a field

    Better money formatting

    Do you remember weird amounts in the checkout before, like

    1 BTC = 25000.424242 USD

    When USD can have maximum of 2 decimal places?

    It is finally fixed!

    Now, every amount will be formatted as per it's currency settings.

    Also, the rate string is now fancier than before, it can contain currency symbol and it's code.

    There are some breaking changes to make it working

    Now every amount in the payment methods is not a Decimal, but a string, which was already formatted for you.

    Also, every payment method now has a rate field, which will contain a computer-readable formatted Decimal of the exchange rate at the moment of invoice creation.

    Also every payment method now has a rate_str field, which is a human-readable pretty-formatted rate string, ready to be used in checkout

    Major task system and logging refactor

    Now all background tasks are running only in the worker process, and not in every worker ran by gunicorn

    Instead of using local process state, fetched and parsed data is now placed in redis, and fetched from there by workers serving requests.

    Now, instead of each process logging concurrently, which lead to race condition (like, having logs from yesterday contain today's logs), each worker uses sends request to logging server, which is ran as part of the main background worker.

    What does it mean?

    It means that BitcartCC deployments should use way less RAM, should have less issues and work more stable.

    Plus it means that logging system now works correctly

    Logs in the admin panel are now sorted, and it is now possible to remove individual logs or clean them all.

    Tor extension is now refreshed every 15 minutes instead of every 2 minutes to reduce logs spam.

    Added configuration samples and documented every setting

    Every setting supported by BitcartCC that is configured by an environment variable is supported.

    Now, the conf directory of your cloned BitcartCC repo contains more samples:

    • .env.sample was cleaned up from unused settings, and now every setting is documented
    • .env.dev.sample was added, which contains the configuration we use when developing BitcartCC

    Misc changes

    • Fixed worker start on Mac OS
    • Pending invoice processing will no longer stop processing on error in one of the invoices
    • Added wallet balance endpoint, /wallets/{wallet_id}/balance, which returns a dictionary with 4 keys: confirmed, unconfirmed, lightning and unmatured.
    • Various bugfixes and performance improvements
    • Added an easter egg (:
    Source code(tar.gz)
    Source code(zip)
  • 0.0.0.3(Oct 25, 2020)

    Logging system

    We now have logging system set up for our merchants API.

    It means that it'll be easier to debug issues, as it is now possible to view logs from admin panel.

    You can view logs (collected each day), and download them if needed for others to help to fix your issue.

    Admin panel responsibility improvements

    Admin panel should now work better on mobile, especially in server management page.

    Other changes

    Search input in admin panel now no longer searches all related tables, but only the one you are currently viewing.

    Fixed a bug where if you have passed products=None to API it would crash.

    Update check now doesn't even start to run if update url is not set

    Admin panel's wallets creation dialog currency field is now a dropdown-to avoid entering invalid fields.

    Source code(tar.gz)
    Source code(zip)
  • 0.0.0.2(Oct 17, 2020)

  • 0.0.0.1(Oct 16, 2020)

Owner
BitcartCC
Your self-hosted, open-source cryptocurrency all-in-one solution
BitcartCC
A cool, modern and responsive django admin application based on bootstrap 5

django-baton A cool, modern and responsive django admin application based on bootstrap 5 Documentation: readthedocs Live Demo Now you can try django-b

Otto srl 494 Oct 19, 2021
Awesome Video Datasets

Awesome Video Datasets

Yunhua Zhang 243 Oct 17, 2021
Python Crypto Bot

Python Crypto Bot

Michael Whittle 986 Oct 17, 2021
WebVirtCloud is virtualization web interface for admins and users

WebVirtCloud is a virtualization web interface for admins and users. It can delegate Virtual Machine's to users. A noVNC viewer presents a full graphical console to the guest domain. KVM is currently the only hypervisor supported.

Anatoliy Guskov 1.1k Oct 17, 2021
StyleCLIP: Text-Driven Manipulation of StyleGAN Imagery

StyleCLIP: Text-Driven Manipulation of StyleGAN Imagery

null 2.3k Oct 23, 2021
Django app that enables staff to log in as other users using their own credentials.

Impostor Impostor is a Django application which allows staff members to login as a different user by using their own username and password. Login Logg

Andreu Vallbona Plazas 134 Oct 5, 2021
Jet Bridge (Universal) for Jet Admin – API-based Admin Panel Framework for your application

Jet Bridge for Jet Admin – Admin panel framework for your application Description About Jet Admin: https://about.jetadmin.io Live Demo: https://app.je

Jet Admin 1k Oct 14, 2021
A high-level app and dashboarding solution for Python

Panel provides tools for easily composing widgets, plots, tables, and other viewable objects and controls into custom analysis tools, apps, and dashboards.

HoloViz 1.4k Oct 23, 2021
Django Smuggler is a pluggable application for Django Web Framework that helps you to import/export fixtures via the automatically-generated administration interface.

Django Smuggler Django Smuggler is a pluggable application for Django Web Framework to easily dump/load fixtures via the automatically-generated admin

semente 359 Sep 28, 2021
xarray: N-D labeled arrays and datasets

xarray is an open source project and Python package that makes working with labelled multi-dimensional arrays simple, efficient, and fun!

Python for Data 2.3k Oct 17, 2021
Python books free to read online or download

Python books free to read online or download

Paolo Amoroso 2.9k Oct 15, 2021
"Log in as user" for the Django admin.

django-loginas About "Login as user" for the Django admin. loginas supports Python 3 only, as of version 0.4. If you're on 2, use 0.3.6. Installing dj

Stavros Korokithakis 282 Oct 10, 2021
Lazymux is a tool installer that is specially made for termux user which provides a lot of tool mainly used tools in termux and its easy to use

Lazymux is a tool installer that is specially made for termux user which provides a lot of tool mainly used tools in termux and its easy to use, Lazymux install any of the given tools provided by it from itself with just one click, and its often get updated.

DedSecTL 1.2k Oct 24, 2021
A minimalist GUI frontend for the youtube-dl. Takes up less than 4 KB.

?? libre-DL A minimalist GUI wrapper for youtube-dl. Written in python. Total size less than 4 KB. Contributions welcome. You don't need youtube-dl pr

null 37 Aug 20, 2021
Freqtrade is a free and open source crypto trading bot written in Python

Freqtrade is a free and open source crypto trading bot written in Python. It is designed to support all major exchanges and be controlled via Telegram. It contains backtesting, plotting and money management tools as well as strategy optimization by machine learning.

null 12.7k Oct 22, 2021
Nginx UI allows you to access and modify the nginx configurations files without cli.

nginx ui Table of Contents nginx ui Introduction Setup Example Docker UI Authentication Configure the auth file Configure nginx Introduction We use ng

David Schenk 4k Oct 24, 2021
An improved django-admin-tools dashboard for Django projects

django-fluent-dashboard The fluent_dashboard module offers a custom admin dashboard, built on top of django-admin-tools (docs). The django-admin-tools

django-fluent 295 Sep 9, 2021
FLEX (Federated Learning EXchange,FLEX) protocol is a set of standardized federal learning agreements designed by Tongdun AI Research Group。

Click to view Chinese version FLEX (Federated Learning Exchange) protocol is a set of standardized federal learning agreements designed by Tongdun AI

同盾科技 40 Sep 18, 2021
An administration website for Django

yawd-admin, a django administration website yawd-admin now has a live demo at http://yawd-admin.yawd.eu/. Use demo / demo as username & passowrd. yawd

Pantelis Petridis 139 Jul 27, 2021