locked
Security - need write access RRS feed

  • Question

  •  

    Hey folks,

     

    We encountered the following scenario/issue - is it a bug or design?

    Entity1 is related to Entity2 (1:M, Entity1 is parent, Entity2 is child, eg. Account to Opportunity).

    There seems to different "requirement" depending on how you create an opportunity related to an account.

     

    To create an opportunity via the associated view in account form, the following rights in the user role are required

    - Append for opportunity and

    - AppendTo for account and

    - Write for account (without this right, the New Opportunity icon will not show up)

    To create an opportunity and lookup to a record to an account, the following rights in the user role are required

    - Append for opportunity and

    - AppendTo for account

     

    Why is write rights required in the former scenario and not the later scenario - for the same outcome?

     

    regards,

    LuanBoo

    Friday, June 13, 2008 7:36 AM

Answers

  •  

    You are correct, write is required to make any changes to the account, including creating related records. There is probably a reason why this is the case, probably users wanted a way to prevent all writing to a record, including creating related records.  In effect, taking away write access is puting the users in complete "read only" mode for an entity.

     

    There are reasons why you would want to prevent creating relationships from one side of the relationship and not from the other. For example, I have an environment where we have a survey entity associated with an account, and I have certain users that I don't want to be able to create accounts from the survey record, but I do want them to be able to do a lookup to select a survey on the account record, and I also want them to be able to open the survey record and see what accounts are associated with the survey, but I don't want them to be able to create new accounts or lookup existing accounts from this view--just read only.

     

    If you restrict the append and append to permissions, you are restricting the ability for these records to be appended in all scenarios.  Restricting the write access allows you to restrict it in a specific scenario.

     

    Does that make sense?  Unless absolutely necessary, I would give users at least user level write access in most cases.  If you want to give them access to adding opportunities from the account, but want to restrict them from editing key fields on the account, consider C360's Field Level security add-on http://www.c360.com/FieldLevelSecurity.aspx  That will allow you to restrict certain fields based on security role, while still granting write access.

    Friday, June 13, 2008 11:45 AM
    Moderator

All replies

  •  

    You are correct, write is required to make any changes to the account, including creating related records. There is probably a reason why this is the case, probably users wanted a way to prevent all writing to a record, including creating related records.  In effect, taking away write access is puting the users in complete "read only" mode for an entity.

     

    There are reasons why you would want to prevent creating relationships from one side of the relationship and not from the other. For example, I have an environment where we have a survey entity associated with an account, and I have certain users that I don't want to be able to create accounts from the survey record, but I do want them to be able to do a lookup to select a survey on the account record, and I also want them to be able to open the survey record and see what accounts are associated with the survey, but I don't want them to be able to create new accounts or lookup existing accounts from this view--just read only.

     

    If you restrict the append and append to permissions, you are restricting the ability for these records to be appended in all scenarios.  Restricting the write access allows you to restrict it in a specific scenario.

     

    Does that make sense?  Unless absolutely necessary, I would give users at least user level write access in most cases.  If you want to give them access to adding opportunities from the account, but want to restrict them from editing key fields on the account, consider C360's Field Level security add-on http://www.c360.com/FieldLevelSecurity.aspx  That will allow you to restrict certain fields based on security role, while still granting write access.

    Friday, June 13, 2008 11:45 AM
    Moderator
  • Joel,

     

    Thanks for the reply.

     

    I personally think it depends on how you look at things. It is more of a consistency issue.

    If you create an associated record (eg. survey) by looking up to the parent record (eg. account), and it is not considered "Write" to the parent record (since you don't need "Write" access), then creating an associated recorded via the associated view of the parent record should not be considered "Write" to the parent record. I would consider "Write" to the parent record only when I make any changes attributes in the parent record.

     

    In any case, if that's the way the solution is designed, we will have to "accept" it right?

    The other purpose of me asking in the forum is to understand whether it is a "bug" or it was design to behave that way.

     

    regards,

    luanboo

     

    Monday, June 16, 2008 1:47 AM
  • that's how it works, it's by design, not a bug.

     

    Monday, June 16, 2008 2:43 AM
    Moderator