Discussion:
[mantisbt-dev] Fixed Problemes / Improving agileMantis / Help Needed
Schmitz, Jean
2014-07-03 15:02:05 UTC
Permalink
Hello Damien,

you are right, I send it to the mailing list.

Best regards
Jean Schmitz

giServer project:
http://gadivintegrationserver.sourceforge.net/
http://www.gadiv.de/de/opensource/giserver/giserver.html

Please join out mailing lists:
https://sourceforge.net/p/gadivintegrationserver/mailman

Von: ***@gmail.com [mailto:***@gmail.com] Im Auftrag von Damien Regad
Gesendet: Donnerstag, 3. Juli 2014 16:40
An: Alain D'EURVEILHER
Cc: Schmitz, Jean; Jenauer, Walter; Zschoerner, Janine; Damien Regad
Betreff: Re: Fixed Problemes / Improving agileMantis / Help Needed

Guys,

Unless you really want to keep this off-the-record, I would strongly suggest to move such discussions to the mantisbt-dev mailing list.
FYI, the variable are stored in the table: mantis_plugin_config_table with the id: agileMantis_my_config.
The table is mantis_config_table.

Best regards,
Damien

On 3 July 2014 15:36, Alain D'EURVEILHER <***@gmail.com<mailto:***@gmail.com>> wrote:
Hi everyone,
I think that all the points are listed, I cannot find more ones.
First let me remind you that I am not a member of the MantisBT team as your email suggested ;-), but a regular user, who happens to be also a plugin creator (GanttChart).
I'd like also to apologize for remaing silent during the last few weeks, as some urgent tasks recently appeared to be achieved in a very short time, which kept me very busy (and I still am by the way).
Now my comments:
In fact the guideline you refer to is nice, but does not explains how to create a plugin. I don't know if there is such a guide somewhere...
I think we could prioritize the tasks as the following, according to the complexity (easiest first):
- 1: usage of the database_api: db_query_bound(), etc... (very easy to do. A bit repeatitive and long, but easy).
- 2: No modification of the config_inc.php file. use the plugin_config APIs instead. Not too difficult also to refactor here, it is quite easy to understand. Basically when a plugin needs a configuration we create it with plugin_config_set( 'my_config', $t_value ). Then we required, retrieve the value with: plugin_config_get( 'my_config' ). FYI, the variable are stored in the table: mantis_plugin_config_table with the id: agileMantis_my_config.
- 3: No direct insert into Mantis table. This one is a bit more complicated. If possible, yes, use some custom fields. As they are custom field, there should be in the configuration pages of the plugin, a detailed help page describing to the user what kind of custom fields is required (type, values, etc...). Then in the config page, the user must select among the existing custom fields the one which needs to be used for a specific purpose. Also, if the plugin is based on the settings of some custom field, keep in mind that the custom fields are not available by default to all the mantis projects, but is assigned to one or another project by the Mantis manager. So there must be some checks/verifications/warning messages to add in the source code of the plugin to manage the case where the expected custom fields are not set for the selected project.
- 4: No direct insert in mantis table, and no "CREATE TABLES". Idem there some API to use: plugin_table() and schema() function. That way all the plugin tables are standardized. (for information, they will be named mantis_plugin_agileMantis_my_table. But we use the API to call them plugin_table( 'my_table' ).). This task is not toooo difficult, but it's a major change in the DB. If you need also informations to specific issues, or projects, then you'll need to create relational tables instead of creating new columns inside existing mantis tables.
A very good example for the usage of 3 and 4 above is the pluging 'Souce Control Integration' of John Reese: http://leetcode.net

If you have any remarks about my analysis let me know. Then we could think of assigning the tasks.
Best regards,

AlainD.


On Wed, Jul 2, 2014 at 4:58 PM, Schmitz, Jean <***@gadiv.de<mailto:***@gadiv.de>> wrote:
Hello Alain,

I am a co-worker of Jan. As Jan is occupied by another project for now, I took over this issue.

I made a list of things that need to be changed from what I learned so far.
Maybe you or one of the other MantisBT team members can have a look on it.
Then we can start do work on the necessary changes.


- Source code needs to follow the MantisBT coding guidelines at https://www.mantisbt.org/wiki/doku.php/mantisbt:coding_guidelines

- All SQL calls need to make use of the db_query_bound() method

- No direct creation of tables via CREATE TABLE, instead make use of the schema() method to manage plugin-specific tables.

- No direct inserts into Mantis base tables. Make use of Mantis API, e.g. for custom fields.

- Don’t mess with the MantisBT configuration file (no special entries for the plugin)

Is there anything I missed?

Thanks for your help.

Jean

Von: Alain D'EURVEILHER [mailto:***@gmail.com
]
Gesendet: Dienstag, 10. Juni 2014 12:00
An: Koch, Jan
Cc: Jenauer, Walter; Zschoerner, Janine
Betreff: Re: Fixed Problemes / Improving agileMantis / Help Needed

Dear Jan,
I will not be able to work on aglieMantis this week, and maybe neither next week. But I think I could start to analyse what need to change the week after.
I will let you know whenever I'm free.
Thank you.

On Fri, Jun 6, 2014 at 4:11 PM, Koch, Jan <***@gadiv.de<mailto:***@gadiv.de>> wrote:
Hey Alain,

as promised, we would like to tell you about our results.

Faulty tags: we tested our changes with different MantisBT-Versions and with short-tags deactivated. Unfortunately, we did not pay attention to the server setting for short-tags during the development, that is why these errors have not noticed yet.

The use of the custom_strings_inc.php has already been explained.

Language strings in strings_english.txt: There were actually a few more hits with lang_get (). These have been changed to plugin_lang_get ().

CREATE TABLE: will have to be changed.

The modified software including other minor corrections will be uploaded on sourceforge and github in a few minutes.

agileMantis was developed by the end of 2013 for a inhouse use only. Therefore, we paid no special attention at the standards of MantisBT.
Then we decided to release the software as Open Source.

There are already user stories in our Product Backlog which provide a refactoring to the standards of MantisBT.
We will put a stronger effort on this user stories and we will do it now.

We are thankful for your offer to help us.

Especially because I am recently working in an external project and the current summer holidays, fewer PHP experts are available in our team.

Do you have a suggestion with what you can start?

Jan Koch
Junior Software Engineer
________________________________
gadiv GmbH
Bövingen 148
53804 Much
Tel.:

+49 (0)2245 / 9160-32<tel:%2B49%20%280%292245%20%2F%209160-32>

Fax:

+49 (0)2245 / 9160-21<tel:%2B49%20%280%292245%20%2F%209160-21>

E-Mail:

***@gadiv.de<mailto:***@gadiv.de>

Web:

www.gadiv.de<http://www.gadiv.de/>


Vertreten durch die GeschÀftsfÌhrer:
Walter Jenauer, Axel Heuchmer, Werner Mauelshagen

