Documentation for entitlements #152
Conversation
… into sainati/entitlement-docs
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| - Entitled access means the declaration is only accessible/visible | ||
| to owned values, or to references that are authorized to the required entitlements. | ||
|
|
||
| For example, an `access(E, F)` field can only be accessed by an owned value, | ||
| or a reference to a value that is authorized to the `E` and `F` entitlements. | ||
|
|
||
| An element is made accessible by code in the same containing type |
There was a problem hiding this comment.
I think we might need to be a little more hand-holdy with this part. A lot of people come here for their first introduction to access control in cadence, so using terms like "owned values" or "references that are authorized to the required entitlements" without any context is going to really confuse people who aren't familiar with anything in Cadence. I'd almost rather just avoid talking about entitlements at all in this section since entitlements are an advanced concept.
There was a problem hiding this comment.
Hmm. I agree that we could make this presentation simpler, but I don't think we can avoid talking about entitlements here. They aren't really an advanced concept; they are pretty fundamental to how access control is going to work in Cadence. It's going to be essentially impossible to write a contract post-Stable Cadence without understanding how entitlements work at least at a basic level, so I think we need to have this section present an introduction to the concept at least.
There was a problem hiding this comment.
Added some additional language about what an "owned value" is and what it means for a reference to be authorized to an entitlement.
Co-authored-by: Joshua Hannan <hannanjoshua19@gmail.com>
Agreed 1000%. I think the current plan is to rewrite all the existing tutorials to use entitlements (they're all going to be outdated by Stable Cadence regardless), so hopefully seeing concrete examples of entitlements in use for those will be valuable. |
|
cc @SupunS can you take a look at these and let me know what you think? We can update them with your entitlements changes too once those are all merged. |
… into sainati/entitlement-docs
…o sainati/entitlement-docs
| let alsoEntitledSubRef = r.getRef() | ||
| ``` | ||
|
|
||
| {/* TODO: Update once mappings can be used on regular composite fields */} |
There was a problem hiding this comment.
Should we make this a comment?
| {/* TODO: Update once mappings can be used on regular composite fields */} | |
| <!-- TODO: Update once mappings can be used on regular composite fields --> |
Co-authored-by: Supun Setunga <supun.setunga@gmail.com>
| let alsoEntitledSubRef = r.getRef() | ||
| ``` | ||
|
|
||
| {/* TODO: Update once mappings can be used on regular composite fields */} |
| Entitlement mappings may be used either in accessor functions (as in the example above), or in fields whose types are references. Note that this latter | ||
| usage will necessarily make the type of the composite non-storage, since it will have a reference field. | ||
|
|
||
| {/* TODO: once the Account type refactor is complete and the documentation updated, let's link here to the Account type page as an example of more complex entitlement mappings */} |
There was a problem hiding this comment.
Same here: turn into a Markdown comment, i.e. <!-- ... -->
There was a problem hiding this comment.
When I tried doing this, it made the CI complain. I'm pretty sure these are comments as-is, since they don't show up here: https://developers.flow.com/next/cadence/language/access-control
No description provided.