0024615: admin/check : writability check for absolute_path_default_upload_folder with FAIL may be too restrictive

ID	Project	Category	View Status	Date Submitted	Last Update
0024615	mantisbt	attachments	public	2018-07-18 02:17	2024-11-10 06:15

Reporter	tk	Assigned To	dregad
Priority	normal	Severity	tweak	Reproducibility	always
Status	closed	Resolution	won't fix
Product Version	2.15.0

Summary	0024615: admin/check : writability check for absolute_path_default_upload_folder with FAIL may be too restrictive
Description	In my environment I have a main upload folder and various project (-group) specific subdirectories as proper upload folders. This is required in order to allow for simple accounting of the data. Therefore in my case absolute_path_default_upload_folder must not be writable, since attachments have to be reliably inserted into the proper (writable) subdirectories. In that sense I only use absolute_path_default_upload_folder as a suitable start assignment for the project upload folder tree when I set up new projects, When I execute admin/check the checker will prematurely stop due to failure with absolute_path_default_upload_folder configuration option points to a writable directory The path '<MAIN_UPLOAD_PATH>' must be writable. Currently I chmod the main upload folder writable before running the check, but maybe there are better options. I.e. the error level for absolute_path_default_upload_folder may be released to WARN, or the check routine could be implemented such that it does not stop at FAIL (which appears to me the better option in the course of writing this text)
Tags	No tags attached.

dregad 2024-10-27 12:21 developer ~0069404	We expect $g_absolute_path_default_upload_folder because it is the default upload folder, and as such it needs to be writable. Your specific scenario where it is not actually used is quite specific, and it may happen that someone adds a new project and forgets to change the project's upload folder. In my opinion it would not be worth the effort, to check that every project overrides the default, so I'm closing this as won't fix. That being said, your second suggestion, i.e. not causing subsequent checks to fail after the first error, is covered by 0033012 which I'm targeting for release 2.28.0.