-
Please describe in greater detail permissions that are associated with the Value class. The permissions that you have posted don't grant any operation for the Value class. Alternatively, create a simple application that demonstrates this issue. This will help us understand the situation and provide you with an appropriate solution.
-
Here. Log in as Operator, navigate to Indicator Form, open record, in the detal view open Indicator Form Report, open any Indicator Form Cell Value and you'll see, that you cant edit it. Now, navigate to Indicator Form Report, open record, open any Indicator Form Cell Value and you'll be able to edit it. I need to let user edit it, regardless of from where he opened Indicator Form Cell Value.
Hope, it make any sense.
-
Thank you for the update.
We're working on your issue and we will post our resolution as soon as possible. Please stay tuned.
Hello,
Our research has shown that for the correct work it is necessary to give the Write permission for the IndicatorForm member of the IndicatorFormReport class (this member is a back association reference). I hope you find this information helpful.
-
I see... All association sides must be editable then. Thanks!
-
You are always welcome, Alex!
-
Hmmm... I tried your approach and it worked, as expected, but now im faceing another problem - im forced to expose both sides of association, so how i suppose to protect IndicatorForm property from modification from user, that should not change it?
-
Thank you for the update. Our additional research shows that this is a result of the Security - The HasRightsToModifyMemberController incorrectly marks the entire ListPropertyEditor as readonly when the Write operation is denied for the corresponding collection member in our product. We will do our best to fix it as soon as we can.
-
That means that i can remove write permission on master object association when this problem is fixed?
-
Exactly. You will not need an explicit permission for another side of your association.
This behavior is a specificity of XAF user interface part and is not related to security: the IndicatorFormReports editor is marked as read-only in the IndicatorForm_DetailView view, so the opened IndicatorFormReport_DetailView view is also opened as read-only.
In contrast, the IndicatorFormReport_DetailView view is not set read-only when it is opened from a root ListView. That is why the IndicatorFormReport_DetailView view is read-only in one case and editable in another. We will see how to improve this situation though I cannot promise any time frame because the old functionality is based on this behavior.
You can find more details about how to diagnose this situation at Why is it disabled?.
-
I figured as much. I hope you will resolve this situation - MemberLevelSecurity is rendered useless by this behaviour, and i have many similar scenarios in my project. Im sure, many others too.
-
I have registered the corresponding ticket in our database: Security - A detail view should be set to readonly in accordance with security settings if it is opened from another readonly view.
Please track it to be notified when its status is changed. -
Thanks!
-
You are welcome!
Is your intention to post an answer to your own question?
- If so, then proceed.
- If you simply wanted to post additional information, ask for further clarification, or to just say "Thanks!", please click Leave a Comment.
- If you wish to edit your original question, please use the Edit button in the Toolbox at the top right corner of that entry.
Facebook
Twitter
Google+