You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@allura.apache.org by Rui Ferreira <rf...@av.it.pt> on 2013/05/02 10:53:41 UTC
Re: Allura private projects for non-admins
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
> <><
Re: Allura private projects for non-admins
Posted by Dave Brondsema <da...@brondsema.net>.
On 5/2/13 4:53 AM, Rui Ferreira wrote:
> 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?
That sounds good to me
>
> This would break compatibility with the current
> set_neighborhood_property command, would this be a problem? I could add a new property instead.
I think the current property is ok. The code could check and see if the value
is True and then treat it like Admin, that'd be backwards compatible. Or folks
could update their data when upgrading. In scripts/migrations/ there are some
examples of how we've done that in the past.
>
> 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
>> <><
>
--
Dave Brondsema : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
<><