Mixing
Visible vs Read Only?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
3
down vote
favorite
Opportunity Fields > "Field Label/name" > Set Field-Level Security >
What is Visible vs Read OnLy?
A Google Search Revealed:
Visible : If you check the "Visible" checkbox, that field will be visible to that profile. User can read & edit that field
Read-Only: If you check the "Read-Only" checkbox, that field will be read only for the users of that profile. User can only see that field, he can't edit. Field must be Visible to be Read-Only
^That confuses me...
I want The profile to only be able to see The field; Not Edit it. But I can't Select "Read Only" Unless I select "Visible" But "visable" allows them to edit it.
permissions field-level-security
edited Aug 31 at 16:50
Adrian Larson♦
100k19105223
asked Aug 31 at 16:25
Guest Guy
44
add a comment |Â
up vote
3
down vote
favorite
Opportunity Fields > "Field Label/name" > Set Field-Level Security >
What is Visible vs Read OnLy?
A Google Search Revealed:
Visible : If you check the "Visible" checkbox, that field will be visible to that profile. User can read & edit that field
Read-Only: If you check the "Read-Only" checkbox, that field will be read only for the users of that profile. User can only see that field, he can't edit. Field must be Visible to be Read-Only
^That confuses me...
I want The profile to only be able to see The field; Not Edit it. But I can't Select "Read Only" Unless I select "Visible" But "visable" allows them to edit it.
permissions field-level-security
edited Aug 31 at 16:50
Adrian Larson♦
100k19105223
asked Aug 31 at 16:25
Guest Guy
44
Please try to apply tags which indicate the features your question is related to. Your question appears to have nothing to do with theSalesforce Communitiesfeature, so I removed the[community]tag and added some that make more sense.
– Adrian Larson♦
Aug 31 at 16:51
add a comment |Â
up vote
3
down vote
favorite
up vote
3
down vote
favorite
Opportunity Fields > "Field Label/name" > Set Field-Level Security >
What is Visible vs Read OnLy?
A Google Search Revealed:
Visible : If you check the "Visible" checkbox, that field will be visible to that profile. User can read & edit that field
Read-Only: If you check the "Read-Only" checkbox, that field will be read only for the users of that profile. User can only see that field, he can't edit. Field must be Visible to be Read-Only
^That confuses me...
I want The profile to only be able to see The field; Not Edit it. But I can't Select "Read Only" Unless I select "Visible" But "visable" allows them to edit it.
permissions field-level-security
edited Aug 31 at 16:50
Adrian Larson♦
100k19105223
asked Aug 31 at 16:25
Guest Guy
44
Opportunity Fields > "Field Label/name" > Set Field-Level Security >
What is Visible vs Read OnLy?
A Google Search Revealed:
Visible : If you check the "Visible" checkbox, that field will be visible to that profile. User can read & edit that field
Read-Only: If you check the "Read-Only" checkbox, that field will be read only for the users of that profile. User can only see that field, he can't edit. Field must be Visible to be Read-Only
^That confuses me...
I want The profile to only be able to see The field; Not Edit it. But I can't Select "Read Only" Unless I select "Visible" But "visable" allows them to edit it.
permissions field-level-security
edited Aug 31 at 16:50
Adrian Larson♦
100k19105223
asked Aug 31 at 16:25
Guest Guy
44
edited Aug 31 at 16:50
Adrian Larson♦
100k19105223
edited Aug 31 at 16:50
Adrian Larson♦
100k19105223
edited Aug 31 at 16:50
Adrian Larson♦
100k19105223
100k19105223
asked Aug 31 at 16:25
Guest Guy
44
asked Aug 31 at 16:25
Guest Guy
44
asked Aug 31 at 16:25
Guest Guy
44
44
Please try to apply tags which indicate the features your question is related to. Your question appears to have nothing to do with theSalesforce Communitiesfeature, so I removed the[community]tag and added some that make more sense.
– Adrian Larson♦
Aug 31 at 16:51
add a comment |Â
Please try to apply tags which indicate the features your question is related to. Your question appears to have nothing to do with theSalesforce Communitiesfeature, so I removed the[community]tag and added some that make more sense.
– Adrian Larson♦
Aug 31 at 16:51
Please try to apply tags which indicate the features your question is related to. Your question appears to have nothing to do with the
Salesforce Communities feature, so I removed the [community] tag and added some that make more sense.– Adrian Larson♦
Aug 31 at 16:51
Please try to apply tags which indicate the features your question is related to. Your question appears to have nothing to do with the
Salesforce Communities feature, so I removed the [community] tag and added some that make more sense.– Adrian Larson♦
Aug 31 at 16:51
add a comment |Â
1 Answer
1
active
oldest
votes
up vote
5
down vote
The hierarchy of permissions shown in this particular facet of the Salesforce UI is a bit backwards compared to the way we usually talk about permissions. Most of the time, when talking about CRUD/FLS permissions, we understand that there are four different rights at the object level, where Read < Update < Create < Delete, and two at the field level, where Read < Edit. We also always talk about permissions as additive; we don't use the permissions system to take away rights.
In this specific context (as well as in the custom field creation wizard and the properties dialogue for fields shown on a page layout), it works the other way. "Read Only" is an extra layer on the basic "Visible"; "Visible" means Read and Update permission; and "Read Only" removes the Edit facet. This is backwards relative to the FLS editor within a user profile, although it still records the actual permissions the same way under the hood.
In your use case, you should check both boxes.
answered Aug 31 at 16:34
David Reed
19.5k21540
1
Also even if you have Visible permission , you still won't be able to edit it as that field might be locked at page layout level.
– Pranay Jaiswal
Aug 31 at 17:12
1
Historically, it used to be Visible and Editable, but I suspect they changed it because just because it's Editable at the profile level doesn't mean the layout can't override it. The read-only nomenclature makes it clear that you're making it read-only regardless of other conditions.
– sfdcfox
Aug 31 at 17:48
add a comment |Â
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
5
down vote
The hierarchy of permissions shown in this particular facet of the Salesforce UI is a bit backwards compared to the way we usually talk about permissions. Most of the time, when talking about CRUD/FLS permissions, we understand that there are four different rights at the object level, where Read < Update < Create < Delete, and two at the field level, where Read < Edit. We also always talk about permissions as additive; we don't use the permissions system to take away rights.
In this specific context (as well as in the custom field creation wizard and the properties dialogue for fields shown on a page layout), it works the other way. "Read Only" is an extra layer on the basic "Visible"; "Visible" means Read and Update permission; and "Read Only" removes the Edit facet. This is backwards relative to the FLS editor within a user profile, although it still records the actual permissions the same way under the hood.
In your use case, you should check both boxes.
answered Aug 31 at 16:34
David Reed
19.5k21540
1
Also even if you have Visible permission , you still won't be able to edit it as that field might be locked at page layout level.
– Pranay Jaiswal
Aug 31 at 17:12
1
Historically, it used to be Visible and Editable, but I suspect they changed it because just because it's Editable at the profile level doesn't mean the layout can't override it. The read-only nomenclature makes it clear that you're making it read-only regardless of other conditions.
– sfdcfox
Aug 31 at 17:48
add a comment |Â
up vote
5
down vote
The hierarchy of permissions shown in this particular facet of the Salesforce UI is a bit backwards compared to the way we usually talk about permissions. Most of the time, when talking about CRUD/FLS permissions, we understand that there are four different rights at the object level, where Read < Update < Create < Delete, and two at the field level, where Read < Edit. We also always talk about permissions as additive; we don't use the permissions system to take away rights.
In this specific context (as well as in the custom field creation wizard and the properties dialogue for fields shown on a page layout), it works the other way. "Read Only" is an extra layer on the basic "Visible"; "Visible" means Read and Update permission; and "Read Only" removes the Edit facet. This is backwards relative to the FLS editor within a user profile, although it still records the actual permissions the same way under the hood.
In your use case, you should check both boxes.
answered Aug 31 at 16:34
David Reed
19.5k21540
1
Also even if you have Visible permission , you still won't be able to edit it as that field might be locked at page layout level.
– Pranay Jaiswal
Aug 31 at 17:12
1
Historically, it used to be Visible and Editable, but I suspect they changed it because just because it's Editable at the profile level doesn't mean the layout can't override it. The read-only nomenclature makes it clear that you're making it read-only regardless of other conditions.
– sfdcfox
Aug 31 at 17:48
add a comment |Â
up vote
5
down vote
up vote
5
down vote
The hierarchy of permissions shown in this particular facet of the Salesforce UI is a bit backwards compared to the way we usually talk about permissions. Most of the time, when talking about CRUD/FLS permissions, we understand that there are four different rights at the object level, where Read < Update < Create < Delete, and two at the field level, where Read < Edit. We also always talk about permissions as additive; we don't use the permissions system to take away rights.
In this specific context (as well as in the custom field creation wizard and the properties dialogue for fields shown on a page layout), it works the other way. "Read Only" is an extra layer on the basic "Visible"; "Visible" means Read and Update permission; and "Read Only" removes the Edit facet. This is backwards relative to the FLS editor within a user profile, although it still records the actual permissions the same way under the hood.
In your use case, you should check both boxes.
answered Aug 31 at 16:34
David Reed
19.5k21540
The hierarchy of permissions shown in this particular facet of the Salesforce UI is a bit backwards compared to the way we usually talk about permissions. Most of the time, when talking about CRUD/FLS permissions, we understand that there are four different rights at the object level, where Read < Update < Create < Delete, and two at the field level, where Read < Edit. We also always talk about permissions as additive; we don't use the permissions system to take away rights.
In this specific context (as well as in the custom field creation wizard and the properties dialogue for fields shown on a page layout), it works the other way. "Read Only" is an extra layer on the basic "Visible"; "Visible" means Read and Update permission; and "Read Only" removes the Edit facet. This is backwards relative to the FLS editor within a user profile, although it still records the actual permissions the same way under the hood.
In your use case, you should check both boxes.
answered Aug 31 at 16:34
David Reed
19.5k21540
answered Aug 31 at 16:34
David Reed
19.5k21540
answered Aug 31 at 16:34
David Reed
19.5k21540
answered Aug 31 at 16:34
David Reed
19.5k21540
19.5k21540
1
Also even if you have Visible permission , you still won't be able to edit it as that field might be locked at page layout level.
– Pranay Jaiswal
Aug 31 at 17:12
1
Historically, it used to be Visible and Editable, but I suspect they changed it because just because it's Editable at the profile level doesn't mean the layout can't override it. The read-only nomenclature makes it clear that you're making it read-only regardless of other conditions.
– sfdcfox
Aug 31 at 17:48
add a comment |Â
1
Also even if you have Visible permission , you still won't be able to edit it as that field might be locked at page layout level.
– Pranay Jaiswal
Aug 31 at 17:12
1
Historically, it used to be Visible and Editable, but I suspect they changed it because just because it's Editable at the profile level doesn't mean the layout can't override it. The read-only nomenclature makes it clear that you're making it read-only regardless of other conditions.
– sfdcfox
Aug 31 at 17:48
1
1
Also even if you have Visible permission , you still won't be able to edit it as that field might be locked at page layout level.
– Pranay Jaiswal
Aug 31 at 17:12
Also even if you have Visible permission , you still won't be able to edit it as that field might be locked at page layout level.
– Pranay Jaiswal
Aug 31 at 17:12
1
1
Historically, it used to be Visible and Editable, but I suspect they changed it because just because it's Editable at the profile level doesn't mean the layout can't override it. The read-only nomenclature makes it clear that you're making it read-only regardless of other conditions.
– sfdcfox
Aug 31 at 17:48
Historically, it used to be Visible and Editable, but I suspect they changed it because just because it's Editable at the profile level doesn't mean the layout can't override it. The read-only nomenclature makes it clear that you're making it read-only regardless of other conditions.
– sfdcfox
Aug 31 at 17:48
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f230888%2fvisible-vs-read-only%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Please try to apply tags which indicate the features your question is related to. Your question appears to have nothing to do with the
Salesforce Communitiesfeature, so I removed the[community]tag and added some that make more sense.– Adrian Larson♦
Aug 31 at 16:51