Gesellschaftssitz: Much
Amtsgericht Siegburg HRB 2487
USt-ID DE123109137
________________________________

Von: Alain D'EURVEILHER [mailto:***@gmail.com<mailto:***@gmail.com>]
Gesendet: Freitag, 6. Juni 2014 10:54
An: Koch, Jan
Betreff: agileMantis refactoring

Hi Jan,
We really like your plugin and would like to use it on our porject.
If you'd like us to help you refactor it in order to meet the Mantis standards about plugins implementation, feel free to ask.
Best Regards
--
AlainD.
--
AlainD.
--
AlainD.
Schmitz, Jean
2014-07-04 08:23:18 UTC
Permalink
Hello Damien,

are the mentioned points complete from your point of view?

If so, we would like to start making the changes as soon as possible.

Best regards
Jean Schmitz

Projects on Source Forge:
agileMantis - http://www.agilemantis.org<http://www.agilemantis.org/>
giServer - http://www.giserver.org<http://www.giserver.org/>

Please join out mailing lists:
[gadivintegrationserver-announcement]<https://lists.sourceforge.net/lists/listinfo/gadivintegrationserver-announcement>
[gadivintegrationserver-development]<https://lists.sourceforge.net/lists/listinfo/gadivintegrationserver-development>
[agilemantis-announcement]<https://lists.sourceforge.net/lists/listinfo/agilemantis-announcement>
[agilemantis-development]<https://lists.sourceforge.net/lists/listinfo/agilemantis-development>

Von: Schmitz, Jean
Gesendet: Donnerstag, 3. Juli 2014 17:02
An: 'Damien Regad'; 'mantisbt-***@lists.sourceforge.net'
Cc:
Betreff: AW: Fixed Problemes / Improving agileMantis / Help Needed

Hello Damien,

you are right, I send it to the mailing list.

Best regards
Jean Schmitz

giServer project:
http://gadivintegrationserver.sourceforge.net/
http://www.gadiv.de/de/opensource/giserver/giserver.html

Please join out mailing lists:
https://sourceforge.net/p/gadivintegrationserver/mailman

Von: ***@gmail.com<mailto:***@gmail.com> [mailto:***@gmail.com] Im Auftrag von Damien Regad
Gesendet: Donnerstag, 3. Juli 2014 16:40
An: Alain D'EURVEILHER
Cc: Schmitz, Jean; Jenauer, Walter; Zschoerner, Janine; Damien Regad
Betreff: Re: Fixed Problemes / Improving agileMantis / Help Needed

Guys,

Unless you really want to keep this off-the-record, I would strongly suggest to move such discussions to the mantisbt-dev mailing list.
FYI, the variable are stored in the table: mantis_plugin_config_table with the id: agileMantis_my_config.
The table is mantis_config_table.

Best regards,
Damien

On 3 July 2014 15:36, Alain D'EURVEILHER <***@gmail.com<mailto:***@gmail.com>> wrote:
Hi everyone,
I think that all the points are listed, I cannot find more ones.
First let me remind you that I am not a member of the MantisBT team as your email suggested ;-), but a regular user, who happens to be also a plugin creator (GanttChart).
I'd like also to apologize for remaing silent during the last few weeks, as some urgent tasks recently appeared to be achieved in a very short time, which kept me very busy (and I still am by the way).
Now my comments:
In fact the guideline you refer to is nice, but does not explains how to create a plugin. I don't know if there is such a guide somewhere...
I think we could prioritize the tasks as the following, according to the complexity (easiest first):
- 1: usage of the database_api: db_query_bound(), etc... (very easy to do. A bit repeatitive and long, but easy).
- 2: No modification of the config_inc.php file. use the plugin_config APIs instead. Not too difficult also to refactor here, it is quite easy to understand. Basically when a plugin needs a configuration we create it with plugin_config_set( 'my_config', $t_value ). Then we required, retrieve the value with: plugin_config_get( 'my_config' ). FYI, the variable are stored in the table: mantis_plugin_config_table with the id: agileMantis_my_config.
- 3: No direct insert into Mantis table. This one is a bit more complicated. If possible, yes, use some custom fields. As they are custom field, there should be in the configuration pages of the plugin, a detailed help page describing to the user what kind of custom fields is required (type, values, etc...). Then in the config page, the user must select among the existing custom fields the one which needs to be used for a specific purpose. Also, if the plugin is based on the settings of some custom field, keep in mind that the custom fields are not available by default to all the mantis projects, but is assigned to one or another project by the Mantis manager. So there must be some checks/verifications/warning messages to add in the source code of the plugin to manage the case where the expected custom fields are not set for the selected project.
- 4: No direct insert in mantis table, and no "CREATE TABLES". Idem there some API to use: plugin_table() and schema() function. That way all the plugin tables are standardized. (for information, they will be named mantis_plugin_agileMantis_my_table. But we use the API to call them plugin_table( 'my_table' ).). This task is not toooo difficult, but it's a major change in the DB. If you need also informations to specific issues, or projects, then you'll need to create relational tables instead of creating new columns inside existing mantis tables.
A very good example for the usage of 3 and 4 above is the pluging 'Souce Control Integration' of John Reese: http://leetcode.net

If you have any remarks about my analysis let me know. Then we could think of assigning the tasks.
Best regards,

AlainD.


On Wed, Jul 2, 2014 at 4:58 PM, Schmitz, Jean <***@gadiv.de<mailto:***@gadiv.de>> wrote:
Hello Alain,

I am a co-worker of Jan. As Jan is occupied by another project for now, I took over this issue.

I made a list of things that need to be changed from what I learned so far.
Maybe you or one of the other MantisBT team members can have a look on it.
Then we can start do work on the necessary changes.


- Source code needs to follow the MantisBT coding guidelines at https://www.mantisbt.org/wiki/doku.php/mantisbt:coding_guidelines

- All SQL calls need to make use of the db_query_bound() method

- No direct creation of tables via CREATE TABLE, instead make use of the schema() method to manage plugin-specific tables.

- No direct inserts into Mantis base tables. Make use of Mantis API, e.g. for custom fields.

- Don’t mess with the MantisBT configuration file (no special entries for the plugin)

Is there anything I missed?

Thanks for your help.

Jean

Von: Alain D'EURVEILHER [mailto:***@gmail.com
]
Gesendet: Dienstag, 10. Juni 2014 12:00
An: Koch, Jan
Cc: Jenauer, Walter; Zschoerner, Janine
Betreff: Re: Fixed Problemes / Improving agileMantis / Help Needed

Dear Jan,
I will not be able to work on aglieMantis this week, and maybe neither next week. But I think I could start to analyse what need to change the week after.
I will let you know whenever I'm free.
Thank you.

On Fri, Jun 6, 2014 at 4:11 PM, Koch, Jan <***@gadiv.de<mailto:***@gadiv.de>> wrote:
Hey Alain,

