fine grained but not micro managed

gistfile1.txt

	mistergibson	do the engines declare in any explicit way, a list of capabilities - or what it is that it provides (programmatically) ?
	ordordord	Hello, when someone deletes a page in the backend, that page along with all its children are lost forever. is that correct?
09:14	Kagetsuki		mistergibson: If that engine is from a gem you'll get the dependencies when you install the gem - assuming they were properly set

09:15	Kagetsuki	however you may need to set up some engines in order if they depend on eachother
	mistergibson	Kagetsuki: that's not what I mean, wrong context
	Kagetsuki	I'm sorry, can you clarify?
09:16	mistergibson	Kagetsuki: within a deps-in-full satisfied and running state -- does the engine declare : I provide crud on model_a, crud,search on model_b ...
	mistergibson	?
	mistergibson	verb : noun pairs
09:17	mistergibson	just speculating
	mistergibson	I suppose you could just do a list of the engines models and list the methods of them
09:18	mistergibson	but that does not provide context as to what is intended as public interface for interaction between itself and other engines
	Kagetsuki	well I'm assuming if you dug into the controllers and what not you'd be able to figure it out? I don't think I understand your situation well enough.
	mistergibson	I have no situation yet -- I'm just doing some conceptual modeling now
	Kagetsuki	perhaps you want to add functionality but aren't sure if an engine already available will provide that?
09:19	mistergibson	or
	mistergibson	I have to establish fine grained permissions to user roles, etc
	mistergibson	not just 'can access plugin or not'
	Kagetsuki	aah, I'm working on something like that myself
	mistergibson	really?
09:20	mistergibson	I'm going to be messing with the roles management section
	Kagetsuki	well probably not in the depth that you are looking for
		<- ordordord has disconnected (Quit: ordordord)
	Kagetsuki	there is refinerycms-members that you could look at. It does not provide the depth of control you are looking for, but it could be a start or a reference
09:21	mistergibson	I was wondering about making a formal proposal for what I'm talking about. The trick is to do it in a way that provides enough external hints and guides, without constraining free-form implementation
	mistergibson	I saw that
	Kagetsuki	I actually just got rid of it because it did not suite my needs
	mistergibson	would you consider a discussion with rbriank, myself, and others about this area?
	Kagetsuki	so you mean to actually propse something for the core
09:22	Kagetsuki	I seriously doubt what I am trying to do is worth any consideration for a core implementation
	mistergibson	I'm not sure how else to do it -- it would require the engines to make some statement about their public interfaces for others to interact with in my estimation
	Kagetsuki	aaah, now I understand what you are saying
	mistergibson	that's ok -- what I'm looking for in the discussion is to basically flesh it out and attempt to meet several goal areas at the same time
09:23	Kagetsuki	you basically want some way to derive what an engine can do, and without explicitly setting things determine if a user can access that
	mistergibson	sort of
	mistergibson	roles get a record of what engines' verb:noun pair are enabled, and that gets used for the user
09:24	mistergibson	so... in a helper or controller you simply do current_user.can_do?(:verb, :noun)
	Kagetsuki	like (:create, :news)?
	mistergibson	yes
	Kagetsuki	(:delete, :blog)
	mistergibson	or even (:some_funky_action, :thingy)
	mistergibson	yup
09:25	Kagetsuki	that's actually interesting, I could easily see using that
	mistergibson	so, you can list crud +
	Kagetsuki	:index, :product
09:26	Kagetsuki	:reorder, :items
	mistergibson	it is a set of ideas that gathered around what I see going on. members, members-ci, membership ... this grouped permission thing keeps trying to get into the code --- because it is *needed*
	mistergibson	exactly
09:27	mistergibson	so, instead of forcing everyone to re-invent a wheel : provide a basic one that you can embellish
	Kagetsuki	I think you'd need to add to existing engines, I can't think of what would provide that grain of detail off hand
	mistergibson	yes, that's the rub
	mistergibson	but at least it is early in the life of Refinery
	mistergibson	a hassle to be sure, but doable
