I'm potentially interested in working out how BTCpay works at some point, but it's doesn't seem necessary for our trial run, so it'd be helpful to be able to hide it in Capsul if it's not configured.
These changes hide the link to /payment/btcpay, and prevent that page from loading, if BTCPAY_PRIVATE_KEY is not set.
I'm potentially interested in working out how BTCpay works at some point, but it's doesn't seem necessary for our trial run, so it'd be helpful to be able to hide it in Capsul if it's not configured.
These changes hide the link to `/payment/btcpay`, and prevent that page from loading, if `BTCPAY_PRIVATE_KEY` is not set.
Yeah, fair point, maybe a further change to make in future? My thinking was that BTCPAY_PRIVATE_KEY is blank by default, so the flow of "first set-up = no BTCPay", "add BTCPay private key = enabled" didn't seem terrible, but yes, still not as explicit as it could be.
Yeah, fair point, maybe a further change to make in future? My thinking was that `BTCPAY_PRIVATE_KEY` is blank by default, so the flow of "first set-up = no BTCPay", "add BTCPay private key = enabled" didn't seem terrible, but yes, still not as explicit as it could be.
Is that ok? I thought it might be better to avoid tying the config structure to the template files. So config values would have to be passed explicitly, like:
I made the BTCPAY_ENABLED boolean config value get automatically set depending on app.config['BTCPAY_URL'] is not "" and btcpay.Client(api_uri=app.config['BTCPAY_URL'], pem=app.config['BTCPAY_PRIVATE_KEY']) does not raise an exception (i.e. the key is valid)
Does that sound good ?
I changed this a little bit:
1. I didn't wanna use
```
@app.context_processor
def load_config_vars():
return dict(config=app.config)
```
Is that ok? I thought it might be better to avoid tying the config structure to the template files. So config values would have to be passed explicitly, like:
```
return render_template(
"account-balance.html",
...
btcpay_enabled=current_app.config["BTCPAY_ENABLED"],
...
```
2. I made the `BTCPAY_ENABLED` boolean config value get automatically set depending on `app.config['BTCPAY_URL'] is not ""` and `btcpay.Client(api_uri=app.config['BTCPAY_URL'], pem=app.config['BTCPAY_PRIVATE_KEY'])` does not raise an exception (i.e. the key is valid)
Does that sound good ?
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
I'm potentially interested in working out how BTCpay works at some point, but it's doesn't seem necessary for our trial run, so it'd be helpful to be able to hide it in Capsul if it's not configured.
These changes hide the link to
/payment/btcpay, and prevent that page from loading, ifBTCPAY_PRIVATE_KEYis not set.LGTM.
Probably more intuitive to have a
BTCPAY_ENABLED=true/false?But again, this looks fine as-is.
Yeah, fair point, maybe a further change to make in future? My thinking was that
BTCPAY_PRIVATE_KEYis blank by default, so the flow of "first set-up = no BTCPay", "add BTCPay private key = enabled" didn't seem terrible, but yes, still not as explicit as it could be.I changed this a little bit:
Is that ok? I thought it might be better to avoid tying the config structure to the template files. So config values would have to be passed explicitly, like:
BTCPAY_ENABLEDboolean config value get automatically set depending onapp.config['BTCPAY_URL'] is not ""andbtcpay.Client(api_uri=app.config['BTCPAY_URL'], pem=app.config['BTCPAY_PRIVATE_KEY'])does not raise an exception (i.e. the key is valid)Does that sound good ?
OK, looks excellent, merging!
@@ -73,3 +72,3 @@BTCPAY_PRIVATE_KEY=os.environ.get("BTCPAY_PRIVATE_KEY", default="").replace("\\n", "\n"),BTCPAY_URL=os.environ.get("BTCPAY_URL", default="https://btcpay.cyberia.club")BTCPAY_URL=os.environ.get("BTCPAY_URL", default="")Ah, greatlooks. I didn't wanna complicate things for Cyberia's deployment, but this seems like a good generic default