2010/11/29 Martin Dobias <wonder...@gmail.com> > Hi Alessandro > > On Mon, Nov 29, 2010 at 2:53 PM, Alessandro Pasotti <apaso...@gmail.com> > wrote: > > 2010/11/28 Martin Dobias <wonder...@gmail.com> > >> > >> I think log in / log out can be added now (just without registration) > >> - if I understand it correctly, once we know how to deal with the ldap > >> server, we will just switch over to ldap authentication backend from > >> the default one. Not having log in/out facility makes the testing > >> harder as it's not possible to log in as ordinary user (only staff i's > >> allowed to login to admin interface). > > > > Right, you can still enter as staff then (while logged in) change the > flag > > via console or another browser, but adding django-registration is not > hard > > to do (I woudn't waste time on styling though) > > I meant to just enable log in and log out without having to use admin > application. The log in/out facility will be needed also when using > ldap authentication. > > But django-registration is IMHO not necessary right now since the > users can be added easily in admin area. > > >> Inside QGIS we make a difference between plugin name (user-readable) > >> and plugin package name (the directory of the plugin). We require the > >> package names to be unique. I think it will be good to add 'package > >> name' attribute to plugin model, strictly require it to remain the > >> same and update plugin's name from the metadata on updates. Does this > >> sound good to you? > > > > > > Ok, let's call them "package_name" and "name", what prevented me to do > so > > is that AFAIK in the __init__.py file there is just one field (name). So, > we > > should read the "package_name" from the main directory name and the > "name" > > from the __init__.py ? A validation rule should be added accordingly. > > Yes, that's exactly what I meant. > > > >> I think a reasonable requirement would be to allow adding only trusted > >> users as co-owners of a plugin. In case someone is willing to add an > >> untrusted user, he can solve that with admins (e.g. mail them to > >> request setting the other user as trusted) - this probably won't be a > >> common case. > > > > Ok, what happens if a trusted owner become untrusted and uploads a new > > version? It's a potential security hole. > > In addition to trusted/untrusted users, we should add one more state: > blocked user. These would be allowed transitions: > - untrusted -> trusted (marked by admin when the author uploads > something useful) > - untrusted -> blocked, trusted -> blocked (marked by admin when the > author uploads something malicious) > > Blocked users have permanently forbidden to log in and do anything. So > if someone trusted will get blocked by admin, he will not be able to > do any further changes (additionally admin will have to rollback some > of his changes). > > > > Ok, I will refactor changing "last" to "current" and make the select. > > Do you think the last uploaded version should be automatically marked as > > current ? > > Yes. Even better, in the upload form there could be a combo with > following options: 1. set as current stable (default), 2. set as > current experimental, 3. do not set anything. > > > Perhaps a last thing we missed is some kind of moderation/email > notification > > on new plugin submissions. > > Right, when an untrusted user uploads a plugin, the admins (or staff?) > should be notified that there's a plugin waiting for a review. > > Regards > Martin >
Hi Martin, all done, except the select in templates for plugin upload, but the same functionality is implemented with checkboxes and sensible defaults. I've also added some views and functions for a better user handling (block an trust/untrust), there shouldn't be any need to enter the admin panel for daily administration. All staff users can manage plugins and other non-staff users. Email notification on new plugins is sent to all staff users which have an email set, can be easily extendend to send notifications on new versions too. -- Alessandro Pasotti w3: www.itopen.it
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