as promised, we would like to tell you about our results.

Faulty tags: we tested our changes with different MantisBT-Versions and with short-tags deactivated. Unfortunately, we did not pay attention to the server setting for short-tags during the development, that is why these errors have not noticed yet.

The use of the custom_strings_inc.php has already been explained.

Language strings in strings_english.txt: There were actually a few more hits with lang_get (). These have been changed to plugin_lang_get ().

CREATE TABLE: will have to be changed.

The modified software including other minor corrections will be uploaded on sourceforge and github in a few minutes.

agileMantis was developed by the end of 2013 for a inhouse use only. Therefore, we paid no special attention at the standards of MantisBT.
Then we decided to release the software as Open Source.

There are already user stories in our Product Backlog which provide a refactoring to the standards of MantisBT.
We will put a stronger effort on this user stories and we will do it now.

We are thankful for your offer to help us.

Especially because I am recently working in an external project and the current summer holidays, fewer PHP experts are available in our team.

Do you have a suggestion with what you can start?

Jan Koch
Junior Software Engineer
________________________________
gadiv GmbH
Bövingen 148
53804 Much
Tel.:

+49 (0)2245 / 9160-32<tel:%2B49%20%280%292245%20%2F%209160-32>

Fax:

+49 (0)2245 / 9160-21<tel:%2B49%20%280%292245%20%2F%209160-21>

E-Mail:

***@gadiv.de<mailto:***@gadiv.de>

Web:

www.gadiv.de<http://www.gadiv.de/>


Vertreten durch die GeschÀftsfÌhrer:
Walter Jenauer, Axel Heuchmer, Werner Mauelshagen

Gesellschaftssitz: Much
Amtsgericht Siegburg HRB 2487
USt-ID DE123109137
________________________________

Von: Alain D'EURVEILHER [mailto:***@gmail.com<mailto:***@gmail.com>]
Gesendet: Freitag, 6. Juni 2014 10:54
An: Koch, Jan
Betreff: agileMantis refactoring

Hi Jan,
We really like your plugin and would like to use it on our porject.
If you'd like us to help you refactor it in order to meet the Mantis standards about plugins implementation, feel free to ask.
Best Regards
--
AlainD.
--
AlainD.
--
AlainD.
Schmitz, Jean
2014-07-07 09:02:55 UTC
Permalink
Hello Alain,

I have some question on topic #3 “custom fields”.
Indeed we heavily rely on the use of custom fields.
It’s right that we should have used API functions instead of direct inserts.

What we do, is that we add the custom fields during installation of the plugin.
Then, if someone decides to create a product backlog we assign the custom fields to the selected project.

So from my opinion, there shouldn’t be the need to manually select the custom fields on the config page.
So, do you thing that, if we just use the API functions instead of the direct inserts this will be sufficient?


Best regards
Jean Schmitz

Projects on Source Forge:
agileMantis - http://www.agilemantis.org<http://www.agilemantis.org/>
giServer - http://www.giserver.org<http://www.giserver.org/>

Please join out mailing lists:
[gadivintegrationserver-announcement]<https://lists.sourceforge.net/lists/listinfo/gadivintegrationserver-announcement>
[gadivintegrationserver-development]<https://lists.sourceforge.net/lists/listinfo/gadivintegrationserver-development>
[agilemantis-announcement]<https://lists.sourceforge.net/lists/listinfo/agilemantis-announcement>
[agilemantis-development]<https://lists.sourceforge.net/lists/listinfo/agilemantis-development>

Von: Alain D'EURVEILHER [mailto:***@gmail.com]
Gesendet: Donnerstag, 3. Juli 2014 15:36
An: Schmitz, Jean
Cc: Jenauer, Walter; Zschoerner, Janine; Damien Regad
Betreff: Re: Fixed Problemes / Improving agileMantis / Help Needed

Hi everyone,
I think that all the points are listed, I cannot find more ones.
First let me remind you that I am not a member of the MantisBT team as your email suggested ;-), but a regular user, who happens to be also a plugin creator (GanttChart).
I'd like also to apologize for remaing silent during the last few weeks, as some urgent tasks recently appeared to be achieved in a very short time, which kept me very busy (and I still am by the way).
Now my comments:
In fact the guideline you refer to is nice, but does not explains how to create a plugin. I don't know if there is such a guide somewhere...
I think we could prioritize the tasks as the following, according to the complexity (easiest first):
- 1: usage of the database_api: db_query_bound(), etc... (very easy to do. A bit repeatitive and long, but easy).
- 2: No modification of the config_inc.php file. use the plugin_config APIs instead. Not too difficult also to refactor here, it is quite easy to understand. Basically when a plugin needs a configuration we create it with plugin_config_set( 'my_config', $t_value ). Then we required, retrieve the value with: plugin_config_get( 'my_config' ). FYI, the variable are stored in the table: mantis_plugin_config_table with the id: agileMantis_my_config.
- 3: No direct insert into Mantis table. This one is a bit more complicated. If possible, yes, use some custom fields. As they are custom field, there should be in the configuration pages of the plugin, a detailed help page describing to the user what kind of custom fields is required (type, values, etc...). Then in the config page, the user must select among the existing custom fields the one which needs to be used for a specific purpose. Also, if the plugin is based on the settings of some custom field, keep in mind that the custom fields are not available by default to all the mantis projects, but is assigned to one or another project by the Mantis manager. So there must be some checks/verifications/warning messages to add in the source code of the plugin to manage the case where the expected custom fields are not set for the selected project.
- 4: No direct insert in mantis table, and no "CREATE TABLES". Idem there some API to use: plugin_table() and schema() function. That way all the plugin tables are standardized. (for information, they will be named mantis_plugin_agileMantis_my_table. But we use the API to call them plugin_table( 'my_table' ).). This task is not toooo difficult, but it's a major change in the DB. If you need also informations to specific issues, or projects, then you'll need to create relational tables instead of creating new columns inside existing mantis tables.
A very good example for the usage of 3 and 4 above is the pluging 'Souce Control Integration' of John Reese: http://leetcode.net

If you have any remarks about my analysis let me know. Then we could think of assigning the tasks.
Best regards,

AlainD.


On Wed, Jul 2, 2014 at 4:58 PM, Schmitz, Jean <***@gadiv.de<mailto:***@gadiv.de>> wrote:
Hello Alain,

I am a co-worker of Jan. As Jan is occupied by another project for now, I took over this issue.

I made a list of things that need to be changed from what I learned so far.
Maybe you or one of the other MantisBT team members can have a look on it.
Then we can start do work on the necessary changes.


- Source code needs to follow the MantisBT coding guidelines at https://www.mantisbt.org/wiki/doku.php/mantisbt:coding_guidelines

- All SQL calls need to make use of the db_query_bound() method

- No direct creation of tables via CREATE TABLE, instead make use of the schema() method to manage plugin-specific tables.

