Database scheme was properly displayed on web page but not in email: aiki_users 1-------N aiki_users_usergroups N-------1 aiki_users_groups 1 1 1 \ / / (owner) _______(edit_permission)________/ / \ / / N N / aiki_widget / 1 (view permission) | / (if_authorized) / | / N / restricted_content N---------------------+
On Mon, 02 Jan 2012 09:43:58 -0000 Jakub Jankiewicz <jcu...@onet.pl> wrote: > Blueprint changed by Jakub Jankiewicz: > > Whiteboard changed: > good idea, added the field to the db for now, and started the > implementation > > Ok notice this already exists: > > https://blueprints.launchpad.net/aikiframework/+spec/widget-group-level > > ### > > any progress on this? Jon > > reassigned to jcubic, fosdevel is gone - Jon > > Reassigned to rg1024 who express interest - Jon here's his email: > > #### > > Feel free to take over this blueprint. I think that Aiki the > permissions system needs to be clearly documented. If I remember > correctly, a 'SystemGod' is basically top-level/admin Aiki permission > which has access to everything. This is somewhat of an issue, when > you have many system Gods that all have access to everything > including widgets. My idea was that in the context of the Aiki admin > interface, you could have owners and groups enforced on widgets. So, > other admins won't have write or read access in the Aiki admin > interface. > On a side note, I'm quite involved in working on the Aiki update > system as this is no small task. Please, forgive me if I don't reply > to future emails regarding the widget-privilege. > > By the way, thanks for your contributions to Aiki! Great work! :-) > > #### > > what is widget privileges? what is wrong with the current > permissions group? what is ownership? r + w? who understand that? I > don't. plus no one is working on this. this will never happen and > will not be useful > #### > > is like on Unix/Linux systems where every file have it owner and the > group. and you have 3 permissions for owner for the group and for > everyone else - read, write and execute. > > for instance: you will have widget - /admin - and that widget have > owner "jon" the group admins you you have for owner and the group rwx > - (read write) and r read for other users. If there is jcubic user > which belong to the group admins then he can edit that widget. And > jon always can edit the widget now matter if his a admin or not > because he is the owner of that widget (he created it). So if user is > librarian belong to the group libriarians he can't edit this admin > widget. but he can see it content. > > if there is a widget remove-comment that belong to betty and betty > is a librarian then when she create that widget it have owner betty > and the group librarian. if it have permissions rxw for group then > every user that is a librarian can edit and execute that widget. Jon > can't edit that widget nor execute it unless hes is also a librarian > (belong to the list of librarians) > > ### > > Yes Jcubic this is important. Opening for discussion unless bassel > can show how this works now. > > We need better permission system in aiki that is not hacky. -- Jon > + > + ### > + > + I have idea there should be two more fields in aiki_widgets owner > ( id > + of the user) and edit_permission_group which tell which users can > edit a > + widget. SystemGOD (root) will not need to be put in that field he > will > + be able to edit all widgets (like in Unix) > + > + and there should be table aiki_users_usergroups which will will > hold id > + of users in specific usergroup > + > + so for instance user rg1024 and jcubic will be SystemGOD (root) so > they > + will be on the list of SystemGODs (root). this will be beter > because one > + user could be in few groups. > + > + > aiki_users 1-------N aiki_users_usergroups N-------1 aiki_users_groups > + > 1 1 1 > + > \ / / > + > (owner) __(edit_permission)___ / / > + > \ / / > + > N N / > + > aiki_widget / > + > 1 (view permission) > + > | / > + > (if_authorized) / > + > | / > + > N / > + > restricted_content N---------------------+ > + > + And widgets should have multiply number of authorized content > + > + Widget should have content for "coworkers" another for "friends" and > + different for "consultans". > + > + and if user is "developer" the write permission will be "developer" > and > + he will not be able to change it (like in unix group). > + > + and we don't need Unix like rxw - there will be view and edit (ve) > + > + If we have this, on OCAL, we can alow librarians to edit some > widgets > + and create new once. And new Admin Panel can have restrictions for > part > + of the GUI like: edit_config edit_forms see_event etc. so librarians > + will be able to use Admin Panel but not all functionality. > + > + And we also shouldn't use root we should use admin because there > can be > + few of them, and default aiki instaltion should have one "admin" > which > + will be able to edit everything and "developers" will be edit > widgets. > + > + instead of SystemGOD admin - instead of ModuleGOD we will have > + developer. And admin will be able to add users to the group. And > only > + admin will be able to use mysql console. > + > + Thoughts? > + > + ~~~~ jcubic > -- Jakub Jankiewicz twitter: @jcubic www: http://jcubic.pl _______________________________________________ Mailing list: https://launchpad.net/~aikiframework-devel Post to : aikiframework-devel@lists.launchpad.net Unsubscribe : https://launchpad.net/~aikiframework-devel More help : https://help.launchpad.net/ListHelp
