0034368: Accept timestamps (including historical/past dates) when posting notes via REST API - MantisBT - Signup temporarily disabled due to spam

ID	Project	Category	View Status	Date Submitted	Last Update

0034368	mantisbt	api rest	public	2024-03-25 16:00	2024-04-01 19:22

Reporter	acoder2020	Assigned To
Priority	normal	Severity	feature	Reproducibility	always
Status	acknowledged	Resolution	open
Product Version	2.26.0

Summary	0034368: Accept timestamps (including historical/past dates) when posting notes via REST API
Description	Presently the created_at value is ignored when posting a note via REST API: `'bug_id' => 188, 'text' => 'this comment was posted a while ago', 'view_state' => [ 'id' => 10 ], 'created_at' => '2020-01-01 12:23:45', 'reporter' => [ 'name' => 'acoder2020' ]` The resulting note is posted successfully, but with a timestamp of today (not 2020 as specified) I am importing 15 years of data into MantisBT and cannot have every note posted with today's date. It makes imported issues very difficult to read/follow.
Steps To Reproduce	Submit this JSON: `'bug_id' => 188, 'text' => 'this comment was posted a while ago', 'view_state' => [ 'id' => 10 ], 'created_at' => '2020-01-01 12:23:45', 'reporter' => [ 'name' => 'acoder2020' ]`
Tags	No tags attached.

acoder2020 2024-03-25 16:11 reporter ~0068709	This should also work if updating an existing note via REST API.

dregad 2024-03-26 04:17 developer ~0068712	@vboctor your opinion on this would be appreciated (see also 0034369).

acoder2020 2024-03-26 09:03 reporter ~0068716	If not obvious, leaving `created_by` blank would default to today's datetime. So this change would not affect the current basic method of adding a note.

acoder2020 2024-03-26 09:06 reporter ~0068718	Additionally, if `created_by` were invalid, it would preferably error out and not post (or if you don't check dates anywhere else just let it add as it was submitted)

vboctor 2024-03-30 02:07 manager ~0068754	I thought about the migration scenario before, but I never really implemented support for migrations via the REST API. Tweaks will have to be done in multiple places to make it work full as expected / desired. For example: Ability to set created_at and updated_at fields. Ability to do actions on behalf of other users (e.g. user X is calling the API, but reporting an issue, adding a note, adding a relationship as another user) etc. I'm OK with adding such support, but I think often we will have to protect it from general usage. For example, we now have a threshold that enables users to specify reporter name (vs. just be the signed in user). We would need the same for overriding fields likes created_at, updatd_at, user who added relationship, etc. There are two options to consider: Have a config option for overriding time stamps, and possibly others for specific functionality. Similar to how we have `webservice_specify_reporter_on_add_access_level_threshold` (name is really obsolete, we don't use this naming convention anymore). Have a config option for migration user which can point to a username that is the migration user and is allowed to do actions that are specific to migrations, but now allowed typically. The good thing about this approach is that it limits such functionality to a single user and it makes it expected that it is only needed at the API level and not UI. Open for other ideas, but I think the above suggestions reflect my initial thoughts.

dregad 2024-03-31 07:41 developer ~0068758	we will have to protect it from general usage Fully agreed. two options to consider Have a config option for migration user which can point to a username that is the migration user and is allowed to do actions that are specific to migrations. I like this second option better. The first one, if left enabled (intentionally or not), leaves the door open to introducing data integrity issues Until this is implemented, I believe the Bundled XmlImportExport plugin is the better approach.

acoder2020 2024-04-01 09:42 reporter ~0068762	We have to wait for this to appear in REST API. We've invested several weeks in building a PHP script to migrate data from TRAC to MantisBT using REST API, bosses will not let us start over with a different method (XmlImportExport plugin) for this remaining issue. Will continue monitoring this and 0034369

acoder2020 2024-04-01 09:45 reporter ~0068763	I like the idea of placing this behind a config option as a master switch for these added submission options.

dregad 2024-04-01 19:22 developer ~0068773	We have to wait for this to appear in REST API. Well, I'm sorry to say but don't hold your breath... As stated before, XML import can do this out of the box, so while nice to have, this feature is not a priority (at least for me). bosses will not let us start over with a different method (XmlImportExport plugin) for this remaining issue. If you're on a schedule for your migration and really must have this feature to move forward, then you are welcome to submit a pull request to implement the functionality, and we can review it. If you can't do that, maybe you can ask the bosses if they would be willing to pay for it.. I personally have no intention to develop this in the short term, as I have neither the time nor the motivation.