09:28	mistergibson	a year from now -- good luck
	mistergibson	and you'll end up with 5 differing systems for it
	mistergibson	>ouch<
	Kagetsuki	but simply having nothing accessable until it was defined would be "secure", and if you had a secondary file that you could use to set those attributes without actually touching the engine you wouldn't have to worry about customizations to engines being destroyed in updates
09:29	mistergibson	the roles and permissions are in a table
	mistergibson	like anything else
	mistergibson	merged in, seeded with defaults
	mistergibson	but you'll have to set them when you add an engine, or it must be provided for what defaults are set by a soft policy of some sort
	Kagetsuki	aah, so if you have a standard set of engines already just adding those defaults to the seeds would be enough
09:30	mistergibson	pretty much
	Kagetsuki	if engines had overrides you could put that in the migration
	Kagetsuki	clever
	mistergibson	engines only tell you what they do for you
	mistergibson	your roles and permissions store how it is set loose
	Kagetsuki	assuming they tell you
	mistergibson	well, that's what an admin does -- sets security policy implementations
09:31	mistergibson	I'd consider it a part of the setup
	Kagetsuki	either way I'll be honest and tell you this is a problem beyond me at the moment. I'm still very new to Rails and Refinery
09:32	Kagetsuki	I do think that's a very good idea though
	mistergibson	I'm new to RefineryCMS ... fresh off the boat
	Kagetsuki	as long as it was unintrusive by default of course
	mistergibson	but I see the need for this very clearly
	mistergibson	sure, where possible
09:33		-> veronatii has joined refinerycms
	mistergibson	the only thing I think I'm really asking from the existing engines, is to give me a bloody hash of what your engine does in verb:noun pairs ... not too much to ask 
	mistergibson	might take them all of 5 minutes?
09:34	mistergibson	I'm not asking them to give me a typed arity table or some crap ... just a simple hash of what it will let people do...
	Kagetsuki	I actually have no idea on that one. I'm assuming you could derive a fair ammount of information from the controllers at least
09:35	Kagetsuki	but probably not in the detail or context you would really need
	Kagetsuki	especially for oddball non CRUD actions
09:36	mistergibson	perhaps, but it would be very easy for them to add one method : def capabilities();{:noun => [:action1, :action2, :action3]};end
	mistergibson	not the full method list, but rather an activity-level :symbol
09:37	mistergibson	it won't substitute for your reviewing the engine docs
	mistergibson	but it will give you a very easy to enforce security model you don't have to micro-manage in the controller, and helpers
	Kagetsuki	as long as there is a safe fallback and way to set that externally from the engine root I think that's a nice idea
	mistergibson	safe fallback?
09:38	mistergibson	... and yes - the engine simply makes a declaration via this idea ... it comes from within it 
	Kagetsuki	 - if the tags aren't set then have it use a default set of rules that wouldn't present a security threat on a running system
09:39	mistergibson	I'd have to explore that
	mistergibson	crud would be default on any engine model
	Kagetsuki	well, disabling create and delete for any non-administrator class user by default would probably be good enough
	mistergibson	but it is up to the helper/controller to enforce the security ... that is where the flexibility comes in
09:40	mistergibson	sure, imagine instead of on/off plug-in access you have: read, write, create, destroy, x,y,z
	mistergibson	with checkboxes
		-> nicinabox has joined refinerycms
	Kagetsuki	right, like how there is the "plugin access" checkboxes there now - add a subset below each checkbox with the permissions
09:41	Kagetsuki	having groups would be a good idea as well
	mistergibson	roles will fill that one
	Kagetsuki	ah, yes
	mistergibson	it will be the grouping index
09:42	Kagetsuki	sounds solid, I like it
	Kagetsuki	definitely something worth being in the core functionality

..


	jadams	but I'd like to have all of this work nicely together / promote a good memberships engine that's modular and maintained
03:22	mistergibson	ok : if we can get any given engine to support a method called capabilities and return a hash like {:model_name_a => [:action1, :action2, :action3], :engine_name => [:action1, :action2]} ...
	mistergibson	that will supply a much needed set of hints to the roles managment page
