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

[Martin Dobias]

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