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