- No direct inserts into Mantis base tables. Make use of Mantis API, e.g. for custom fields.

- Don’t mess with the MantisBT configuration file (no special entries for the plugin)

Is there anything I missed?

Thanks for your help.

Jean

Von: Alain D'EURVEILHER [mailto:***@gmail.com
]
Gesendet: Dienstag, 10. Juni 2014 12:00
An: Koch, Jan
Cc: Jenauer, Walter; Zschoerner, Janine
Betreff: Re: Fixed Problemes / Improving agileMantis / Help Needed

Dear Jan,
I will not be able to work on aglieMantis this week, and maybe neither next week. But I think I could start to analyse what need to change the week after.
I will let you know whenever I'm free.
Thank you.

On Fri, Jun 6, 2014 at 4:11 PM, Koch, Jan <***@gadiv.de<mailto:***@gadiv.de>> wrote:
Hey Alain,

as promised, we would like to tell you about our results.

Faulty tags: we tested our changes with different MantisBT-Versions and with short-tags deactivated. Unfortunately, we did not pay attention to the server setting for short-tags during the development, that is why these errors have not noticed yet.

The use of the custom_strings_inc.php has already been explained.

Language strings in strings_english.txt: There were actually a few more hits with lang_get (). These have been changed to plugin_lang_get ().

CREATE TABLE: will have to be changed.

The modified software including other minor corrections will be uploaded on sourceforge and github in a few minutes.

agileMantis was developed by the end of 2013 for a inhouse use only. Therefore, we paid no special attention at the standards of MantisBT.
Then we decided to release the software as Open Source.

There are already user stories in our Product Backlog which provide a refactoring to the standards of MantisBT.
We will put a stronger effort on this user stories and we will do it now.

We are thankful for your offer to help us.

Especially because I am recently working in an external project and the current summer holidays, fewer PHP experts are available in our team.

Do you have a suggestion with what you can start?

Jan Koch
Junior Software Engineer
________________________________
gadiv GmbH
Bövingen 148
53804 Much
Tel.:

+49 (0)2245 / 9160-32<tel:%2B49%20%280%292245%20%2F%209160-32>

Fax:

+49 (0)2245 / 9160-21<tel:%2B49%20%280%292245%20%2F%209160-21>

E-Mail:

***@gadiv.de<mailto:***@gadiv.de>

Web:

www.gadiv.de<http://www.gadiv.de/>


Vertreten durch die GeschÀftsfÌhrer:
Walter Jenauer, Axel Heuchmer, Werner Mauelshagen

Gesellschaftssitz: Much
Amtsgericht Siegburg HRB 2487
USt-ID DE123109137
________________________________

Von: Alain D'EURVEILHER [mailto:***@gmail.com<mailto:***@gmail.com>]
Gesendet: Freitag, 6. Juni 2014 10:54
An: Koch, Jan
Betreff: agileMantis refactoring

Hi Jan,
We really like your plugin and would like to use it on our porject.
If you'd like us to help you refactor it in order to meet the Mantis standards about plugins implementation, feel free to ask.
Best Regards
--
AlainD.
--
AlainD.
--
AlainD.
Alain D'EURVEILHER
2014-07-07 22:26:18 UTC
Permalink
Hi, I didn't know that there were public APIs for that (I'm not an expert),
but yes, if that's possible, yes, why not. It would be easier indeed. But I
think that the MantisBT team would rather be able to advise on that point.

