View Issue Details

IDProjectCategoryView StatusLast Update
0027912mantisbtcustom fieldspublic2021-02-10 16:29
ReporterDejmiJohn Assigned Todregad  
PrioritylowSeverityfeatureReproducibilityalways
Status closedResolutionwon't fix 
Product Version2.24.2 
Summary0027912: Respect $p_log_insert while updating custom field
Description

In the function custom_field_set_value( $p_field_id, $p_bug_id, $p_value, $p_log_insert = true ), there is an if-else statement which either updates or creates new entry in the database for given custom field. In the else branch, there is a condition like:

"if( $p_log_insert ) {history_log_event_direct( $p_bug_id, $t_name, '', $t_value );"

which respects if the history log should be created or not.

Can you add the same condition to the if-branch of the if-else so when user-created plugin manages custom fields on its own it is possible to edit them without logging history?

Instead of:

history_log_event_direct( $p_bug_id, $t_name, custom_field_database_to_value( $t_row[$t_value_field], $t_type ), $t_value );

there should be:

if( $p_log_insert ) {history_log_event_direct( $p_bug_id, $t_name, custom_field_database_to_value( $t_row[$t_value_field], $t_type ), $t_value ); }

TagsNo tags attached.

Relationships

related to 0026933 new Plugins are not able to validate custom_fields 

Activities

dregad

dregad

2021-01-25 11:22

developer   ~0065029

The only case where we don't log changes to custom fields, is when creating a new issue. The $p_log_insert flag was added for this very specific purpose, and only that.

Allowing plugins to update data (be it custom fields or anything else) without logging the change, goes against the principle of an audit trail (which is what the History is).

I am therefore opposed to implementing this.

DejmiJohn

DejmiJohn

2021-01-25 16:01

reporter   ~0065032

Hi, this sounds reasonable. This was a cheap workaround for a problem how to intercept custom items being reported before saved to the database by plugin. The events which gets signaled when user submits issue get only BugData class, which does not contain custom items for modification. Of course you can additionally load them from db, but we use custom items to pre-fill textarea with specific table (definiton of such table tends to be around 1000 chars long) and we do not want to save this table definition over and over again, so it would be nice if you can add such event. Something like: "event_signal( 'EVENT_BUG_CUSTOM_ITEMS_REPORTED', $t_issue['custom_fields'] ); Can this be discussed? If so, should I create new feature request?

atrol

atrol

2021-01-25 16:05

developer   ~0065033

Can this be discussed? If so, should I create new feature request?

Do you think your request is covered by 0026933?

DejmiJohn

DejmiJohn

2021-01-26 01:07

reporter   ~0065036

Yes, 0026933 should be fine!