incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cory Johns <cjo...@slashdotmedia.com>
Subject mount_point character restrictions and repositories
Date Thu, 18 Apr 2013 22:58:44 GMT
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?

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message