Ticket Q572556
Visible to All Users

Blocking Access to an object Security, Validation or Conditional Appearance

created 11 years ago

Hi there,

I'm looking for some best practice advice. I have a Client object that I need to manage with the following business process -

  1. A new Client is created.
  2. This client information is verified by a second person at a later date. After the information is deemed accurate the second person sets the "Verified" property on the Client object.
  3. When the Verified property is set, the client should ONLY be editable by a person in a special "Can Edit Verified" group.

Now,

I have this woking in the security system using Object Permissions and a special security group.

Here are my specific questions:

  1. Is this the right approach or should I use Validation or Appearance?
  2. Is there any way to not block the entire object and only specific properties?
  3. Is there any way to not block all of the Associated Child objects (like Phone and Address)

Thanks,

Ralph

Comments (1)

    After a bit of experimentation, I am moving away from the Security system and using Conditional Appearance. It seems to give me the granular control I am looking for without effecting the Associated Child Objects. Is this a resonable use of COnditional Appearance or will I get into trouble down the road?

    Answers approved by DevExpress Support

    created 11 years ago (modified 11 years ago)

    Hello Ralph,
    After reading your description I think that the Conditional Appearance is the best choice in your situation. It allows you to define conditional rules that will disable fields in the UI. The main disadvantage of this approach is that the object can be modified via code. That is why I suggest you refer to the Validation Module module to prevent this.
    Feel free to contact us if you experience any further difficulties.
    UPDATE:
    >>1) Is this the right approach or should I use Validation or Appearance?
    The primary data protection should be guaranteed by the security system permissions. You can use the Validation and ConditionalAppearance rules for additional UI level protection and better UX.
    >>2) Is there any way to not block the entire object and only specific properties?
    Yes, there are member-level permissions for that purpose. Refer to our SecurityDemo or check the corresponding docs for more details.
    >>3) Is there any way to not block all of the Associated Child objects (like Phone and Address)
    Yes, this is also flexibly configurable via security permissions.

      Show previous comments (1)
      Dennis Garavsky (DevExpress) 11 years ago

        Hello Ralph,
        Thank you for your feedback. It is really great to know how you use the features of our framework to resolve real-world problems.
        Let me comment on the security aspect of this solution. The ConditionalAppearance module (as stated in the docs) should not be used as a security means, even if it can hide or disable certain UI elements. Its primary purpose is to customize the appearance of the application, provide a better UX by guiding an end-user through the predefined application flow (e.g., he or she entered a certain value, then depending on it, new editors appear just for this case or certain editors get disabled not to allow a user to go a wrong way).
        So, if you need data protection, you should also have additional security checks (preferably on the server side) and not rely just on the availability of UI controls. For this, I can recommend the following things:
        1. Make sure your business logic in data model classes or controllers handles invalid user inputs or other unwanted situations, even if you have set up the Validation or ConditionalAppearance rules for the UI;
        2. Use the Security System module to protect your data in the UI or on the server side;
        3. Consider hiding your database from the client by using a remote data store service as described in How to connect to a remote data service instead of using a direct database connection;
        4. Consider storing the Application Model differences in the database instead of the file system and thus disallowing powerful end-users to customize it manually. See the How to: Store Model Differences in Database example for more details.
        5. Make sure your application does not allow loading external modules/plug-ins from the configuration file by using the right XafApplication.Setup method overload.
        That is all for now and I hope you will find these suggestions helpful. I will also consider extracting this info in a dedicated article. Let me know if I can be of more help.
        P.S.
        I have also updated our original answer to explicitly answer your specific questions.

          Thanks fro your very complete response Dennis. It is going to take me a bit of time to experiment with your suggestions. I might come back with a design for you to validate again in a couple of weeks. (I will open another ticket)

          Dennis Garavsky (DevExpress) 11 years ago

            Disclaimer: The information provided on DevExpress.com and affiliated web properties (including the DevExpress Support Center) is provided "as is" without warranty of any kind. Developer Express Inc disclaims all warranties, either express or implied, including the warranties of merchantability and fitness for a particular purpose. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.

            Confidential Information: Developer Express Inc does not wish to receive, will not act to procure, nor will it solicit, confidential or proprietary materials and information from you through the DevExpress Support Center or its web properties. Any and all materials or information divulged during chats, email communications, online discussions, Support Center tickets, or made available to Developer Express Inc in any manner will be deemed NOT to be confidential by Developer Express Inc. Please refer to the DevExpress.com Website Terms of Use for more information in this regard.