[Qgis-developer] Python Plugin Repository - plugins app first working version

[Alessandro Pasotti]

2010/11/29 Martin Dobias <wonder.sk at gmail.com>

> Hi Alessandro
>
> On Mon, Nov 29, 2010 at 2:53 PM, Alessandro Pasotti <apasotti at gmail.com>
> wrote:
> > 2010/11/28 Martin Dobias <wonder.sk at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20101130/2b5a99ea/attachment.html