locked
Dynamic Data (Scaffolding Templated Sites) [REPOST] RRS feed

  • Question

  • User612007317 posted

    Just been using this for a few days, but love it already.

    I was wondering what some of the plans were for things like role/user-level security, or even 'type' security.

    For some real-world 'for-instance' examples:

    • How would I go about deciding/filtering out which tables are visible?
    • What would the guidance be for making a particular field available to edit for a particular user (set of users)?
    • Can I tie into events (or something) at the model level to filter out data?

    I easily built a custom control based off some of your examples and it's already up and working in the site.  I can really see where this is going to help in the protyping of admin apps, specifically with internal or early-versions of software, and while I get the idea it is really a springboard for more complex development, what is available here is just awesome.

     Thanks for any info/suggestions to the above questions.

    Cheers,

    -jc

    Thursday, January 3, 2008 9:32 AM

All replies

  • User1641955678 posted

    Hi James,

    Thanks for the good feedback on Dynamic Data!

    To decide which tables are visible, our plan is to provide a new attribute that you can place on the partial class (e.g. Scaffold(true)).  So the behavior will be:

    • By default, nothing is exposed (we need a safe default)
    • You can turn on one switch to expose all tables
    • You can also selective turn on/off individual tables

    To be clear, we don't have this granularity today, but we will in the next drop.

    As for the security model within one table, we came to the conclusion that we should not try to define a way to automatically do role management and similar things at the model level, because there are just too many different ways that people want to do things.  Instead, the recommended approach will be to add custom code to the page/code behind to call into whatever security layer makes sense for you.  For example, you could make a call that determines whether the current user is allowed to modify the current table, and you'd then set the GridView (or other control) into the correct mode (e.g. AutoGenerateEditButton=false/true).

    So another way to put it is that we will probably not try to invent any new security paradigm, but will instead just make sure that there are enough hooks for users to plug in the security model that works for them.

    thanks,
    David

    Friday, January 4, 2008 2:41 AM
  • User612007317 posted

    Thanks David,

    The Scaffold(true) attribute is good, but won't let me work at a per-user level of granularity, if I understand it correctly.  For example, an administrator should be able to see a ref code table whereas a standard user would not.

    Would the use of this attribute preclude the table from all scaffolding, or just the appearance on the default table list page?

    On the topic of field-level security (where a receiving clerk cannot change the category of widgets, but could add a new inventory row) I'm going to infer here, but I get the impression that with the 'buddy' pattern and the application of metadata in that manner I would gain the field-level control I am looking for.  Is that correct?

    And to be clear, I'm glad you're taking the approach you're taking on security!  The hooks to allow me to tie into the paradigm we've chosen is exactly what we're looking for  ;)

    I suppose the new build with multiple contexts would also open a few doors, but even then I would have some trouble working with multiple types accross different namespaces to get that to work...

    ...sorry for the meandering, I'm just really into this feature/framework/package and want to find where the bounds of it fit for development.

    Cheers,

    -jc

    Friday, January 4, 2008 10:24 AM
  • User581277377 posted

    I'm also working with dynamic scaffolding that I currently have to write custom code to hide certain fields from certain roles/users. Besides, I also need to override the DisplayName class for localization. I hope the next release will built-in support such security and localization features.

    Sunday, August 22, 2010 1:01 AM
  • User-693128592 posted

    Will it be possible in the future to have master/details forms generated automatically altogether, and not in different pages? That's a very usual requests we have from customers

    Monday, March 14, 2011 1:07 PM
  • User-330204900 posted

    Hi there, I will have an articel posted on my blog in the next few weeks that does this in DD for Linq to SQL, Entity Framework and Domain Service.

    Thursday, March 17, 2011 12:32 PM
  • User-693128592 posted

    sorry, this topic has almost 3 years and I posted another question 3 days ago, but Im still wondering if you are replying to me or to someone else in this topic. By "this" do you mean the Masters/Details feature? Greetings.

    Thursday, March 17, 2011 1:01 PM
  • User-330204900 posted

    Hi Pablodalma93, I am replyint to you yes [:)]

    Friday, March 18, 2011 7:09 AM