DisallowIncomingCredential #5704
Conversation
| { | ||
| auto const id = ctx.tx[sfAccount]; | ||
| if (id != subject && | ||
| sleSubject->getFlags() & lsfDisallowIncomingCredential) |
There was a problem hiding this comment.
please use isFlag instead of getFlags
|
Shouldn't this be a feature amendment? |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #5704 +/- ##
=========================================
- Coverage 78.9% 78.9% -0.0%
=========================================
Files 816 816
Lines 72075 72086 +11
Branches 8437 8414 -23
=========================================
+ Hits 56865 56873 +8
- Misses 15210 15213 +3
... and 3 files with indirect coverage changes 🚀 New features to boost your workflow:
|
I have chosen it as Fix Amendment because I thought it was originally appropriate to include it in the Credentials Amendment. Changing to Feature Amendment is totally fine. |
Fair, but it wasn't in the spec, and I would consider this more of an expansion of the spec than a fix. This amendment adds a new flag. For people implementing tooling, they're generally paying closer attention to the feature amendments and not the fix amendments, and therefore might miss the addition of the new flag if they don't double check this amendment. |
Bronek
added
the
Needs second review
|
@tequdev please change this to a feature amendment and publish a spec for it in the XRPL-Standards discussions |
|
Created the spec and changed it to a feature amendment. |
High Level Overview of Change
Blocks incoming (as Subject field) CredentialCreate for your account, similar to the existing DisallowIncoming flags.
Context of Change
Type of Change