View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0017826 | mantisbt | administration | public | 2014-11-01 01:34 | 2018-02-07 03:04 |
Reporter | vboctor | Assigned To | vboctor | ||
Priority | normal | Severity | minor | Reproducibility | have not tried |
Status | assigned | Resolution | open | ||
Product Version | 1.2.17 | ||||
Summary | 0017826: Support disabling per project upload path | ||||
Description | Often there is a single attachments folder for all folders. In such case, it would be useful to disable the upload path field showing up for each project. This allows the administrator to set one path to be used for all projects. Add $g_allow_per_project_upload_path. | ||||
Tags | mantishub | ||||
Pull request: |
|
Do we really need this ? Considering that if the upload path is left blank it defaults to the global upload path, it seems somewhat unnecessary to add a new config to just hide it in a not-so-frequently used management page. |
|
This is useful in a couple of scenario:
|
|
We already have code in there to hide the absolute path to non-admins. Maybe it would make sense to completely hide the field instead of just the sensitive content ?
I personally don't mind that much myself, but I can't help smiling as I imagine grangeway's reaction to a request for patching an open-source system solely to address the needs of a commercial endeavor ;) Anyway, kind of hard for me to comment as I don't know how MantisHub works internally. Taking things one step further (just thinking out loud here): what about getting rid of the project-specific upload folder setting completely ? I never really understood the need to manually set that up anyway... We could consider something like:
|
|
It could be that we should extend this option to hide the field, and enable even hiding from admin. Will check.
Making our product host-able is a good thing for the open source project. Think of WordPress. If it wasn't easy to host, it wouldn't be as successful for sure. MantisHub doesn't need such features to be ported back to MantisBT since it overlays its own set of hosting-specific features. It is more work to port these changes than just to keep them MantisHub specific. So we should think about this as goodness to MantisBT.
You should comment from the MantisBT perspective.
I'm totally for removing the per project upload path. In fact that is how I run any instance that I personally manage. I never hit an issue with number of files in folder given real usage that I have seen. |
|
In that case, this sounds like the better way forward. I've not seen this with Mantis, but I've had experiences of similar functionality with other software (Windows-hosted) where directories with very large number of files started performing very poorly (talking 40K+ files in my case) [1] [1] http://support.microsoft.com/kb/130694/en-us |
|
I know about the large directories having a big performance issue. What I've noticed is that the number of attachments that MantisBT usually has doesn't often hit these limits. There is two parts of the work here:
Number 2 is likely more work that 1. Anyway, we will dump my thoughts here as I spend more time on it. However, it is not a priority really. |
|
As a side note: IIRC there is a bug when cloning issues with attachments from one project to another one that has setup the same upload folder. That's why I had to setup an own directory for project "Track DBAL replacement" |
|
The instance I ran at my previous employer had more than 25K attachments, which is enough to start noticing performance degradations when accessing the file system (at that point we decided to move attachments to DB). Anyway, my point is that if we revisit this, we should make sure the solution we develop works well for all cases and not just the ones we know about. In other words, if we take away from admins the possibility to specify per-project dirs we should at least make sure we don't introduce performance issues. Organizing attachments in a tree vs a single dir, and relocating them into such a structure is not adding much more overhead, so it's probably worth the effort. We could also consider a simple strategy where we use the first few chars of the filename's MD5 hash as directories, e.g. c4ca4238a0b923820dcc509a6f75849b ==> /c/4/ca4238a0b923820dcc509a6f75849b (but need to be careful with existing old attachments not using md5 names). |
|
Hello everyone, just want to share one thing on this. |
|
@dregad The suggest change for this issue is to enable the administrator to turn a config ON to hide the upload project path so that managers don't see it and can't update it. This will be OFF by default, but it is a global config option that administrator can set via config_inc.php. If ON, the attachments will be saved to the default upload path. Also the move attachments to disk in such case will save the attachments extracted from the db to the default upload path. @noizeg From memory, if a file is not found in the path saved in the db, we look for it in the default upload file path. We should also check for the project upload path (if set). This should fix the issue that you are raising where the project path is moved. In this case, we will not need to update the db file entries with the new paths. In general, I don't like the fact that we save the full path to the file. I would rather we just save the file name and then at retrieval time construct the full path based on project upload path (if found) or based on default upload path (if found). However, that should be a separate issue. |
|