allura-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <d...@brondsema.net>
Subject Re: Allura private projects for non-admins
Date Tue, 30 Apr 2013 21:58:38 GMT
Since Allura was developed at SourceForge which hosts open source projects, the
functionality was designed to support that open (not private) projects initially.

Note that these are just initial settings and a project admin can remove
anonymous 'read' rights later.

Your changes seem fine for a local modification.  If you were interested in
contributing them back to Allura, that'd be great, but I think it'd be best to
have additional configuration so that each neighborhood could have different
settings for whether they allowed private projects for nobody, neighborhood
admins, or everyone.  This could be done with an expansion of the
neighborhood.features['private_projects'] values.

-Dave


On 4/29/13 5:25 AM, Rui Ferreira wrote:
> Hi,
> 
> I'm looking into allowing users to create private projects in allura,
> but it seems that Allura requires a user to be admin on a neighborhood
> in order to create private projects.
> I was wondering if there is any strong reason for this restriction?
> 
> This seems to be enforced at the controller and template, and removing
> both checks allowed my users to create private projects i.e. 
> 
> diff --git a/Allura/allura/controllers/project.py b/Allura/allura/controllers/project.py
> index 5aa9e02..55d8ff6 100644
> --- a/Allura/allura/controllers/project.py
> +++ b/Allura/allura/controllers/project.py
> @@ -177,8 +177,8 @@ def check_names(self, project_name='', unix_name=''):
>      def register(self, project_unixname=None, project_description=None, project_name=None,
neighborhood=None,
>                   private_project=None, tools=None, **kw):
>          require_access(self.neighborhood, 'register')
> -        if private_project:
> -            require_access(self.neighborhood, 'admin')
> +#        if private_project:
> +#            require_access(self.neighborhood, 'admin')
>          neighborhood = M.Neighborhood.query.get(name=neighborhood)
>  
>          project_description = h.really_unicode(project_description or '').encode('utf-8')
> diff --git a/Allura/allura/templates/widgets/neighborhood_add_project.html b/Allura/allura/templates/widgets/neighborhood_add_project.html
> index 78ab608..0b36cb8 100644
> --- a/Allura/allura/templates/widgets/neighborhood_add_project.html
> +++ b/Allura/allura/templates/widgets/neighborhood_add_project.html
> @@ -41,7 +41,7 @@
>          </div>
>      {% endfor %}
>      {% endif %}
> -    {% if h.has_access(neighborhood, 'admin') and not neighborhood.project_template
and neighborhood.features['private_projects'] %}
> +{#    {% if h.has_access(neighborhood, 'admin') and not neighborhood.project_template
and neighborhood.features['private_projects'] %} #}
>      <div style="margin-top:20px">
>          <div class="grid-16" style="padding-top:4px; padding-left:4px">
>            {{widget.display_field(widget.fields.private_project)}}
> @@ -52,7 +52,7 @@
>          </div>
>          <div style="clear:both"></div>
>      </div>
> -    {% endif %}
> +{#    {% endif %} #}
>      <div class="button-row">
>          <input type="submit" id="start" value="Create">
>      </div>
> 
> Support for private projects is already enabled/disabled on a per
> beighborhood basis, is there really a need for this check?
> 
> 



-- 
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Mime
View raw message