[RFC] offer: allow re-enabling a previously disabled offer #7362
Conversation
|
When I copied my test from the other PR, it shows why we need tests. The final commit, which needs to be squashed, shows why... |
Yes, this RFC was not finished, I was waiting to know if we want to have an |
549cfaf
to
9d96709
Compare
65eee36
to
75425a1
Compare
By accident, I force push the previous version with your code, so I remake the work, sorry about that. NNow the code should be ready, probably I need to fix some failure with the docs, but should be a minor |
75425a1
to
689f15a
Compare
|
Rebased, and added a new return code a-la @Lagrang3 suggestion. |
1a908b1
to
ebe9453
Compare
ebe9453
to
df46f0e
Compare
Sometimes, for various reasons, a user disables an offer and then wants to re-enable it. This should be allowed because, from the CLN point of view, it is just an internal state. If a user has constraints on the description of the invoice because they are using services that link some sort of user ID to an offer, it is important for the user to be able to re-enable the offer, not create a new one. Creating a new offer would require a different description. Link: ElementsProject#7360 Co-Developed-by: Rusty Russell <rusty@rustcorp.com.au> Signed-off-by: Vincenzo Palazzo <vincenzopalazzodev@gmail.com>
Suggested-by: https://github.com/Lagrang3 Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
df46f0e
to
42f121e
Compare
|
Thanks for the @Lagrang3 review, sorry for the 3-day silence from my side, but I was taking a small holiday, and now I am back. Added Rusty ad Co-Developed-by inside the 7bdc8db so when people will complain about this commit, can In addition, I fixed a test failure regarding the code error in df46f0e now the CI should be happy! Thanks to everyone for keeping this PR going also when I was off <3 |
Sometimes, for various reasons, a user disables an offer and then wants to re-enable it. This should be allowed because, from the CLN point of view, it is just an internal state.
If a user has constraints on the description of the invoice because they are using services that link some sort of user ID to an offer, it is important for the user to be able to re-enable the offer, not create a new one. Creating a new offer would require a different description.
P.S: This is in an RFC, if it will be accepted I will finish the documentation but I still need to write the test
Fixes: #7360