<div dir="ltr">Great Paolo!<div>We did not create that group by default but there have been some requests for that so please add it!</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-05 13:42 GMT+02:00 Francesco Bartoli <span dir="ltr"><<a href="mailto:xbartolone@gmail.com" target="_blank">xbartolone@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Paolo,<div><br><div><div><div class="h5"><div>Il giorno 05/giu/2015, alle ore 12:42, Paolo Corti <<a href="mailto:pcorti@gmail.com" target="_blank">pcorti@gmail.com</a>> ha scritto:</div><br><blockquote type="cite">Hi<br><br>I am working on a procedure that should be able to migrate any GeoNode<br>instance from 2.0 to 2.4 (starting from this work that was done by the<br>NEPA geonode people:<br><a href="https://github.com/DOE-NEPA/geonode_2.0_to_2.4_migration" target="_blank">https://github.com/DOE-NEPA/geonode_2.0_to_2.4_migration</a>). I am almost<br>ready (I will soon send a PR with the code so that this could be<br>beneficial for others that need to do this migration), except that I<br>need to figure out how to proceed with permissions migration.<br><br>In GeoNode 2.0 for generic roles we have the following situtations:<br><br>1) anonymous - Read Only: every user can view/download<br>2) authenticated - Read Only: every authenticated user can view/download<br>3) authenticated - Read/Write: every authenticated user can view/download/edit<br><br>for 1) we can set the following two permissions in guardian ("anyone"<br>is a user):<br><br>* anyone can view<br>* anyone can download<br><br>for 2) and 3) we would need to add respectively two (can view, can<br>download) or six (can view, can download, can edit, can edit metadata,<br>can edit styles, can manage) record/s for each different GeoNode user.<br>If the combination of user and resource base is large (as in my case),<br>this will translate in a very large number of records loaded in the<br>guardian table.<br><br>Is it acceptable in your opinion if for the migration purpose I create<br>a group named 'authenticated' by code and assign all of the users to<br>it, and then proceed with the permission migration assigning the<br>permission for a resource just to the group in case of 2/3? Do you<br>think there is a better approach?<br><br>I was considering if it would make sense to have this 'authenticated'<br>group created by default in geonode. This would mean to add a signal<br>to assign every freshly created user by default to that group.<br></blockquote><div><br></div></div></div>Makes sense IMHO and does fit into the “notMember” role for group authorization described in this issue <a href="https://github.com/GeoNode/geonode/issues/2164" target="_blank">#2164</a></div><span class=""><div><br><blockquote type="cite"><br>ideas?<br>cheers<br><br>-- <br>Paolo Corti<br>Geospatial software developer<br>web: <a href="http://www.paolocorti.net" target="_blank">http://www.paolocorti.net</a><br>twitter: @capooti<br>skype: capooti<br>_______________________________________________<br>geonode-devel mailing list<br><a href="mailto:geonode-devel@lists.osgeo.org" target="_blank">geonode-devel@lists.osgeo.org</a><br><a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/geonode-devel" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/geonode-devel</a><br></blockquote></div><br></span></div></div><br>_______________________________________________<br>
geonode-devel mailing list<br>
<a href="mailto:geonode-devel@lists.osgeo.org">geonode-devel@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/cgi-bin/mailman/listinfo/geonode-devel" target="_blank">http://lists.osgeo.org/cgi-bin/mailman/listinfo/geonode-devel</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Simone </div>
</div>