best regards,
AlainD.
Post by Schmitz, Jean
Hello Alain,
I have some question on topic #3 “custom fields”.
Indeed we heavily rely on the use of custom fields.
It’s right that we should have used API functions instead of direct inserts.
What we do, is that we add the custom fields during installation of the plugin.
Then, if someone decides to create a product backlog we assign the custom
fields to the selected project.
So from my opinion, there shouldn’t be the need to manually select the
custom fields on the config page.
So, do you thing that, if we just use the API functions instead of the
direct inserts this will be sufficient?
Best regards
Jean Schmitz
agileMantis - http://www.agilemantis.org
giServer - http://www.giserver.org
[gadivintegrationserver-announcement]
<https://lists.sourceforge.net/lists/listinfo/gadivintegrationserver-announcement>
[gadivintegrationserver-development]
<https://lists.sourceforge.net/lists/listinfo/gadivintegrationserver-development>
[agilemantis-announcement]
<https://lists.sourceforge.net/lists/listinfo/agilemantis-announcement>
[agilemantis-development]
<https://lists.sourceforge.net/lists/listinfo/agilemantis-development>
*Gesendet:* Donnerstag, 3. Juli 2014 15:36
*An:* Schmitz, Jean
*Cc:* Jenauer, Walter; Zschoerner, Janine; Damien Regad
*Betreff:* Re: Fixed Problemes / Improving agileMantis / Help Needed
Hi everyone,
I think that all the points are listed, I cannot find more ones.
First let me remind you that I am not a member of the MantisBT team as
your email suggested ;-), but a regular user, who happens to be also a
plugin creator (GanttChart).
I'd like also to apologize for remaing silent during the last few weeks,
as some urgent tasks recently appeared to be achieved in a very short time,
which kept me very busy (and I still am by the way).
In fact the guideline you refer to is nice, but does not explains how to
create a plugin. I don't know if there is such a guide somewhere...
I think we could prioritize the tasks as the following, according to the
- 1: usage of the database_api: db_query_bound(), etc... (very easy to do.
A bit repeatitive and long, but easy).
- 2: No modification of the config_inc.php file. use the plugin_config
APIs instead. Not too difficult also to refactor here, it is quite easy to
understand. Basically when a plugin needs a configuration we create it with
*plugin_config_set*( 'my_config', $t_value ). Then we required, retrieve
the value with: *plugin_config_get*( 'my_config' ). FYI, the variable are
agileMantis_my_config.
- 3: No direct insert into Mantis table. This one is a bit more
complicated. If possible, yes, use some custom fields. As they are custom
field, there should be in the configuration pages of the plugin, a detailed
help page describing to the user what kind of custom fields is required
(type, values, etc...). Then in the config page, the user must select among
the existing custom fields the one which needs to be used for a specific
purpose. Also, if the plugin is based on the settings of some custom field,
keep in mind that the custom fields are not available by default to all the
mantis projects, but is assigned to one or another project by the Mantis
manager. So there must be some checks/verifications/warning messages to add
in the source code of the plugin to manage the case where the expected
custom fields are not set for the selected project.
- 4: No direct insert in mantis table, and no "CREATE TABLES". Idem there
some API to use: *plugin_table*() and *schema*() function. That way all
the plugin tables are standardized. (for information, they will be named
mantis_plugin_agileMantis_my_table. But we use the API to call them
plugin_table( 'my_table' ).). This task is not toooo difficult, but it's a
major change in the DB. If you need also informations to specific issues,
or projects, then you'll need to create relational tables instead of
creating new columns inside existing mantis tables.
A very good example for the usage of 3 and 4 above is the pluging 'Souce
Control Integration' of John Reese: http://leetcode.net
If you have any remarks about my analysis let me know. Then we could think
of assigning the tasks.
Best regards,
AlainD.
Hello Alain,
I am a co-worker of Jan. As Jan is occupied by another project for now, I
took over this issue.
I made a list of things that need to be changed from what I learned so far.
Maybe you or one of the other MantisBT team members can have a look on it.
Then we can start do work on the necessary changes.
- Source code needs to follow the MantisBT coding guidelines at
https://www.mantisbt.org/wiki/doku.php/mantisbt:coding_guidelines
- All SQL calls need to make use of the db_query_bound() method
- No direct creation of tables via CREATE TABLE, instead make
use of the schema() method to manage plugin-specific tables.
- No direct inserts into Mantis base tables. Make use of Mantis
API, e.g. for custom fields.
- Don’t mess with the MantisBT configuration file (no special
entries for the plugin)
Is there anything I missed?
Thanks for your help.
Jean
]
*Gesendet:* Dienstag, 10. Juni 2014 12:00
*An:* Koch, Jan
*Cc:* Jenauer, Walter; Zschoerner, Janine
*Betreff:* Re: Fixed Problemes / Improving agileMantis / Help Needed
Dear Jan,
I will not be able to work on aglieMantis this week, and maybe neither
next week. But I think I could start to analyse what need to change the
week after.
I will let you know whenever I'm free.
Thank you.
Hey Alain,
as promised, we would like to tell you about our results.
Faulty tags: we tested our changes with different MantisBT-Versions and
with short-tags deactivated. Unfortunately, we did not pay attention to the
server setting for short-tags during the development, that is why these
errors have not noticed yet.
The use of the custom_strings_inc.php has already been explained.
Language strings in strings_english.txt: There were actually a few more
hits with lang_get (). These have been changed to plugin_lang_get ().
CREATE TABLE: will have to be changed.
The modified software including other minor corrections will be uploaded
on sourceforge and github in a few minutes.
agileMantis was developed by the end of 2013 for a inhouse use only.
Therefore, we paid no special attention at the standards of MantisBT.
Then we decided to release the software as Open Source.
There are already user stories in our Product Backlog which provide a
refactoring to the standards of MantisBT.
We will put a stronger effort on this user stories and we will do it now.
We are thankful for your offer to help us.
Especially because I am recently working in an external project and the
current summer holidays, fewer PHP experts are available in our team.
Do you have a suggestion with what you can start?
Jan Koch
Junior Software Engineer
------------------------------
gadiv GmbH
Bövingen 148
53804 Much
+49 (0)2245 / 9160-32
+49 (0)2245 / 9160-21
www.gadiv.de
Walter Jenauer, Axel Heuchmer, Werner Mauelshagen
Gesellschaftssitz: Much
Amtsgericht Siegburg HRB 2487
USt-ID DE123109137
------------------------------
*Gesendet:* Freitag, 6. Juni 2014 10:54
*An:* Koch, Jan
*Betreff:* agileMantis refactoring
Hi Jan,
We really like your plugin and would like to use it on our porject.
If you'd like us to help you refactor it in order to meet the Mantis
standards about plugins implementation, feel free to ask.
Best Regards
--
AlainD.
--
AlainD.
--
AlainD.
--
AlainD.
Schmitz, Jean
2014-07-08 08:44:17 UTC
Permalink
Hello MantisBT Team,

Besides the question below, I have one more question concerning the localization of custom fields.

To translate custom fields into other languages there needs to be a file called “custom_strings_inc.php” in the main directory of the mantis installation.

As our plugin makes use of custom fields and we want to localize them, is there a clean way to translate the fields just by using the plugin code?

Many thanks for your help!


Best regards
Jean Schmitz

Projects on Source Forge:
agileMantis - http://www.agilemantis.org<http://www.agilemantis.org/>
giServer - http://www.giserver.org<http://www.giserver.org/>

Please join out mailing lists:
[gadivintegrationserver-announcement]<https://lists.sourceforge.net/lists/listinfo/gadivintegrationserver-announcement>
[gadivintegrationserver-development]<https://lists.sourceforge.net/lists/listinfo/gadivintegrationserver-development>
[agilemantis-announcement]<https://lists.sourceforge.net/lists/listinfo/agilemantis-announcement>
[agilemantis-development]<https://lists.sourceforge.net/lists/listinfo/agilemantis-development>

Von: Alain D'EURVEILHER [mailto:***@gmail.com]
Gesendet: Dienstag, 8. Juli 2014 00:26
An: Schmitz, Jean
Cc: mantisbt-***@lists.sourceforge.net; Zschoerner, Janine; Jenauer, Walter
Betreff: Re: Fixed Problemes / Improving agileMantis / Help Needed

Hi, I didn't know that there were public APIs for that (I'm not an expert), but yes, if that's possible, yes, why not. It would be easier indeed. But I think that the MantisBT team would rather be able to advise on that point.

best regards,
AlainD.

On Mon, Jul 7, 2014 at 11:02 AM, Schmitz, Jean <***@gadiv.de<mailto:***@gadiv.de>> wrote:
Hello Alain,

I have some question on topic #3 “custom fields”.
Indeed we heavily rely on the use of custom fields.
It’s right that we should have used API functions instead of direct inserts.

What we do, is that we add the custom fields during installation of the plugin.
Then, if someone decides to create a product backlog we assign the custom fields to the selected project.

So from my opinion, there shouldn’t be the need to manually select the custom fields on the config page.
So, do you thing that, if we just use the API functions instead of the direct inserts this will be sufficient?


Best regards
Jean Schmitz

Projects on Source Forge:
agileMantis - http://www.agilemantis.org<http://www.agilemantis.org/>
giServer - http://www.giserver.org<http://www.giserver.org/>

Please join out mailing lists:
[gadivintegrationserver-announcement]<https://lists.sourceforge.net/lists/listinfo/gadivintegrationserver-announcement>
[gadivintegrationserver-development]<https://lists.sourceforge.net/lists/listinfo/gadivintegrationserver-development>
[agilemantis-announcement]<https://lists.sourceforge.net/lists/listinfo/agilemantis-announcement>
[agilemantis-development]<https://lists.sourceforge.net/lists/listinfo/agilemantis-development>

Von: Alain D'EURVEILHER [mailto:***@gmail.com<mailto:***@gmail.com>]
Gesendet: Donnerstag, 3. Juli 2014 15:36
An: Schmitz, Jean
Cc: Jenauer, Walter; Zschoerner, Janine; Damien Regad

Betreff: Re: Fixed Problemes / Improving agileMantis / Help Needed

