View Issue Details

IDProjectCategoryView StatusLast Update
0026140mantisbtcustom fieldspublic2019-12-17 09:07
Reportercproensa Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Product Version2.23.0 
Summary0026140: Custom fields are displayed on issue report even if they have disabled "Display When Reporting Issues"
Description

The custom fields are presented in report page when they are configured with "Display When Reporting Issues" OR "Required On Report".
Having the custom field not "displayed" and still "required" may seem like a incoherent combination but:

  • If we want to prevent users to make mistakes with these options, that should be managed in the custom field configuration page.
  • If the options are set in that way, we should honour that behaviour, because other tools may be in place to provide a valid input: plugin, javascript, etc.

In my case, i use a plugin with "report_bug_form" event to display a customized input for a required custom field, so i don't want to display the standard input. At the moment, i need a javascript routine that deletes the standard input from the form. This is a very unelegant, solution.

TagsNo tags attached.

Relationships

related to 0026149 closeddregad Possibility to hide custom fields for selected users 
related to 0026151 new Custom fields required but not displayed should be filled with the default value 

Activities

dregad

dregad

2019-09-14 19:23

developer   ~0062803

even if they have disabled "Display When Resolving Issues"

Do you mean Display When Reporting Issues ?

not "displayed" and still "required" may seem like a incoherent combination

Which as I recall is the reason why display was handled with OR

that should be managed in the custom field configuration page.

What do you propose ?

cproensa

cproensa

2019-09-14 20:21

developer   ~0062804

Do you mean Display When Reporting Issues ?

yes, reporting. But probably it's also applicable to the other similar options.

Which as I recall is the reason why display was handled with OR
What do you propose ?

In a similar scenario, when configuring the workflow, we display warnings for inconsistent transitions (unreachable status, etc)
The idea is that if the combination of options is not consistent for a general case, the correction must be made ( or proposed, or guessed) when saving those options.

cproensa

cproensa

2019-09-14 20:52

developer   ~0062805

Another use case:
Having the custom field not displayed on report, but still required, and having a configured default value.
I would expect that the custom field is created with the default value.

keessonnema

keessonnema

2019-09-17 07:22

reporter   ~0062843

@cproensa About your last case: I was stumbling across this exact same situation and we were looking for a solution, then @dregad linked me to this issue.
Have you guys thought about how to do this? I guess this would be a helpful 'feature'.

cproensa

cproensa

2019-09-17 07:54

developer   ~0062844

Have you guys thought about how to do this? I guess this would be a helpful 'feature'

I think that behavior makes sense, but before modifying it, we must agree for the change.

cproensa

cproensa

2019-09-17 08:05

developer   ~0062846

@keessonnema
I filled a new issue to track that feature separately: 0026140

keessonnema

keessonnema

2019-09-17 08:10

reporter   ~0062847

Thanks. I will monitor the issue.

keessonnema

keessonnema

2019-12-17 09:07

reporter   ~0063289

Any updates on this?