Databases
StackOverflow2013
Postsdbo
POWhat is the 'right' data structure to turn app features on/off based on 'type' of account?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POWhat is the 'right' data structure to turn app features on/off based on 'type' of account?
    primarykey
    data
    text
    <p>My app has 10 features that are enabled/disabled depending upon which of the 3 'types' of account a user has. </p> <p>Currently, I have 10 methods (one per feature) along the lines of:</p> <pre><code>def is_FEATURENAME_enabled case currentuser.accounttype when "A", "C" # account types allow to see that feature return true else return false end end </code></pre> <p>Then, in each place where I potentially disable a feature, I do</p> <pre><code>if foo.is_SOMEFEATURE_enable do stuff to enable that feature end </code></pre> <p>It works. It's not that hard to maintain. But there should be a better way. I suspect the right solution is to define some sort of structure (hash? I dunno) in one place that maps enabled features to accounttypes, then have a single method that I call something like:</p> <pre><code>if foo.is_feature_enabled(:FEATURENAME) do stuff to enable feature end </code></pre> <p>where the method <code>is_feature_enabled</code> looks at <code>currentuser.accountype</code> and checks the mapping structure to see if the identified feature is enabled.</p> <p>And I suspect the DRY way to define that mapping (given I have WAY more features than account types) is to list all the features ONCE then for each feature list the accounttypes that have access to that feature (not the other way around). That way when I add a new feature I only have to edit ONE line in the mapping. Something like:</p> <pre><code>FeatureA: usertype1 FeatureB: usertype1, usertype3 FeatureC: usertype2 ... </code></pre> <p>seems more logical and easier to maintain than:</p> <pre><code>usertype1: FeatureA, FeatureB, FeatureD, FeatureG usertype2: FeatureC, FeatureD usertype3: FeatureB, FeatureD, FeatureG, FeatureH </code></pre> <p>Any suggestions would be appreciated, and instructive for learning The Right Way to do stuff in ruby.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USsawa
    1. USjpwynn
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. POWhat is the 'right' data structure to turn app features on/off based on 'type' of account?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. POWhat is the 'right' data structure to turn app features on/off based on 'type' of account?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. POWhat is the 'right' data structure to turn app features on/off based on 'type' of account?
      1. This table or related slice is empty.
      1. VTUpMod
    1. COI don't suppose you're using RoR? In that case, have a look at https://github.com/ryanb/cancan if you haven't already. It can give you ideas to implement your own DSL for managing authorization. If you are using RoR, well, you can simply use the gem.
      singulars
      1. POWhat is the 'right' data structure to turn app features on/off based on 'type' of account?
      1. USDogbert
    2. COI would suggest using a trust-based model instead of a role-based model, where each user has a single trust-score. Then you just mark each feature with its required minimum trust-score. This is comparable to how SO works with user reputation scores (and SO has quite a bit more than 10 unlockable features), and much simpler and more scalable than a role-based model.
      singulars
      1. POWhat is the 'right' data structure to turn app features on/off based on 'type' of account?
      1. USaroth
    3. CO@aroth I agree with what you say about a trust-based model-- it can be easier for many, perhaps most cases. However, a role-based model is indispensable in some cases, where there isn't a strict "ladder." (E.g., there are things teachers can do that students can't, like grade papers, while there are things students can do that teachers can't, like submit papers. Or, cops can file arrest paperwork, but not sentence people, and judges can sentence people but not arrest people.) So think about your particular requirements and try to get away with a trust-model if you can, but not if you can't.
      singulars
      1. POWhat is the 'right' data structure to turn app features on/off based on 'type' of account?
      1. USDomingo Ignacio
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload