Hi Dennis,

i would love if you make some improvements in this regard - i guess we have our solution running now since 2010 with the help of Tolis and expandFrameWork. So please take also a look on the expand solution. We can also email if you like ;)

1. Differences for which levels are you currently storing in the database and how well does this work for you (shared, user, or both)?

-> We store application diffs (= i guess this is the shared pared) which is gloably for the whole company
-> We store role diffs - those belog to a specific user role
-> We store user diffs

2. Have you required customizing differences stored in the database for already deployed production apps? If so, clarify the following points: - this is a requirement for all of our customers and is a huge benefit for us since we have so many different company types.

2.1. Was this customization done for shared or user levels?
-> almost all parts are customized - shared / role / user diffs

2.2. List the exact use-case scenarios that needed such customizations (e.g., a client screwed up a View layout and could not reset it back to normal)?
-> creating runtime member
-> customize navigation
-> customize BO captions to meet company specific "spellings"
-> customize views (detail/lsitview) layouts to meet customers specifics

2.3. Which solutions and how often did you use for this customization (e.g., direct database updates, editing raw XML after enabling the Administrative UI inside the app, etc.)?

-> take a look at expand - we use the model propertyeditor for years now ;)

2.4. How well did your current solutions for different customizations work for you so far and what could be improved in them and why?

-> currently it works pretty well - but it would be great to switch to the xaf solution OOB instead of relying on 3rd party solution.

3. Have you considered the opportunity to customize shared or user differences using the Standalone Model Editor, which visualizes the actual differences in XML content as a nodes tree? If so, clarify the following points to help us better understand the behavior you expect from such a feature:

3.1. Do you need to customize differences for shared, user or both levels?
-> every level

3.2. Taking the severeness and effect of this operation over all application users, do you think that a logon form should be shown before someone can perform this customization for security reasons? Or, how do you plan to prevent a power user from obtaining the Standalone Model Editor tool binaries and running it locally for this or even harmful purposes?

-> for us this is not a requirement since most if not any customers are not able to handle the model editor :)

thx noxe

Hi Dennis,

Thank you for creating this survey, because it covers a point that certainly deserves to be improved in XAF.
Thank you Martin Praxmarer for your comment, you are spot on.

In the application I am working on, like Martin, we use both levels: Shared differences and user differences.
It is a very good thing, but alas not enough:
Additionaly, we need a "role differences", because this would simplify the user settings assignments.

Usually, users from a specific role need specific actions available to them, and the application must prevent them to perform other actions.
For example, a "course planner" needs to create or delete new courses, or to preform specific "Course planning actions", that an "attendee" cannot do.

We solve this with burdensome solutions:

1. We build several views for the same data, one for each role combinaison.
We authorize each view separately via our own implementation ot NavigationItem authorization.
In a simple case, this would be: a view for the course planner (viewer + CRUD etc.) and a similar view for the attendee (only viewer).
I know what the XAF authorization system can do (and is useful in some situations), but in the reality, the use cases are more complex.
The XAF authorization system only covers "Create", "Edit", "Delete", "Navigate".
It does not cover the other actions (built-in or custom), or the layout of a view.
(For the little story, we implemented our own navigation authorization.
For compatibility reasons, we cannot use the new authorization system introduced in 16.2, that would enable flexible NavigationItem authorization out of the box).

2. The administrator edits the user models, to take out some of the actions, adjust view settings, etc.
This is laborious, because there could be thousands of users.
This is actually not a solution, because the users roles change over time:
A user who is a "Cource planner" today could become tomorrow a "Course administrator".
But no administrator has the time to adjust the related views every day.

I believe that a "role model difference" would greatly improve the matter, it could even be THE solution.

Role models should be additive: If a user has two roles, both role models should be merged with the Shared Model Differences before being merged with the user Model Differences.

Standalone model editor
I have never used the standalone model editor, and don't see how it could help me.

One other need that I have is to be able to edit in a graphic model editor the web specific shared model differences.

Our administrators can edit simple things in the model, or somebody from the support does it remotely.

If you see a use case where a standalone model editor can be useful, I believe that password protecting it would be a good thing. Ideally, it should be the same user/password as the one used in the application, for a specific role.

Thanks for the post and the qualified comments. I would like to second the need for role customization. We also have to use expand for this, but it would be great if this would be supported out of the box.
Regards,
Johannes

Same here, we use custom NavigationPermissions for different roles (therefore can not use the new SecuritySystem from 16.2 wg. compatibility).
We plan to integrate ActionPermissions into security system, so this would be a big help for us.
We deliver only shared models (every differentiation is handled through security/NavigationPermissions). Role models could be an improvement.