allura-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rui Ferreira <rferre...@av.it.pt>
Subject Re: Allura private projects for non-admins
Date Thu, 02 May 2013 08:53:41 GMT
Hi,

I'd be willing to send some patches your way.

Perhaps changing the value of neighborhood.features['private_projects'] to
hold the user group that can create private projects (Admin, Developer,
Member, Authenticated) would cover all those cases?

This would break compatibility with the current
set_neighborhood_property command, would this be a problem? I could add a new property instead.

On Tue, Apr 30, 2013 at 05:58:38PM -0400, Dave Brondsema wrote:
> 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