Site: https://admin.bitcartcc.com/login

Posible fix:

• Add white background.

Pre-commit hooks should be added, documented and applied as we did in all our python repositories.
Pre-commit hooks are to be added by pre-commit app: https://pre-commit.com/
See those pull requests for reference: bitcart/bitcart#238, bitcart/bitcart-sdk#32, bitcart/bitccl#13

Of course, python-related tasks should be removed, and a set of rules for js repos should be created. Pre-commit checks should run most basic checks for file consistency (newlines, trailing whitespaces, etc), also probably eslint with our config (so that it runs prettier too) and any other useful checks for js code

We currently use husky for pre-commit hooks. Preferably pre-commit would also run the linting run by husky, or just run husky itself

The main issue is to make pre-commit use versions from package.json without manually specifying them in it's config file

Important: the pull request will be merged without squash, so please try to make it like reference PRs, first commit adding the pre-commit config, and in next commits applying fixers one by one, and in last commits documenting it and adding to CI. To add to CI you can use bitcartcc/lint action by our bitcartcc/bitcartcc-shared orb. See other pull requests for reference

Currently we only run eslint linting by yarn lint:
https://github.com/bitcartcc/bitcart-admin/blob/6a3e10391ef22dead01e0b9a65a2dba393ccdc4c/package.json#L12
To get to 1.0 release, we need a stable test suite to test that UI doesn't break without checking it manually (for example when upgrading one image input library it got broken and got into release, so I had to fix it later manually)
I am not an expert in javascript apps (and vue apps) testing, so any help welcome
We need a few categories of tests set up:

