incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <>
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/ 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/ so there are no dynamic
subdomains, which would make mail server configuration easier for anyone
deploying Allura.

Current email routing code is at
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.


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.)
>  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 : : personal : programming

View raw message