Sorry, I forgot to CC the list.<br><br><div class="gmail_quote">---------- Forwarded message ----------<br><br><br><br><div class="gmail_quote"><div class="im">2010/11/28 Martin Dobias <span dir="ltr"><<a href="http://wonder.sk" target="_blank">wonder.sk</a>@<a href="http://gmail.com" target="_blank">gmail.com</a>></span><br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Alessandro!<div class="im"><br>
<div><br>
On Fri, Nov 26, 2010 at 6:28 PM, Alessandro Pasotti <<a href="mailto:apasotti@gmail.com" target="_blank">apasotti@gmail.com</a>> wrote:<br>
> Hi,<br>
> I've just uploaded the first working version of the new Python plugins<br>
> Django app.<br>
<br>
</div>I've just tried it - and it's great stuff, working very well!<br></div></blockquote><div><br></div><div>Thank you Martin, please see my comments here below</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
<div><br>
> Implementation is hopefully complete but it still needs testing,<br>
> authentication is also missing since it should be handled by an external<br>
> provider (ldap ?) but for testing as a logged in user you can log in through<br>
> the admin panel.<br>
<br>
</div>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></div>
harder as it's not possible to log in as ordinary user (only staff i's<div class="im"><br>
allowed to login to admin interface).<br></div></blockquote><div><br></div><div>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) </div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> A few open questions still remain:<br>
> 1 - metadata are read from the zip file on plugin creation and that is fine,<br>
> but what happens when a new version of an existing plugin is uploaded and<br>
> there is a conflict in metadata plugin's name ? Should the plugin name name<br>
> be updated with the new plugin name or just fail? I guess that updating<br>
> description is just fine but changing plugin's name it isn't, so I put some<br>
> validation in place to avoid name mismatch or (worse) having different names<br>
> in the DB and in the zip packages.<br>
<br>
</div>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></blockquote><div><br></div><div><br></div></div><div>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.</div>
<div class="im">
<div> </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> 2 - according to specs, the users are initially untrusted and they cannot<br>
> publish their plugins. When a staff member grants the "trust" to the user,<br>
> he can publish all his plugins. Plugins have a creator and 0 or more<br>
> "owners" who can manage the plugin exactly as if they were the original<br>
> author. Common sense says that if a user i not "trusted" and he uploads a<br>
> new versions, the whole plugin should be unpublished (remember the published<br>
> flag is in the Version model)<br>
<br>
</div>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></blockquote><div><br></div></div><div>Ok, what happens if a trusted owner become untrusted and uploads a new version? It's a potential security hole. </div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br>
> 3 - "last" version in the two "branches" stable/experimental i somewhat<br>
> tricky (and IMHO the name is misleading, since if "last" has to do with<br>
> time, the upload time should suffice to determine which version is the last<br>
> one). I did not put too much magic in the code and this part can be improved<br>
> for sure.<br>
> So, I'm not sure that the workflow I have implemented is what you had in<br>
> your mind.<br>
<br>
</div>I agree that "last" version is somewhat misleading. So let's call it<br>
rather "current" version (stable/experimental). My idea was that it<br>
would be an attribute of each plugin which version is the current one<br>
(and not to have a "current" flag for each plugin version). Setting<br>
the current version should be thus possible e.g. in "edit plugin" form<br>
using a combo box listing available versions.<br>
<div><br></div></blockquote><div><br></div></div><div>Ok, I will refactor changing "last" to "current" and make the select. </div><div>Do you think the last uploaded version should be automatically marked as current ? </div>
<div><br></div><div>Perhaps a last thing we missed is some kind of moderation/email notification on new plugin submissions.</div><div><br></div><div><br></div><div>Cheers</div></div><div><div></div><div class="h5"><br>-- <br>
Alessandro Pasotti<br>w3: <a href="http://www.itopen.it" target="_blank">www.itopen.it</a><br>
</div></div></div><br>