Dave, So are you proposing that we change the definition of valid mount point to include _ and . but only for repos?
Tim On Friday, April 19, 2013 at 10:23 AM, Dave Brondsema wrote: > . 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/[email protected] (mailto:[email protected]) 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/[email protected] (mailto:[email protected]) 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.) > > [email protected] > > (mailto:[email protected]). 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 : [email protected] (mailto:[email protected]) > http://www.brondsema.net : personal > http://www.splike.com : programming > <>< > >