1. Unit tests. I heard that jest is often used for this. We may test some utility functions and so on. For code coverage codecov is to be used of course.
2. Integration tests: something that may be tested on a real API. This could either use our demo merchants api instance (https://api.bitcartcc.com), or better, it would start the most recent changes from bitcart master repo in docker
3. End to end tests and snapshot testing. This type of testing is the most important one. Something like selenium could be used, or better-suiting libraries for that in js world. It would test that UI works as expected.
   This would then be added to our CI. If you need help in adding it, you can just implement the tests and I can add that to CI.
   First of all we need to scaffold the initial infrastructure for that, then add those test types and start adding new tests. This issue can yield a lot of pull requests because there are a lot of tests to add or set up.

Currently the UX for both new contributors and users experiencing issues accessing the Merchants API is not optimal, all they see is connection refused error:

It is caused by fetching done in server side (on client side it will just fail request so it doesn't matter).
We fetch API policies to configure some essential settings for store operations, and most store pages require those variables set.
Instead of erroring out, the page being accessed (so this should probably be implemented in layouts to make it work on all pages) should display a message that it was not possible to reach Merchants API and provide hints on how to fix the issue: either it is not started or BITCART_ADMIN_API_URL is set to an invalid value

Some hints on how it works:
Nuxt config is used to load API url from env variable here:
https://github.com/bitcartcc/bitcart-admin/blob/6a3e10391ef22dead01e0b9a65a2dba393ccdc4c/nuxt.config.js#L62
It is loaded in nuxtServerInit:
https://github.com/bitcartcc/bitcart-admin/blob/6a3e10391ef22dead01e0b9a65a2dba393ccdc4c/store/index.js#L45
3 requests on server side are made in nuxtServerInit, they should be handled:
https://github.com/bitcartcc/bitcart-admin/blob/6a3e10391ef22dead01e0b9a65a2dba393ccdc4c/store/index.js#L46-L48

Also it is required to add to the documentation (CONTRIBUTING.md) how to set up api for development, see this comment for reference (replace STORE with ADMIN in env variable name)

Version of BitcartCC: 0.7.4.1
Your operating system: MacOS 12.5 | Linux Debian
Deployment method: Docker

Reproducible steps:

1. Setup an EVM related payment token (ETH, MATIC, AVALANCHE) etc.
2. Have metamask installed and changed to the correct network
3. Create an invoice and try to pay with the above token.
4. Try to pay with metamask
5. Error appears

What you expected to see, versus what you actually saw:
Expected to proceed with the payment with metamask, open metamask extension popup.
Actually saw the following error
Please change your network in metamask to work on the MATIC network (chain id 137)

Similar to bitcart/bitcart-store#319

We are taking the same approach: css variables.
It needs to be researched whether vuetify can generate those variables for css files to change colors at runtime

TODO:

• Implement initial theming support via vuetify's css vars support
• Make sure all external UI components also follow theme colors
• Load theme css file from theme_settings.admin_theme_url of the store, see bitcart/bitcart#244
• Research for any vuetify analogues to bootswatch

Initially, at least customizing checkout page is our goal. Later whole admin UI could be made customizeable

We need to set up internalization infastructure on admin panel.
Initially, translating only checkout page is enough. Later we can translate the whole panel.
Steps to do it:

• Set up nuxt/i18n. See this commit and further ones to see how we did it for bitcartcc store
• Setup transifex resource. I will do it when initial setup is done
• Start translating checkout page. The translation process should look the same as in bitcart/bitcart-site#86
• Try translating the whole admin panel. This would mean to change vuetify locale too, as it has some locales supported.

Main welcome: bitcart/bitcart#133

Issue list:

• Fix favicon barely visible in darkmode (#7)
• Making all admin pages responsive (#11)
• Set up formatting guidelines (prettier) (#13)

Main welcome: bitcart/bitcart#243

Issue list (more to be added):

• #119
• #121
• #122
• #123
• #124

Some pages, like toolbars in management panel, aren't responsive on mobile.

Also, toolbars don't have any borders in production, while in developer environment they have borders (as it should be).

Help is appreciated.
Currently we have the following design:


The task is to port https://demo.bitcartcc.com design or similar to vuetify.
Screen of old admin:

Card texts might be fixed to be more fit in this design in both dark and light modes.
After finishing design, actual functionality should be added, loading data from Backend API.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Pending Approval

These branches will be created by Renovate only once you click their checkbox below.

• Update dependency eslint to v9
• Update dependency vue to v3
• Update dependency vuetify to v3
• Update nuxt packages (major) (@nuxtjs/device, @nuxtjs/eslint-config, @nuxtjs/eslint-module, nuxt)
• 🔐 Create all pending approval PRs at once 🔐

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update dependency express to v4.19.2 [SECURITY]
• Update all non-major dependencies (vue-server-renderer, vue-template-compiler, vuetify-loader)
• Lock file maintenance
• Click on this checkbox to rebase all open PRs at once

Ignored or Blocked

These are blocked by an existing closed PR and will not be recreated unless you click a checkbox below.

• Update dependency @chenfengyuan/vue-qrcode to v2

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Currently, we don't have any formatting set up (I format code with vscode eslint extension, but it isn't a formatter actually).
We should create something like https://github.com/bitcartcc/bitcart/blob/master/CODING_STANDARDS.md#formatting, but for vue repos.
What are the choices available? Prettier, for example?
Last time I used it, it was formatting files in a weird way, but it's probably opinionated.
Ideally our formatter we'll use should be like black in python - https://github.com/psf/black - almost no configuration, but sensible, good for readability choices.
We'll need the formatter we choose to be able to check if files are formatted correctly - we need it as a part of our CI process.
P.S. @orestischaral you may want to take a look at it

When an email verification link is sent using the one domain mode configuration, the link in the email is incorrect.

Example:

• The user clicks on resend verification and enters their email on https://my.domain.com/admin/login/email
• Email is sent.
• Clicking on the link from the email sends the user to https://my.domain.com/login/email?code=acFhTTJecLWUjHiJrEVcTDnRFuyZAWSC instead of https://my.domain.com/admin/login/email?code=acFhTTJecLWUjHiJrEVcTDnRFuyZAWSC.