From martinscheffler at googlemail.com Fri Apr 14 10:05:18 2006 From: martinscheffler at googlemail.com (Martin Scheffler) Date: Fri, 14 Apr 2006 16:05:18 +0200 Subject: [Adminpages-development] xxxxxxxxxxxxxxxx Message-ID: <372f5c120604140705n73bd05a7r79ae647a82b4dbbd@mail.gmail.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/adminpages-development/attachments/20060414/945ac694/attachment.htm From martinscheffler at googlemail.com Fri Apr 14 10:07:11 2006 From: martinscheffler at googlemail.com (Martin Scheffler) Date: Fri, 14 Apr 2006 16:07:11 +0200 Subject: [Adminpages-development] hhhhhhhhhhhhhhhhhh Message-ID: <372f5c120604140707j5b1419bi4c6d9741a67b5847@mail.gmail.com> iuzhu -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/adminpages-development/attachments/20060414/a79b2e32/attachment.htm From martinscheffler at googlemail.com Fri Apr 14 10:09:31 2006 From: martinscheffler at googlemail.com (Martin Scheffler) Date: Fri, 14 Apr 2006 16:09:31 +0200 Subject: [Adminpages-development] goddamnit Message-ID: <372f5c120604140709w56ce2b84l20dfdfedd88d1726@mail.gmail.com> iojoim -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/adminpages-development/attachments/20060414/53582ca2/attachment.htm From wooyay at web.de Fri Apr 14 10:10:41 2006 From: wooyay at web.de (wooyay) Date: Fri, 14 Apr 2006 16:10:41 +0200 Subject: [Adminpages-development] tedst Message-ID: <443FAD61.5050808@web.de> From martinscheffler at googlemail.com Mon Apr 17 15:18:13 2006 From: martinscheffler at googlemail.com (Martin Scheffler) Date: Mon, 17 Apr 2006 21:18:13 +0200 Subject: [Adminpages-development] ACLs, permissions Message-ID: <372f5c120604171218v3478cf1fie0cea4b6e1fca8be@mail.gmail.com> Hi all, I took a look at various methods for authentication and ownership handling. Could you tell me what your ideas for authentication are? I would go like this: Three roles: admin, designer, editor Editor can only edit content and pages Designer can also edit templates Admin can also edit element types and users What kind of permission system do we need for pages and content? Do we need any at all? In all my previous projects I never had any use for fine-grained access control, every user could edit every page. What do you think? This is the stuff I found: UserStamp plugin http://www.delynnberry.com/pages/userstamp/ The Userstamp Plugin extends *ActiveRecord::Base * to add automatic updating of *created_by* and *updated_by* attributes of your models in much the same way that the *ActiveRecord::Timestamp * module updates *created_(at/on)* and *updated_(at/on)* attributes. Could be useful, have to take a closer look LoginEngine+UserEngine: simple, wide-spread usage, tested, takes long to install? ActiveRBAC https://activerbac.turingstudio.com Authentication with more fine-grained role handling, role inheritance model, groups. Seems to be pretty new. I got it to work without problems. Mac Engine http://www.ruby-forum.com/topic/61145#new to provide finer grained control over ActiveRecord results than can be achieved by using user_engine. The intention is to provide filtering of results and assigning permissions to users/groups over what they can access. Didn't really take a look at it, but is described as alpha software Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/adminpages-development/attachments/20060417/c098da53/attachment.htm From heikki74 at gmail.com Mon Apr 17 16:39:50 2006 From: heikki74 at gmail.com (=?ISO-8859-1?Q?Heikki_Yl=F6nen?=) Date: Mon, 17 Apr 2006 23:39:50 +0300 Subject: [Adminpages-development] ACLs, permissions In-Reply-To: <372f5c120604171218v3478cf1fie0cea4b6e1fca8be@mail.gmail.com> References: <372f5c120604171218v3478cf1fie0cea4b6e1fca8be@mail.gmail.com> Message-ID: <9c18518b0604171339j144a69feo1653408fff3bc856@mail.gmail.com> I think it would be good to keep this as simple as possible. One super-user who can do everything and possibility to restrict/allow access to created page by choosing user/users. (*the following might differ from your goals*) What if all the elements were similar to "render component"? That way it would be possible to _build_ custom cms. Cms-pages would be just like the other pages, but with restricted access. Superuser would just place components on the right pages and give access to the page to right users. I did 2 ajax render components for fun. They worked pretty well. One was for adding posts and one for uploading images. Static version would then be used on the front end. I had to modify the code a bit, so that it passes rest of the url (the part that it didn't recognize as pages) to the component. That way the component could show a certain post based on the id. Ajax-versions didn't need that of course. (*cms worth looking*) I tried Rubricks CMS today. It looks really flexible, but the UI wasn't clear. Drag'n'Drop works well and user management seems good. http://rubricks.org/index_en.html -- Heikki 2006/4/17, Martin Scheffler : > > Hi all, > > I took a look at various methods for authentication and ownership > handling. > > Could you tell me what your ideas for authentication are? > I would go like this: > Three roles: admin, designer, editor > Editor can only edit content and pages > Designer can also edit templates > Admin can also edit element types and users > > What kind of permission system do we need for pages and content? Do we > need any at all? > In all my previous projects I never had any use for fine-grained access > control, every user could edit every page. What do you think? > > This is the stuff I found: > > UserStamp plugin > http://www.delynnberry.com/pages/userstamp/ > The Userstamp Plugin extends *ActiveRecord::Base > * to add automatic updating of *created_by* and *updated_by* attributes of > your models in much the same way that the *ActiveRecord::Timestamp > * module updates *created_(at/on)* and *updated_(at/on)* attributes. > Could be useful, have to take a closer look > > LoginEngine+UserEngine: > simple, wide-spread usage, tested, takes long to install? > > ActiveRBAC > https://activerbac.turingstudio.com > Authentication with more fine-grained role handling, role inheritance > model, groups. Seems to be pretty new. I got it to work without problems. > > Mac Engine > http://www.ruby-forum.com/topic/61145#new > > to provide finer grained control over ActiveRecord results than can be > achieved by using user_engine. The intention is to provide filtering of > > results and assigning permissions to users/groups over what they can > access. > > Didn't really take a look at it, but is described as alpha software > > Martin > > _______________________________________________ > Adminpages-development mailing list > Adminpages-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/adminpages-development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/adminpages-development/attachments/20060417/66ee94f7/attachment.htm From heikki74 at gmail.com Mon Apr 17 16:39:50 2006 From: heikki74 at gmail.com (=?ISO-8859-1?Q?Heikki_Yl=F6nen?=) Date: Mon, 17 Apr 2006 23:39:50 +0300 Subject: [Adminpages-development] ACLs, permissions In-Reply-To: <372f5c120604171218v3478cf1fie0cea4b6e1fca8be@mail.gmail.com> References: <372f5c120604171218v3478cf1fie0cea4b6e1fca8be@mail.gmail.com> Message-ID: <9c18518b0604171339j144a69feo1653408fff3bc856@mail.gmail.com> I think it would be good to keep this as simple as possible. One super-user who can do everything and possibility to restrict/allow access to created page by choosing user/users. (*the following might differ from your goals*) What if all the elements were similar to "render component"? That way it would be possible to _build_ custom cms. Cms-pages would be just like the other pages, but with restricted access. Superuser would just place components on the right pages and give access to the page to right users. I did 2 ajax render components for fun. They worked pretty well. One was for adding posts and one for uploading images. Static version would then be used on the front end. I had to modify the code a bit, so that it passes rest of the url (the part that it didn't recognize as pages) to the component. That way the component could show a certain post based on the id. Ajax-versions didn't need that of course. (*cms worth looking*) I tried Rubricks CMS today. It looks really flexible, but the UI wasn't clear. Drag'n'Drop works well and user management seems good. http://rubricks.org/index_en.html -- Heikki 2006/4/17, Martin Scheffler : > > Hi all, > > I took a look at various methods for authentication and ownership > handling. > > Could you tell me what your ideas for authentication are? > I would go like this: > Three roles: admin, designer, editor > Editor can only edit content and pages > Designer can also edit templates > Admin can also edit element types and users > > What kind of permission system do we need for pages and content? Do we > need any at all? > In all my previous projects I never had any use for fine-grained access > control, every user could edit every page. What do you think? > > This is the stuff I found: > > UserStamp plugin > http://www.delynnberry.com/pages/userstamp/ > The Userstamp Plugin extends *ActiveRecord::Base > * to add automatic updating of *created_by* and *updated_by* attributes of > your models in much the same way that the *ActiveRecord::Timestamp > * module updates *created_(at/on)* and *updated_(at/on)* attributes. > Could be useful, have to take a closer look > > LoginEngine+UserEngine: > simple, wide-spread usage, tested, takes long to install? > > ActiveRBAC > https://activerbac.turingstudio.com > Authentication with more fine-grained role handling, role inheritance > model, groups. Seems to be pretty new. I got it to work without problems. > > Mac Engine > http://www.ruby-forum.com/topic/61145#new > > to provide finer grained control over ActiveRecord results than can be > achieved by using user_engine. The intention is to provide filtering of > > results and assigning permissions to users/groups over what they can > access. > > Didn't really take a look at it, but is described as alpha software > > Martin > > _______________________________________________ > Adminpages-development mailing list > Adminpages-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/adminpages-development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/adminpages-development/attachments/20060417/66ee94f7/attachment-0003.htm