Ticket Q490696
Visible to All Users
Duplicate

SecuritySystem: Write permission based on criteria with enum does not work until application is closed and reopened

created 12 years ago

Run attached project, logon with username "Default", no password.

In the project, create a new object. Set its status to "Cannot edit" and save. At this point the object should not allow write permissions. However they are still allowed. Even refreshing the list view, going to another view, etc… doesn't trigger it. You have to exit the application and restart, at which point the object is disabled as security defined it

Seems to affect XPObjectSpaceProvider and not the SecuredObjectSpaceProvider. I've had to abandon SecuredObjectSpaceProvider for the time being due to the issues I list in this ticket: http://www.devexpress.com/Support/Center/Question/Details/Q359904

Namely, I have a custom function criteria operator called NewObjectId, which evaluates to Guid.Empty. I have some instances where I lock down roles to objects that have already been saved using the Criteria Oid != NewObjectId(). Works great, but an exception gets thrown on the save because the Oid has been generated before the rest of the members are set.

Comments (1)
DevExpress Support Team 12 years ago

    We are working on your issue and will answer you as soon as possible. We apologize for the delay.

    Answers approved by DevExpress Support

    created 12 years ago (modified 11 years ago)

    I have reproduced this behavior. We have not yet finished our work regarding this scenario. Currently, it is not supported, and I cannot provide advice regarding how to improve it because we have not investigated it, and this work will require significant time.  We will see how to improve this situation, though I cannot promise any time frame. I have registered the corresponding ticket in our database: Security.UILevel - Improve application behavior when creating an object if its properties are adjusted in such way that this object should be readonly under Security rules. Please add it to favorites to be notified when its status is changed.
    In the meantime, I suggest that you consider how this scenario can be applied in similar situation when developing a common WindowsForms application, and I would like to help you integrate your solution in an XAF application.

      Show previous comments (4)

        CA module is not ideal in this scenario at all.
        The purpose of using Security System is the ability to 'easily' customize it. An administrator should be able to come in and customize this rule to say "after this object is saved, I don't want the User role to be able to change it."
        I don't allow Model Editor access. This should be handled via security.

          For the perfomance issue: not an example but an explanation: I use a CustomCriteria Method and i debbuged that this method is called for each propertyeditor used in the CA rule. So if i have 5 controls affected by the rule it calles the rule 5 times. And what is even worse: I have a textfield that allows input at everytime. everytime i type on the keyboard to change the content of this field, the conditional appearance method is called that 5 times. I do agree with Nate: Its must be supported by the security and not the CA module. For me it is a bug that xaf wont apply securityrules on changed objects until reload.

          DevExpress Support Team 12 years ago

            Thank you for your feedback. I greatly appreciate your cooperation. I fully understand your idea.
            We have not considered this scenario when developing SecurityStrategyComplex class and permissions system, but we will take your opinion into account. For more details, see Security.UILevel - Improve application behavior when creating an object if its properties are adjusted in such way that this object should be readonly under Security rules.
            In the meantime, would you review approaches in this ticket and notify us whether or not they satisfy your requirements?

            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.