View Issue Details

WikiJump to Notes
IDProjectCategoryView StatusDate SubmittedLast Update
0020674mantisbtapi soappublic2016-03-09 01:242016-06-01 16:08
Reportervboctor Assigned Tovboctor  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionwon't fix 
Product Version1.3.0-rc.1 
Summary0020674: Removal of 'administrator_email' is causing soap api failures
Description

Marking 'administrator_email' obsolete and not including it in the white list of config options is causing SOAP API calls to fail, hence, breaking some integrations that worked fine with MantisBT 1.2.x.

Possible solutions:

  1. Re-add the config option that used to have the same value as webmaster_email anyway.
  2. Have the API detect this and return 'webmaster_email' anyway.
Tagsmantishub

Activities

vboctor

vboctor

2016-04-28 11:27

manager   ~0053033

@rombert @dregad @atrol any thoughts on this? It brings an interesting scenario for some of the retired configuration options.
dregad

dregad

2016-04-28 17:55

developer   ~0053034

Option 1 is a no-go for me.
Regarding 2, I'm not sure it's right to have the API detect this case (if we do it, then what do we do about all the other obsoleted configs ?)

So, playing Devil's advocate maybe, but what about

  1. do nothing and let the integration adapt to use the new config
atrol

atrol

2016-04-29 03:25

developer   ~0053036

Option 1 is a no-go for me.
+1

  1. Have the API detect this and return 'webmaster_email' anyway.
    If you think about this, it should not be the SOAP API, but get_config as the change might break also plugins
    But we should not remove options and write code afterwards to provide the same options, so
  2. do nothing and let the integration adapt to use the new config
    +1

Scenario 1:
SOAP client fails, client is adapted to Mantis 1.3, issue fixed

Scenario 2:
SOAP client fails, client is not adapted to Mantis 1.3 (maybe no source available), maintain your Mantis fork that works with the client, issue fixed

Mantis is open source, so we don't have to provide backward compatibility options like closed source products. (e.g. there are a lot of flags you can set in Oracle to make the server compatible to older versions)
rombert

rombert

2016-05-20 16:36

reporter   ~0053201

Mantis is open source, so we don't have to provide backward compatibility options like closed source products. (e.g. there are a lot of flags you can set in Oracle to make the server compatible to older versions)

I don't necessarily agree. I've tried hard not to make breaking changes in the SOAP API.

That being said, I think this is something that the client app can check itself based on the version of MantisBT.
dregad

dregad

2016-05-21 04:23

developer   ~0053203

Based on provided feedback, I'm resolving this as won't fix.