03:23	mistergibson	where you select more than just plug-in access/or/not but a finer grained permission set for that role group.
	mistergibson	and then simply add any given user to that role group
	mistergibson	*then*
03:24	mistergibson	in the helpers / controllers you call a method added to current_user : if current_user.can_do?(:noun, :verb);do_this;else;do_that;end
03:25	mistergibson	when the user logs in, an OR compiled set of nouns/verbs like in a keychain from the various roles the user is a part of
	mistergibson	is stored in the session var
	mistergibson	so there isn't massive repetitive calls to the db slowing the whole affair down
03:26	mistergibson	so the security prefs are enforced in the helper (building up the page widgets / editors/ etc)
	jadams	would we use cancan for can_do?
	mistergibson	and in the controller (in case someone tries something sneaky)
	mistergibson	hehe
03:27	mistergibson	whatever, it is just intended to be simple
	jadams	sure
	mistergibson	that is the nutshell of the idea
	mistergibson	it would require existing engines to support this method
	mistergibson	and future ones as well
	mistergibson	but it is only one method
	jadams	it wouldn't require it if they just don't use role management, would it?
03:28	mistergibson	if your custom uber app doesn't use this feature -- no harm no foul
	mistergibson	just do as you do -- it does not get in the way
	mistergibson	but it is always there if you want to mix it in at any point
	jadams	sure
	jadams	I like the idea I think
03:29	mistergibson	so I'm thinking it provides something basic, without locking you in
	jadams	would need to see more concrete examples, but I mostly follow
	mistergibson	this discussion is the prelude to an explanation/pitch paper I'll throw at Phillip and see if it sticks on the wall 
03:30	mistergibson	the reason I'm proposing it is that I get he sense something like this is trying to emerge ... but from 3 to 5 sources ... all different ... 
03:31	mistergibson	it is great to be creative in almost every facility except permission systems ... we just can't have 5 of them
	mistergibson	conflicts, mixed messages to devs
	mistergibson	members, members-ci, membership ... on and on and sounds like two more I didn't know about
03:32	mistergibson	I see trouble going down that road
		-> jswanner has joined refinerycms
03:33	mistergibson	so, if core provides a basic system to address it, without micromanaging the deal -- I think all can use it as they please and the area is covered pretty basically and well
	mistergibson	this can also apply to page access permissions : access based upon roles as group index
03:34	mistergibson	but this would be written by the core team, and therefore won't bugger anything unseen
	mistergibson	your thoughts?
03:35	jadams	I support the idea certainly, but parndt/resolve have the vision for the project obv
	mistergibson	sure, just want to pitch it and see if it sticks
	mistergibson	I think the mods to do it are so minimal overall, and it is early yet in the engine pool development, that I think the time is now to do *something*
	mistergibson	we'll see what he says
03:36	mistergibson	if you tried that in a year with 50 engines ... much more nasty affair
03:44	mistergibson	well, I'm all talked out 
03:49	jadams	sorry
	jadams	was afk
	jadams	lemme read 
	mistergibson	ok
03:50	jadams	so the only problem I see is if people want to use it as an app framework for sites they've already started on, it might be hard to for instance change what the 'public facing user class' is called generally
	jadams	but I guess they can just work around it?
03:51	mistergibson	could you characterize a bit?
03:53		<- jswanner has disconnected (Quit: Leaving.)
	jadams	erm, just if this is going to mean that lots of engines end up expecting a ::Refinery::Member class to be an app's public facing users, but I have an app I want to switch to using refinery that instead has members called Blokes, all those engines cannot easily use my public-facing member class
	jadams	but I don't know that's a big deal
03:54	mistergibson	no, that is what the added method to current_user is for
	jadams	ahh
	mistergibson	you call current_user.can_do?(:verb, :noun) or something .. you don't have to map a class dep
03:55	jadams	sounds good
	mistergibson	and permissions are cached in the session var for performance

fin