How about a real infinite limit as a default, instead of arbitrary 30? Then we
don't break anywhere that is using more than 30 tools (it does happen...)
Using `float("inf")` should work I think.
The logic in `installable_tools_for` could use some fixing. The
`cls._installable_tools` cache is global to the class, so can't have the
per-project "limited_tools" filter applied to that data. Also the new code
could be cleaner by using sets and/or comprehensions.
It seems that when a tool has reached its max, it's no longer displayed as a
choice, but there isn't server-side validation to enforce that. So you can
open up /admin/tools twice and install a tool that has a `max_instances = 1` in
each window and both will succeed. Perhaps this is a bug I encountered only
due to the issue I mention in the above paragraph?
A few places were changed to check `max_instances > 0` instead of `installable`
I think they should still check `installable` in case an app wants to override
that property and provide custom logic. `def validate_mount_point` and
`neighborhood_add_project.html` specifically.
---
** [tickets:#5502] Prevent adding certain tools multiple times**
**Status:** in-progress
**Labels:** 42cc
**Created:** Thu Dec 20, 2012 05:54 PM UTC by Björn Kautler
**Last Updated:** Thu Nov 28, 2013 02:48 PM UTC
**Owner:** nobody
If you add the VHOST tool multiple times and then add a VHOST in one of the
installed tools, it is also shown in the other tools, So as there is absolutely
no benefit of adding the VHOST tool multiple times as far as I see, it should
be prevented that it is added multiple times technically.
I think best would be if it is not in the list of addable tools if it is added
already.
---
Sent from sourceforge.net because allura-dev@incubator.apache.org is subscribed
to https://sourceforge.net/p/allura/tickets/
To unsubscribe from further messages, a project admin can change settings at
https://sourceforge.net/p/allura/admin/tickets/options. Or, if this is a
mailing list, you can unsubscribe from the mailing list.