Hi everyone,
I think that all the points are listed, I cannot find more ones.
First let me remind you that I am not a member of the MantisBT team as your email suggested ;-), but a regular user, who happens to be also a plugin creator (GanttChart).
I'd like also to apologize for remaing silent during the last few weeks, as some urgent tasks recently appeared to be achieved in a very short time, which kept me very busy (and I still am by the way).
Now my comments:
In fact the guideline you refer to is nice, but does not explains how to create a plugin. I don't know if there is such a guide somewhere...
I think we could prioritize the tasks as the following, according to the complexity (easiest first):
- 1: usage of the database_api: db_query_bound(), etc... (very easy to do. A bit repeatitive and long, but easy).
- 2: No modification of the config_inc.php file. use the plugin_config APIs instead. Not too difficult also to refactor here, it is quite easy to understand. Basically when a plugin needs a configuration we create it with plugin_config_set( 'my_config', $t_value ). Then we required, retrieve the value with: plugin_config_get( 'my_config' ). FYI, the variable are stored in the table: mantis_plugin_config_table with the id: agileMantis_my_config.
- 3: No direct insert into Mantis table. This one is a bit more complicated. If possible, yes, use some custom fields. As they are custom field, there should be in the configuration pages of the plugin, a detailed help page describing to the user what kind of custom fields is required (type, values, etc...). Then in the config page, the user must select among the existing custom fields the one which needs to be used for a specific purpose. Also, if the plugin is based on the settings of some custom field, keep in mind that the custom fields are not available by default to all the mantis projects, but is assigned to one or another project by the Mantis manager. So there must be some checks/verifications/warning messages to add in the source code of the plugin to manage the case where the expected custom fields are not set for the selected project.
- 4: No direct insert in mantis table, and no "CREATE TABLES". Idem there some API to use: plugin_table() and schema() function. That way all the plugin tables are standardized. (for information, they will be named mantis_plugin_agileMantis_my_table. But we use the API to call them plugin_table( 'my_table' ).). This task is not toooo difficult, but it's a major change in the DB. If you need also informations to specific issues, or projects, then you'll need to create relational tables instead of creating new columns inside existing mantis tables.
A very good example for the usage of 3 and 4 above is the pluging 'Souce Control Integration' of John Reese: http://leetcode.net

If you have any remarks about my analysis let me know. Then we could think of assigning the tasks.
Best regards,

AlainD.


On Wed, Jul 2, 2014 at 4:58 PM, Schmitz, Jean <***@gadiv.de<mailto:***@gadiv.de>> wrote:
Hello Alain,

I am a co-worker of Jan. As Jan is occupied by another project for now, I took over this issue.

I made a list of things that need to be changed from what I learned so far.
Maybe you or one of the other MantisBT team members can have a look on it.
Then we can start do work on the necessary changes.


- Source code needs to follow the MantisBT coding guidelines at https://www.mantisbt.org/wiki/doku.php/mantisbt:coding_guidelines

- All SQL calls need to make use of the db_query_bound() method

- No direct creation of tables via CREATE TABLE, instead make use of the schema() method to manage plugin-specific tables.

- No direct inserts into Mantis base tables. Make use of Mantis API, e.g. for custom fields.

- Don’t mess with the MantisBT configuration file (no special entries for the plugin)

Is there anything I missed?

Thanks for your help.

Jean

Von: Alain D'EURVEILHER [mailto:***@gmail.com
]
Gesendet: Dienstag, 10. Juni 2014 12:00
An: Koch, Jan
Cc: Jenauer, Walter; Zschoerner, Janine
Betreff: Re: Fixed Problemes / Improving agileMantis / Help Needed

Dear Jan,
I will not be able to work on aglieMantis this week, and maybe neither next week. But I think I could start to analyse what need to change the week after.
I will let you know whenever I'm free.
Thank you.

On Fri, Jun 6, 2014 at 4:11 PM, Koch, Jan <***@gadiv.de<mailto:***@gadiv.de>> wrote:
Hey Alain,

as promised, we would like to tell you about our results.

Faulty tags: we tested our changes with different MantisBT-Versions and with short-tags deactivated. Unfortunately, we did not pay attention to the server setting for short-tags during the development, that is why these errors have not noticed yet.

The use of the custom_strings_inc.php has already been explained.

Language strings in strings_english.txt: There were actually a few more hits with lang_get (). These have been changed to plugin_lang_get ().

CREATE TABLE: will have to be changed.

The modified software including other minor corrections will be uploaded on sourceforge and github in a few minutes.

agileMantis was developed by the end of 2013 for a inhouse use only. Therefore, we paid no special attention at the standards of MantisBT.
Then we decided to release the software as Open Source.

There are already user stories in our Product Backlog which provide a refactoring to the standards of MantisBT.
We will put a stronger effort on this user stories and we will do it now.

We are thankful for your offer to help us.

Especially because I am recently working in an external project and the current summer holidays, fewer PHP experts are available in our team.

Do you have a suggestion with what you can start?

Jan Koch
Junior Software Engineer
________________________________
gadiv GmbH
Bövingen 148
53804 Much
Tel.:

+49 (0)2245 / 9160-32<tel:%2B49%20%280%292245%20%2F%209160-32>

Fax:

+49 (0)2245 / 9160-21<tel:%2B49%20%280%292245%20%2F%209160-21>

E-Mail:

***@gadiv.de<mailto:***@gadiv.de>

Web:

www.gadiv.de<http://www.gadiv.de/>


Vertreten durch die GeschÀftsfÌhrer:
Walter Jenauer, Axel Heuchmer, Werner Mauelshagen

Gesellschaftssitz: Much
Amtsgericht Siegburg HRB 2487
USt-ID DE123109137
________________________________

Von: Alain D'EURVEILHER [mailto:***@gmail.com<mailto:***@gmail.com>]
Gesendet: Freitag, 6. Juni 2014 10:54
An: Koch, Jan
Betreff: agileMantis refactoring

Hi Jan,
We really like your plugin and would like to use it on our porject.
If you'd like us to help you refactor it in order to meet the Mantis standards about plugins implementation, feel free to ask.
Best Regards
--
AlainD.
--
AlainD.
--
AlainD.
--
AlainD.
Damien Regad
2014-07-08 09:13:24 UTC
Permalink
Post by Schmitz, Jean
To translate custom fields into other languages there needs to be a
file called “custom_strings_inc.php” in the main directory of the mantis
installation.
As our plugin makes use of custom fields and we want to localize them,
is there a clean way to translate the fields just by using the plugin code?
I don't think that's possible.

However, I am not sure that using custom fields is the right design
approach and wonder why you decided to use them instead of creating
plugin-specific tables containing your data. Then you can have full
control over everything.
Post by Schmitz, Jean
So, do you thing that, if we just use the API functions instead of the
direct inserts this will be sufficient?
Your plugin can call any function in the MantisBT APIs including the
custom fields-related ones.


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Robert Munteanu
2014-07-08 09:17:33 UTC
Permalink
Post by Damien Regad
However, I am not sure that using custom fields is the right design
approach and wonder why you decided to use them instead of creating
plugin-specific tables containing your data. Then you can have full
control over everything.
One advantage of custom fields is that they are exposed through the
SOAP API, whereas plug-in defined fields are not.

