incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <d...@brondsema.net>
Subject Re: mount_point character restrictions and repositories
Date Fri, 19 Apr 2013 14:23:32 GMT
. and _ are the most common characters but there are others like = or , that
would be valid in a folder name for a repo, but not as a subdomain.

Right now we don't have any functionality to send an email to a repo, so nothing
would break yet.  But it's likely that we'd want make replying to a merge
request email work some day.  I think we probably could determine a different
routing mechanism at that point.  E.g. something like
my_repo/merge123@allura.p.sf.net would be plausible (moving the mount point
before the @ and using a separator that would never be a valid mount point
char).  Or even allura/my_repo/merge123@p.sf.net so there are no dynamic
subdomains, which would make mail server configuration easier for anyone
deploying Allura.

Current email routing code is at
https://sourceforge.net/p/allura/git/ci/master/tree/Allura/allura/tasks/mail_tasks.py
and
https://sourceforge.net/p/allura/git/ci/master/tree/Allura/allura/lib/mail_util.py#l77
for the interested.

Overall I'd prefer keeping mount points and their email addresses simple (as
opposed to complex and powerful) and also human-friendly.

-Dave

On 4/18/13 6:58 PM, Cory Johns wrote:
> Allura currently restricts the use of . and _ (period and underscore) in
> the mount_point when installing a tool / app.  This was originally done to
> enable to routing emails to to the app via the form (e.g.)
> new@tickets.allura.p.sourceforge.net.  However, this has become a sticking
> point for some users, specifically with regards to repository names (and in
> particular with repositories migrated from other systems, such as
> SourceForge's classic system which already allowed those characters).
>  Dave, Tim and I started discussing possible options for opening up these
> characters, and we wanted to open up the discussion here.
> 
> Initially, we were thinking that we could just have a flag that an app
> could set that removed the restriction for these characters for the
> mount_point of that app when installed on a project, with the understanding
> that this would break email routing for that app.  Tim also had the idea of
> adding an additional "sanitized" version of the mount_point that could
> still be used for routing in place of the normal mount_point.  However,
> there would be the potential for conflicts, albeit manageable, if the
> sanitized version of one tool's mount_point matched the non-sanitized
> version of another tool's mount_point.  I floated the idea of going all the
> way and using a guaranteed unique identifier, such as the app_config's _id,
> but then the email address' domain would not be human-friendly.
> 
> Is it worth coming up with a more complicated system to try to both
> preserve email routing and allow the characters in the mount_point, or
> should we just go with a flag and let the tools break their routing?  Are
> there any other ideas that strike a better balance?
> 



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

Mime
View raw message