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

[Alessandro Pasotti]

Sorry, I forgot to CC the list.

---------- Forwarded message ----------



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

> Hi Alessandro!
>
>
> On Fri, Nov 26, 2010 at 6:28 PM, Alessandro Pasotti <apasotti at gmail.com>
> wrote:
> > Hi,
> > I've just uploaded the first working version of the new Python plugins
> > Django app.
>
> I've just tried it - and it's great stuff, working very well!
>

Thank you Martin, please see my comments here below


>
> > Implementation is hopefully complete but it still needs testing,
> > authentication is also missing since it should be handled by an external
> > provider (ldap ?) but for testing as a logged in user you can log in
> through
> > the admin panel.
>
> 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)


>
> > A few open questions still remain:
> > 1 - metadata are read from the zip file on plugin creation and that is
> fine,
> > but what happens when a new version of an existing plugin is uploaded and
> > there is a conflict in metadata plugin's name ? Should the plugin name
> name
> > be updated with the new plugin name or just fail? I guess that updating
> > description is just fine but changing plugin's name it isn't, so I put
> some
> > validation in place to avoid name mismatch or (worse) having different
> names
> > in the DB and in the zip packages.
>
> 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.



>
> > 2 - according to specs, the users are initially untrusted and they cannot
> > publish their plugins. When a staff member grants the "trust" to the
> user,
> > he can publish all his plugins. Plugins have a creator and 0 or more
> > "owners" who can manage the plugin exactly as if they were the original
> > author. Common sense says that if a user i not "trusted" and he uploads a
> > new versions, the whole plugin should be unpublished (remember the
> published
> > flag is in the Version model)
>
> 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.


>
> > 3 - "last" version in the two "branches" stable/experimental i somewhat
> > tricky (and IMHO the name is misleading, since if "last" has to do with
> > time, the upload time should suffice to determine which version is the
> last
> > one). I did not put too much magic in the code and this part can be
> improved
> > for sure.
> > So, I'm not sure that the workflow I have implemented is what you had in
> > your mind.
>
> I agree that "last" version is somewhat misleading. So let's call it
> rather "current" version (stable/experimental). My idea was that it
> would be an attribute of each plugin which version is the current one
> (and not to have a "current" flag for each plugin version). Setting
> the current version should be thus possible e.g. in "edit plugin" form
> using a combo box listing available versions.
>
>
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 ?

Perhaps a last thing we missed is some kind of moderation/email notification
on new plugin submissions.


Cheers

-- 
Alessandro Pasotti
w3:   www.itopen.it
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/qgis-developer/attachments/20101129/3469ca14/attachment-0001.html