Robert
--
http://robert.muntea.nu/
Damien Regad
2014-07-08 09:36:14 UTC
Permalink
Post by Robert Munteanu
One advantage of custom fields is that they are exposed through the
SOAP API, whereas plug-in defined fields are not.
Didn't know that. Maybe something to add to the todo list then ?


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Schmitz, Jean
2014-07-08 10:58:06 UTC
Permalink
The reason why we are using custom fields is, that we need to show additional columns on the default "View Issues" page.
We are showing e.g. an assigned Product Backlog and Sprint.
Otherwise we would have had to create our own copy of the "View Issues" page.

The other part is, that we are adding custom fields to the default "Report Issue" page, if the project is assigned to a product backlog.
Again, we would have had to create our own version of the "Report Issue" page.

The good part on that is, that if a new MantisBT Version, with new page layout, gets released our plugin should still work and we don't need to build new pages.

Best regards
Jean Schmitz

Projects on Source Forge:
agileMantis - http://www.agilemantis.org
giServer - http://www.giserver.org

Please join out mailing lists:
[gadivintegrationserver-announcement]
[gadivintegrationserver-development]
[agilemantis-announcement]
[agilemantis-development]
-----Ursprüngliche Nachricht-----
Von: Damien Regad [mailto:***@mantisbt.org]
Gesendet: Dienstag, 8. Juli 2014 11:13
An: Mantisbt-***@lists.sourceforge.net
Betreff: Re: [mantisbt-dev] Fixed Problemes / Improving agileMantis / Help Needed
Post by Schmitz, Jean
To translate custom fields into other languages there needs to be a
file called "custom_strings_inc.php" in the main directory of the
mantis installation.
As our plugin makes use of custom fields and we want to localize them,
is there a clean way to translate the fields just by using the plugin code?
I don't think that's possible.

However, I am not sure that using custom fields is the right design approach and wonder why you decided to use them instead of creating plugin-specific tables containing your data. Then you can have full control over everything.
Post by Schmitz, Jean
So, do you thing that, if we just use the API functions instead of the
direct inserts this will be sufficient?
Your plugin can call any function in the MantisBT APIs including the custom fields-related ones.


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
Alain D'EURVEILHER
2014-07-08 12:08:27 UTC
Permalink
I think that there are events which can be used for that purpose.
On the report page you could use the event EVENT_REPORT_BUG_FORM_TOP or
EVENT_REPORT_BUG_FORM to insert your plugin's form.

There also some events on the view bugs page, at least to be used to insert
some links. But I don't know whether events for filtering and result
display exists yet?
Post by Schmitz, Jean
The reason why we are using custom fields is, that we need to show
additional columns on the default "View Issues" page.
We are showing e.g. an assigned Product Backlog and Sprint.
Otherwise we would have had to create our own copy of the "View Issues" page.
The other part is, that we are adding custom fields to the default "Report
Issue" page, if the project is assigned to a product backlog.
Again, we would have had to create our own version of the "Report Issue" page.
The good part on that is, that if a new MantisBT Version, with new page
layout, gets released our plugin should still work and we don't need to
build new pages.
Best regards
Jean Schmitz
agileMantis - http://www.agilemantis.org
giServer - http://www.giserver.org
[gadivintegrationserver-announcement]
[gadivintegrationserver-development]
[agilemantis-announcement]
[agilemantis-development]
-----UrsprÃŒngliche Nachricht-----
Gesendet: Dienstag, 8. Juli 2014 11:13
Betreff: Re: [mantisbt-dev] Fixed Problemes / Improving agileMantis / Help Needed
Post by Schmitz, Jean
To translate custom fields into other languages there needs to be a
file called "custom_strings_inc.php" in the main directory of the
mantis installation.
As our plugin makes use of custom fields and we want to localize them,
is there a clean way to translate the fields just by using the plugin
code?
I don't think that's possible.
However, I am not sure that using custom fields is the right design
approach and wonder why you decided to use them instead of creating
plugin-specific tables containing your data. Then you can have full control
over everything.
Post by Schmitz, Jean
So, do you thing that, if we just use the API functions instead of the
direct inserts this will be sufficient?
Your plugin can call any function in the MantisBT APIs including the
custom fields-related ones.
---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows Winner
of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--
AlainD.
Alain D'EURVEILHER
2014-07-08 12:11:46 UTC
Permalink
OK, it seems that they do exist in fact:

# Bug filter events
'EVENT_FILTER_FIELDS' => EVENT_TYPE_DEFAULT,
'EVENT_FILTER_COLUMNS' => EVENT_TYPE_DEFAULT,

# Bug report event
'EVENT_REPORT_BUG_FORM_TOP' => EVENT_TYPE_EXECUTE,
'EVENT_REPORT_BUG_FORM' => EVENT_TYPE_EXECUTE,
'EVENT_REPORT_BUG_DATA' => EVENT_TYPE_CHAIN,
'EVENT_REPORT_BUG' => EVENT_TYPE_EXECUTE,


So it means that instead of custom fields you could use these events to
custom your display.
Then the internationalisation would be done inside the lang subfolder of
the agile plugin, no need to rely on the custom_strings_inc.php.

If I'm not wrong.

AlainD.


On Tue, Jul 8, 2014 at 2:08 PM, Alain D'EURVEILHER <
Post by Alain D'EURVEILHER
I think that there are events which can be used for that purpose.
On the report page you could use the event EVENT_REPORT_BUG_FORM_TOP or
EVENT_REPORT_BUG_FORM to insert your plugin's form.
There also some events on the view bugs page, at least to be used to
insert some links. But I don't know whether events for filtering and result
display exists yet?
Post by Schmitz, Jean
The reason why we are using custom fields is, that we need to show
additional columns on the default "View Issues" page.
We are showing e.g. an assigned Product Backlog and Sprint.
Otherwise we would have had to create our own copy of the "View Issues" page.
The other part is, that we are adding custom fields to the default
"Report Issue" page, if the project is assigned to a product backlog.
Again, we would have had to create our own version of the "Report Issue" page.
The good part on that is, that if a new MantisBT Version, with new page
layout, gets released our plugin should still work and we don't need to
build new pages.
Best regards
Jean Schmitz
agileMantis - http://www.agilemantis.org
giServer - http://www.giserver.org
[gadivintegrationserver-announcement]
[gadivintegrationserver-development]
[agilemantis-announcement]
[agilemantis-development]
-----UrsprÃŒngliche Nachricht-----
Gesendet: Dienstag, 8. Juli 2014 11:13
Betreff: Re: [mantisbt-dev] Fixed Problemes / Improving agileMantis / Help Needed
Post by Schmitz, Jean
To translate custom fields into other languages there needs to be a
file called "custom_strings_inc.php" in the main directory of the
mantis installation.
As our plugin makes use of custom fields and we want to localize them,
is there a clean way to translate the fields just by using the plugin
code?
I don't think that's possible.
However, I am not sure that using custom fields is the right design
approach and wonder why you decided to use them instead of creating
plugin-specific tables containing your data. Then you can have full control
over everything.
Post by Schmitz, Jean
So, do you thing that, if we just use the API functions instead of the
direct inserts this will be sufficient?
Your plugin can call any function in the MantisBT APIs including the
custom fields-related ones.
---
This email is free from viruses and malware because avast! Antivirus
protection is active.
http://www.avast.com
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows Winner
of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
mantisbt-dev mailing list
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--
AlainD.
--
AlainD.
Schmitz, Jean
2014-07-11 09:16:53 UTC
Permalink
Indeed there are events to handle that.

