Hi All, I am making a DAM (seems to be the hip thing to do these days). It is for the company that I work for. We have some really weird domain rules that have prevented me from just using a simple directory structure file permission system. I have come up with a solution but I wanted to run it by you gurus to ensure that I am not recompiling the wheel here. Basically the domain rule is: A user should be able to access a category and the assets within the category only if they have the appropriate permissions. There are assets within a category, which can have different access rights meaning having access to the root category does not mean that you have access to all the files within. Here is what I have laid out as a possible structure: User A user is a person who has access to the site. The content a user can see, and the effects they have over it depend on their roles and permissions. A user can: • Have access to many categories • Have many roles • Belong to many user groups Category A category is a specific area of the site where assets and other categories are stored. Content managers can specify asset restrictions for categories. For example, a category may only allow images under five megabytes to be uploaded. By default, the category does not have any restrictions on asset types. A category can: • Have many assets • Be accessed by many users • Be contained in many permission groups Asset An asset is any file uploaded into a category. While Assets can be any digital file that can be stored on a computer, they are typically, images, text documents or spreadsheets. An asset can have several attributes, which a file owner can specify. An asset can have: • One owner • Belong to many permission groups • Belong to one category • Can be marked as locked, which means another asset cannot overwrite it • Can be marked as private, which means only the owner can see it • Can be marked as archived, which means only user administrators can see it Permission Groups A permission group is a collection of permissions tied to a central group. Using permission groups a user admin can assign access to a user by assigning them to a group rather than assigning them permissions individually. A permission group can have: • One to many users • One to many categories • One to many assets Is this a smart way to go about things? -- -------------------------------------------------------------------- I am Mark Daggett and I approve this message. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
Can ActiveRBAC do what you want? https://activerbac.turingstudio.com/trac Peter On 12/2/05, M Daggett <heavysixer@gmail.com> wrote:> > Hi All, > I am making a DAM (seems to be the hip thing to do these days). It is > for the company that I work for. We have some really weird domain > rules that have prevented me from just using a simple directory > structure file permission system. I have come up with a solution but I > wanted to run it by you gurus to ensure that I am not recompiling the > wheel here. > > Basically the domain rule is: > A user should be able to access a category and the assets within the > category only if they have the appropriate permissions. There are > assets within a category, which can have different access rights > meaning having access to the root category does not mean that you have > access to all the files within. > > Here is what I have laid out as a possible structure: > > User > A user is a person who has access to the site. The content a user can > see, and the effects they have over it depend on their roles and > permissions. > A user can: > • Have access to many categories > • Have many roles > • Belong to many user groups > > Category > A category is a specific area of the site where assets and other > categories are stored. Content managers can specify asset restrictions > for categories. For example, a category may only allow images under > five megabytes to be uploaded. By default, the category does not have > any restrictions on asset types. > A category can: > • Have many assets > • Be accessed by many users > • Be contained in many permission groups > > Asset > An asset is any file uploaded into a category. While Assets can be any > digital file that can be stored on a computer, they are typically, > images, text documents or spreadsheets. An asset can have several > attributes, which a file owner can specify. > An asset can have: > • One owner > • Belong to many permission groups > • Belong to one category > • Can be marked as locked, which means another asset cannot > overwrite it > • Can be marked as private, which means only the owner can see it > • Can be marked as archived, which means only user administrators > can see it > > Permission Groups > A permission group is a collection of permissions tied to a central > group. Using permission groups a user admin can assign access to a > user by assigning them to a group rather than assigning them > permissions individually. > A permission group can have: > • One to many users > • One to many categories > • One to many assets > > > Is this a smart way to go about things? > -- > -------------------------------------------------------------------- > I am Mark Daggett and I approve this message. > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
So this is a framework for role based systems? It looks very young (though not as young as mine considering it is paper-based at this point). The idea of a Framework is really good, I guess I should have considered that rather than the role your own approach. Have you used this system before? Thanks for the link, Mark On 12/2/05, Peter Michaux <petermichaux@gmail.com> wrote:> Can ActiveRBAC do what you want? > > https://activerbac.turingstudio.com/trac > > Peter > > > On 12/2/05, M Daggett <heavysixer@gmail.com> wrote: > > > > Hi All, > > I am making a DAM (seems to be the hip thing to do these days). It is > > for the company that I work for. We have some really weird domain > > rules that have prevented me from just using a simple directory > > structure file permission system. I have come up with a solution but I > > wanted to run it by you gurus to ensure that I am not recompiling the > > wheel here. > > > > Basically the domain rule is: > > A user should be able to access a category and the assets within the > > category only if they have the appropriate permissions. There are > > assets within a category, which can have different access rights > > meaning having access to the root category does not mean that you have > > access to all the files within. > > > > Here is what I have laid out as a possible structure: > > > > User > > A user is a person who has access to the site. The content a user can > > see, and the effects they have over it depend on their roles and > > permissions. > > A user can: > > • Have access to many categories > > • Have many roles > > • Belong to many user groups > > > > Category > > A category is a specific area of the site where assets and other > > categories are stored. Content managers can specify asset restrictions > > for categories. For example, a category may only allow images under > > five megabytes to be uploaded. By default, the category does not have > > any restrictions on asset types. > > A category can: > > • Have many assets > > • Be accessed by many users > > • Be contained in many permission groups > > > > Asset > > An asset is any file uploaded into a category. While Assets can be any > > digital file that can be stored on a computer, they are typically, > > images, text documents or spreadsheets. An asset can have several > > attributes, which a file owner can specify. > > An asset can have: > > • One owner > > • Belong to many permission groups > > • Belong to one category > > • Can be marked as locked, which means another asset cannot > overwrite it > > • Can be marked as private, which means only the owner can see it > > • Can be marked as archived, which means only user administrators > can see it > > > > Permission Groups > > A permission group is a collection of permissions tied to a central > > group. Using permission groups a user admin can assign access to a > > user by assigning them to a group rather than assigning them > > permissions individually. > > A permission group can have: > > • One to many users > > • One to many categories > > • One to many assets > > > > > > Is this a smart way to go about things? > > -- > > > -------------------------------------------------------------------- > > I am Mark Daggett and I approve this message. > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >-- -------------------------------------------------------------------- I am Mark Daggett and I approve this message. _______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails
I don't know much about ActiveRBAC yet. I just started reading about it a week ago. I've read that it will be switching to an engine soon (James Adam even offered to help) and eventually ActiveRBAC would like to be multilingual. I'm hoping it is what I need for roles based authorization in the store.rbopen source ecommerce project I am working on. Maybe you could join the ActiveRBAC mailing list and ask questions there. The author answers questions quickly. -Peter On 12/2/05, M Daggett <heavysixer@gmail.com> wrote:> > So this is a framework for role based systems? It looks very young > (though not as young as mine considering it is paper-based at this > point). The idea of a Framework is really good, I guess I should have > considered that rather than the role your own approach. > > Have you used this system before? > Thanks for the link, > Mark > > On 12/2/05, Peter Michaux <petermichaux@gmail.com> wrote: > > Can ActiveRBAC do what you want? > > > > https://activerbac.turingstudio.com/trac > > > > Peter > > > > > > On 12/2/05, M Daggett <heavysixer@gmail.com> wrote: > > > > > > Hi All, > > > I am making a DAM (seems to be the hip thing to do these days). It is > > > for the company that I work for. We have some really weird domain > > > rules that have prevented me from just using a simple directory > > > structure file permission system. I have come up with a solution but I > > > wanted to run it by you gurus to ensure that I am not recompiling the > > > wheel here. > > > > > > Basically the domain rule is: > > > A user should be able to access a category and the assets within the > > > category only if they have the appropriate permissions. There are > > > assets within a category, which can have different access rights > > > meaning having access to the root category does not mean that you have > > > access to all the files within. > > > > > > Here is what I have laid out as a possible structure: > > > > > > User > > > A user is a person who has access to the site. The content a user can > > > see, and the effects they have over it depend on their roles and > > > permissions. > > > A user can: > > > • Have access to many categories > > > • Have many roles > > > • Belong to many user groups > > > > > > Category > > > A category is a specific area of the site where assets and other > > > categories are stored. Content managers can specify asset restrictions > > > for categories. For example, a category may only allow images under > > > five megabytes to be uploaded. By default, the category does not have > > > any restrictions on asset types. > > > A category can: > > > • Have many assets > > > • Be accessed by many users > > > • Be contained in many permission groups > > > > > > Asset > > > An asset is any file uploaded into a category. While Assets can be any > > > digital file that can be stored on a computer, they are typically, > > > images, text documents or spreadsheets. An asset can have several > > > attributes, which a file owner can specify. > > > An asset can have: > > > • One owner > > > • Belong to many permission groups > > > • Belong to one category > > > • Can be marked as locked, which means another asset cannot > > overwrite it > > > • Can be marked as private, which means only the owner can see > it > > > • Can be marked as archived, which means only user > administrators > > can see it > > > > > > Permission Groups > > > A permission group is a collection of permissions tied to a central > > > group. Using permission groups a user admin can assign access to a > > > user by assigning them to a group rather than assigning them > > > permissions individually. > > > A permission group can have: > > > • One to many users > > > • One to many categories > > > • One to many assets > > > > > > > > > Is this a smart way to go about things? > > > -- > > > > > -------------------------------------------------------------------- > > > I am Mark Daggett and I approve this message. > > > > > > _______________________________________________ > > > Rails mailing list > > > Rails@lists.rubyonrails.org > > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > > > > > > > _______________________________________________ > > Rails mailing list > > Rails@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > > > > > > -- > -------------------------------------------------------------------- > I am Mark Daggett and I approve this message. > > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > >_______________________________________________ Rails mailing list Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org http://lists.rubyonrails.org/mailman/listinfo/rails