Security - Querying, creating additional objects or modifying protected data in code (preferably within the same transaction)

Hi,
I have gone through the reference ticket. Like others for me too either of the object space is not very usable. As an exceptional case can we have some sought of rough, very rough timelines for this suggestion? 14.1, 14.2? If it is happening in the near future I might use XP Object Space and then once this suggestion is implemented go for securedobjectspace.
I hope you understand the situation. Thanks

Hello,
Though I understand that this is a high priority functionality for you, I cannot currently provide you with estimation dates on this feature. We refrain from announcing any specific feature for any product in R&D prior to its release. This is our position for many reasons, including the fact that by promising X or Y, developers end up planning their development schedules around our promised feature set, which can change quite dynamically. We keep this feature on our radar, but it is still premature to discuss when it may be available.

Hi,
we have this scenario in our application as well and hope that a solution gets implemented soon.

I would like to see this solution soon as well

+1 for me

+1 for this

+1 me too

+1 for this

+1 here too

@Scott and others making +1 in this and other threads,
I wanted to kindly ask you to always provide your concrete business scenario description (preferably, in a user story notation) and a small sample project so as not to be misleading or confusing (https://www.devexpress.com/Support/Center/Question/Create). Note that this particular thread covers a particular situation and the behavior described in the reference tickets, and your real life cases can be quite different, as well as their solutions. Of course, it does not necessarily mean that you cannot approach your task in a different manner and thus avoid this XAF security system peculiarity. So, frankly speaking, unless your case is exactly the same as demonstrated in the reference tickets, making even +10 does not add any real value to such threads and only prevents you from resolving real problems right away (which also distracts our support team from helping you with your other tickets in the fastest way possible). Quite the opposite - sending us a small debuggable sample, screenshots and other supporting information that help us understand your scenario better enables us to provide you with the best technical solution possible for the current version. And quite often (from my almost decade experience) understanding a real case reveals other alternative options that will address a business problem even better than the original one. Thanks.

@Dennis I will be honest, when I received the notification after Scott's post yesterday I had no clue what this was about. However 3 years ago I thought it was important enough to +1 it ;) I will investigate and post a new ticket when I find the motivation behind that old +1.

@TeamPlusOne Have a nice weekend!

@Alex: I appreciate your help!
Have a great weekend too!

This has always been my scenario, which I feel is super easy to wrap one's head around and something I really need supported.

Take a simple class like this.

public class SaleItem: BaseObject
    {
        Product fProduct;
        public Product Product
        {
            get { return fProduct; }
            set { SetPropertyValue<Product >("Product", ref fProduct, value);
                if (!IsSaving && !IsLoading)
                {
                    Price = Product.Price;
                    Commission = Product.Commission;
                }
            }
        }

decimal fPrice;
        public decimal Price
        {
            get { return fPrice; }
            set { SetPropertyValue<decimal>("Price", ref fPrice, value); }
        }

decimal fCommission;
        public decimal Commission
        {
            get { return fCommission; }
            set { SetPropertyValue<decimal>("Commission", ref fCommission, value); }
        }
    }

So, we add an Item to a sale. When the product is set, the price and commission both come from the product level and get set to SaleItem.

User should be able to SEE sale item price, but not alter it.
User should not see commission, but needs to be able to have it set in the property setter.
Additionally, once saved, the item should not be able to be altered.

Simple, yes?

This scenario continues to prevent me from adding the secure ObjectSpace provider, which I really need.

Nate, did you consider a more complex solution with a second (non secure) objectspace provider and objectspace or unitofwork to implement the security-sensitive modifications?
Willem

Once again, thanks for your update, Nate. As we noted in the SecurityStrategyComplex: How to modify objects/properties in code when the user does not have the permission? ticket, with the current architecture of SecuredObjectSpaceProvider or MiddleTierServerObjectSpaceProvider, there is no easy way to achieve what you want without chanting your current approach. In these configurations, denied data may not even exist on the client in the execution context and there is no way to temporarily make it available, especially during the same transaction. That is done for more reliable application security. If the solutions outlined in the reference thread do not meet your needs, I can only offer you to grant full access to the Price and Commission properties (while using SecuredObjectSpaceProvider) and manage their availability through a ViewController manually (examples: one, two, three). This looks fine and doable for this particular scenario, especially taking into account that you likely already have a similar Controller for the "Additionally, once saved, the item should not be able to be altered" requirement where you likely manage the View.AllowEdit property based on the View.ObjectSpace.IsNewObject(View.CurrentObject) result. Since the Commission property is not supposed to be visible in the UI at all, you can hide it from the Application Model completely using the standard Browsable attribute.
Last, but not the least, you can make a fully custom form for creating SaleItem objects that will not use secured object spaces at all. Technically, you can even provide a custom Action that will invoke a standard XAF DetailView for SaleItem, but using a non-secured XPObjectSpace created using a manually configured XPObjectSpaceProvider discussed earlier. I understand that these custom solutions require additional implementation and testing, but it seems that SecuredObjectSpaceProvider provides a way more benefits and thus its features and peculiarities can be justified.

Out-of-the-box thinking: did you consider using a workflow in a middle tier server?

@Willem: If this is a question for DevExpress, please describe your own original problem or use-case scenario, expected results and other important user and deployment business requirements as well as a proposed WF-based solution idea in greater detail (preferably in a separate ticket), so that we can better understand it and provide a comprehensive answer. Thanks.