When we began to develop agileMantis we made the design decision to use custom fields,
as they seemed to have the smallest development cost.
We use them quite often in our plugin, so it would mean a huge effort to switch to the event driven solution.

So we decided to make all the earlier mentioned changes to our plugin to adapt to the MantisBT-Standards.
But we won’t change the way we handle custom fields (except to make better usage of the MantisBT API)

There is also the problem, that custom fields need to be localized in the custom_string_inc.php in the MantisBT main directory.
As a plugin shouldn’t change anything there we need to manually add the translation strings to that file.
The make this smoother for the plugin users, we want to add a “create custom strings” page in our plugin configuration that either
writes the custom strings to “custom_string_inc.php” (if write is possible) or shows a text area with the content that needs to be added to that file.

It would be nice if we could just add our own “custom_string_inc.php” to our plugin folder. MantisBT could then add our contents to the default “custom_string_inc.php”.
Maybe there are some API functions, that would allow us to localize our custom strings without changing the “custom string_inc.php”?

Best regards
Jean Schmitz

Projects on Source Forge:
agileMantis - http://www.agilemantis.org<http://www.agilemantis.org/>
giServer - http://www.giserver.org<http://www.giserver.org/>

Please join out mailing lists:
[gadivintegrationserver-announcement]<https://lists.sourceforge.net/lists/listinfo/gadivintegrationserver-announcement>
[gadivintegrationserver-development]<https://lists.sourceforge.net/lists/listinfo/gadivintegrationserver-development>
[agilemantis-announcement]<https://lists.sourceforge.net/lists/listinfo/agilemantis-announcement>
[agilemantis-development]<https://lists.sourceforge.net/lists/listinfo/agilemantis-development>

Von: Alain D'EURVEILHER [mailto:***@gmail.com]
Gesendet: Dienstag, 8. Juli 2014 14:12
An: developer discussions
Betreff: Re: [mantisbt-dev] Fixed Problemes / Improving agileMantis / Help Needed

OK, it seems that they do exist in fact:

# Bug filter events
'EVENT_FILTER_FIELDS' => EVENT_TYPE_DEFAULT,
'EVENT_FILTER_COLUMNS' => EVENT_TYPE_DEFAULT,

# Bug report event
'EVENT_REPORT_BUG_FORM_TOP' => EVENT_TYPE_EXECUTE,
'EVENT_REPORT_BUG_FORM' => EVENT_TYPE_EXECUTE,
'EVENT_REPORT_BUG_DATA' => EVENT_TYPE_CHAIN,
'EVENT_REPORT_BUG' => EVENT_TYPE_EXECUTE,

So it means that instead of custom fields you could use these events to custom your display.
Then the internationalisation would be done inside the lang subfolder of the agile plugin, no need to rely on the custom_strings_inc.php.
If I'm not wrong.

AlainD.

On Tue, Jul 8, 2014 at 2:08 PM, Alain D'EURVEILHER <***@gmail.com<mailto:***@gmail.com>> wrote:
I think that there are events which can be used for that purpose.
On the report page you could use the event EVENT_REPORT_BUG_FORM_TOP or EVENT_REPORT_BUG_FORM to insert your plugin's form.
There also some events on the view bugs page, at least to be used to insert some links. But I don't know whether events for filtering and result display exists yet?

On Tue, Jul 8, 2014 at 12:58 PM, Schmitz, Jean <***@gadiv.de<mailto:***@gadiv.de>> wrote:
The reason why we are using custom fields is, that we need to show additional columns on the default "View Issues" page.
We are showing e.g. an assigned Product Backlog and Sprint.
Otherwise we would have had to create our own copy of the "View Issues" page.

The other part is, that we are adding custom fields to the default "Report Issue" page, if the project is assigned to a product backlog.
Again, we would have had to create our own version of the "Report Issue" page.

The good part on that is, that if a new MantisBT Version, with new page layout, gets released our plugin should still work and we don't need to build new pages.

Best regards
Jean Schmitz

Projects on Source Forge:
agileMantis - http://www.agilemantis.org
giServer - http://www.giserver.org

Please join out mailing lists:
[gadivintegrationserver-announcement]
[gadivintegrationserver-development]
[agilemantis-announcement]
[agilemantis-development]
-----UrsprÃŒngliche Nachricht-----
Von: Damien Regad [mailto:***@mantisbt.org<mailto:***@mantisbt.org>]
Gesendet: Dienstag, 8. Juli 2014 11:13
An: Mantisbt-***@lists.sourceforge.net<mailto:Mantisbt-***@lists.sourceforge.net>
Betreff: Re: [mantisbt-dev] Fixed Problemes / Improving agileMantis / Help Needed
Post by Schmitz, Jean
To translate custom fields into other languages there needs to be a
file called "custom_strings_inc.php" in the main directory of the
mantis installation.
As our plugin makes use of custom fields and we want to localize them,
is there a clean way to translate the fields just by using the plugin code?
I don't think that's possible.

However, I am not sure that using custom fields is the right design approach and wonder why you decided to use them instead of creating plugin-specific tables containing your data. Then you can have full control over everything.
Post by Schmitz, Jean
So, do you thing that, if we just use the API functions instead of the
direct inserts this will be sufficient?
Your plugin can call any function in the MantisBT APIs including the custom fields-related ones.


---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com



------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse Turn processes into business applications with Bonita BPM Community Edition Quickly connect people, data, and systems into organized workflows Winner of BOSSIE, CODIE, OW2 and Gartner awards http://p.sf.net/sfu/Bonitasoft _______________________________________________
mantisbt-dev mailing list
mantisbt-***@lists.sourceforge.net<mailto:mantisbt-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
mantisbt-dev mailing list
mantisbt-***@lists.sourceforge.net<mailto:mantisbt-***@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
--
AlainD.
--
AlainD.
Loading...