Skip to content

caleon/juscribe.alpha

Repository files navigation

This app is a means to extend the concept of a blog and allow it to serve as a user's "home page" on the web, allowing him to clip various external sources into a layout on his page, manage multiple blogs within his one account, finely control access controls, and later on, include mini-apps from within the OpenSocial network. This app is meant to be the socially evolved blog network, with personalized news utilizing data from a user's social graph.

This app has a number of key libraries that can and will be used with my other projects. The concept of a Widget as it applies to this project is that it is a clipping of a model object that can be placed on a user's page. For instance, if John writes an Article that I find pertinent to my situation or that my readers may find interesting, I can clip that article (creating a Widget object with me as its user), and later place it somewhere on my page. Most of the models are "widgetable".

Separate is the notion of a Blog which is described as a set of Articles under a similar topic or category. In this manner a user may have many unrelated Blogs. Blogs can be owned by a "bloggable" which is either a User or a Group (a collection of Users through Memberships).

The single largest integrated library is the "acts_as_accessible" library which, when included into a model, gives it a fine grained control of who can or cannot see/edit a model. By default any model object is public until the privacy is toggled (ex: article.rule.toggle_privacy!) in which case only users "allowed" can access it (ex: article.rule.allow!(:user, colin)), or by extension, groups (ex: article.rule.allow!(:group, friends)). Toggling privacy takes it between two states: in private state, the denied users/groups do not matter, and in public state, the allowed users/groups do not matter. There is an intermediate level of privacy called "protected" which is when the rule is toggled to "public" but has entries in its "denied" list.

It is prohibited from doing something like article.allow!(:user, colin) because many separate and unrelated objects may share the same rule (PermissionRule), so it's imperative to make this distinction.

By default all objects are accessible by anyone including non-logged-in users. By default, only the owner of a model can edit that model. Finer control is possible by overriding the methods #accessible_by? and #editable_by? in each model, making sure "super" is incorporated. You can allow more people to edit a model by calling article.rule.add_boss!(:user, colin).

This determines who has various degrees of access throughout the app, assisted by a controller method verify_login_on(*args) where the symbolized action names are provided as arguments at the class level. Those actions, if using the standard #setup method within the controllers, will get authorized according to their PermissionRules' #accessible_by? method, but you can call an additional check to verify #editable_by? by calling authorize(@object, :editable => true).

About

This was my pet project that is currently offline as it awaits a full rewrite with Rails > 3

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published