P Richards | 17 Jul 23:39 2014

View Issues Page

Hi All,

 

I’ve been experimenting for a while about whether to make use of http://datatables.net/ for the view issues list  and related filtering functionality

 

The aim here would be to modernise and try and improve the existing filtering:

 

·         Make use of Ajax requests for filtering response to avoid a full page load.

·         Try to simplify the filtering options that are currently above the view issues page to take up less space on the screen.

·         Allow easy colour theming of the grid for non-technical users - Data Tables provides colour theming functionality through the use of jquery’s themeroller (http://jqueryui.com/themeroller/ ), and I know in 1.3 we move what used to be the jquery plugin into the core, and include jquery UI in the core, as well as its own theme creator (http://datatables.net/manual/styling/theme-creator ). Of course, making use of Jquery’s theme roller would allow someone who has a plugin utilising jquery ui already to theme both the grid and the plugin in one go.

 

I’ve done a bunch of preliminary work for a while now into this (and actually make use of a hacked up implementation of the datatable functionality on my work Mantis instance), I’d like to sit down and try and get an implementation done that would be suitable to include in the open source version of Mantis.

 

Before I proceed on this, I’m after some feedback on:

·         Whether people feel that making use of datatables for the View issues functionality specifically would be useful, and improve the current behaviour.

·         Whether, whilst it works in my work environment (Which is controlled in terms of browsers/devices/people using it), would be a bad idea to try and make work as part of the core Mantis

·         Given the suggestion of using datatables, whether there are any key things to consider when doing an initial implementation i.e. ideas of things you would like to see

·         How important it would be to support the use of jquery’s themeroller to allow customising the colours of the datatable in an easy to use manner.

 

I’ve obviously got some ideas on the above, and some background experience having added it to my work instance of Mantis, of what I think works, but it would be good to get some feedback/thoughts from both users and others on the dev team on this concept before spending time trying to port, generalise and improve the code from work to the latest master.

 

Whilst I could have submitted a patch with this proposal, I feel that the filtering and viewing issues functionality within Mantis is key to the usability of Mantis – and arguably it’s success or failure, that I’d rather see what views and opinions people have first J - and see if others in the community have any good suggestions or ideas that could be covered as part of looking at improving this part of Mantis.

 

Paul

 

 

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
mantisbt-dev mailing list
mantisbt-dev@...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
P Richards | 14 Jul 01:09 2014

DB API syntax Backport

Hi All,

 

I’ve just generated a Pull Request that would include some of the DB API changes in functionality for use alongside the existing format.

 

There’s a twofold reason for doing this:

 

a)      It helps us to extend and support 1.3 long term. We can start dropping the use of db_get_table() in core, whilst keeping it for plugin authors etc in 1.3. Plugin authors will be able to update their plugins, keeping compatibility with 1.3, and also adding compatibility for “2.0” – which we’ve already said will be released shortly after 1.3 with the DB API changes.

b)      It reduces the size of the patch set waiting to hit master after we branch into our normal master-1.3 status – in the past, we’ve given ourselves grief by ending up with big differences between master and master-1.2 within days of a release.  (as a side note, this is part of my rationale for spending some time recently to try to standardise our code, so we don’t end up doing this with the 1.3 release. I’d like to see things like the example from a week ago of https://github.com/mantisbt/mantisbt/commit/83e1cfde28459f74fd34aa8a2e233ccd7c6385dd a thing of the past ;))

 

Assuming that the small change in https://github.com/mantisbt/mantisbt/pull/216 passes review, I’ll generate a PR that implements the use of the new syntax over db_get_table for review.

 

I’m deliberately doing this as a two step process so that people can test and review that the above change is a standard alone change with no impact on the existing code base.

 

Details of PR below:

 

Backport from DB API changes functionality to set table name.

 

This would allow the use of the new syntax i.e.:

 

-$t_query = 'SELECT COUNT(*) AS unused_user_count FROM ' . $t_user_table . '

+$t_query = 'SELECT COUNT(*) AS unused_user_count FROM {user}

 

Whilst still allowing use of the old syntax, to give developers and plugin

authors the opportunity to start migrating code to the new syntax ready

for the 2.x.

 

By doing this, it also helps us extend the life of 1.3 - as it stands, if we

release test versions of mantis with the new DB layer about within a month of

the final 1.3 release as previously agreed, we could reach the stage where we

have support issues from our side for the 1.3 release.

------------------------------------------------------------------------------
_______________________________________________
mantisbt-dev mailing list
mantisbt-dev@...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
P Richards | 14 Jul 00:35 2014

Code Standards

Hi All,

 

I’ve just finished the final pass of the work on code standards within mantis. I personally, don’t plan on doing anything more on the code base on this for a while – (UNLESS others (well Damien!) have suggestions on things that are not covered and they would like covered.)

 

I’m now going to focus on getting the code standards checking a part of the build process for both developers locally and on travis.

 

Current ‘build’ errors on the codesniffer rules I’ve got are listed below.

 

In Mantisconnect.php, I believe we can remove the use of $QUERY_STRING as that is legacy from php 4.

In API/Soap/mc_api.php – l_oServer as a global variable I believe is also legacy from the nusoap days – rombert can you confirm ?

The issue with user_pref_api.php is a rule error that I’ll fix.

 

PHP codesniffer ruleset is available on a branch under my github, if people want to provide some feedback against the ruleset.

 

Alternatively, it would be good to get some feedback on any code in mantis that now remains that people believe do not cover our existing code standards.

 

Thanks for bearing with me as I’ve gone over the code over the last few weeks, as it’s taken about a week and a half longer than I expected to do a final pass – as work took up a bunch of time I wasn’t expecting.

 

If anyone has any existing pull requests, that they would rather me update against latest master to save having to go back and re-doing the work, drop me an email address of the existing pull request ID, and I will generate clone your github repository and do the work for you.

 

Paul

 

 

 

----------------------------------------------

 

FILE: adm_config_report.php

78 | ERROR | Global Variable "t_config_types" should be prefixed $g_

 

FILE: api\soap\mantisconnect.php

43 | ERROR | Variable "QUERY_STRING" U is not prefixed

50 | ERROR | Variable "QUERY_STRING" U is not prefixed

50 | ERROR | Variable "QUERY_STRING" U is not prefixed

51 | ERROR | Variable "QUERY_STRING" U is not prefixed

 

FILE: api\soap\mc_api.php

132 | ERROR | Global Variable "l_oServer" should be prefixed $g_

 

FILE: core\classes\MantisEnum.class.php

116 | ERROR | Variable "_cacheAssocArrayIndexedByValues" c is not prefixed

117 | ERROR | Variable "_cacheAssocArrayIndexedByValues" c is not prefixed

144 | ERROR | Variable "_cacheAssocArrayIndexedByValues" c is not prefixed

 

FILE: core\columns_api.php

638 | ERROR | Global Variable "t_icon_path" should be prefixed $g_

757 | ERROR | Global Variable "t_icon_path" should be prefixed $g_

957 | ERROR | Global Variable "t_icon_path" should be prefixed $g_

1049 | ERROR | Global Variable "t_icon_path" should be prefixed $g_

1162 | ERROR | Global Variable "t_icon_path" should be prefixed $g_

1192 | ERROR | Global Variable "t_sort" should be prefixed $g_

1470 | ERROR | Global Variable "t_icon_path" should be prefixed $g_

1518 | ERROR | Global Variable "t_icon_path" should be prefixed $g_

 

FILE: core\custom_function_api.php

312 | ERROR | Global Variable "t_sort" should be prefixed $g_

 

FILE: core\install_helper_functions_api.php

95 | ERROR | Global Variable "f_db_type" should be prefixed $g_

 

FILE: core\user_pref_api.php

259 | ERROR | Variable "_default_mapping" d is not prefixed

261 | ERROR | Variable "_default_mapping" d is not prefixed

276 | ERROR | Variable "_default_mapping" d is not prefixed

------------------------------------------------------------------------------
_______________________________________________
mantisbt-dev mailing list
mantisbt-dev@...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
Schmitz, Jean | 7 Jul 11:02 2014
Picon

Re: Fixed Problemes / Improving agileMantis / Help Needed

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

giServer - http://www.giserver.org

 

Please join out mailing lists:

[gadivintegrationserver-announcement]

[gadivintegrationserver-development]

[agilemantis-announcement]

[agilemantis-development]

 

Von: Alain D'EURVEILHER [mailto:alain.deurveilher <at> 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 <J.Schmitz <at> 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:alain.deurveilher <at> 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 <J.Koch <at> 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

Fax:

+49 (0)2245 / 9160-21

E-Mail:

j.koch <at> gadiv.de

Web:

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:alain.deurveilher <at> 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.

------------------------------------------------------------------------------
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-dev@...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
Damien Regad | 6 Jul 11:38 2014

Mylyn connector

Rombert,

User reported on IRC [1]:

The Mylyn (An Eclipse Bug Tracker Integration tool) seems to be broken 
with Mantis I'm not sure where to look for help. The Mylyn Mantis 
Connector website seems broken?
well I should say, there is no place for support on it.

Maybe you want to take a look ?

[1] 
http://www.mantisbt.org/irclogs/mantisbt/2014/mantisbt.2014-07-04.log.html#t2014-07-04T13:28:05

D

------------------------------------------------------------------------------
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
Schmitz, Jean | 4 Jul 10:23 2014
Picon

WG: Fixed Problemes / Improving agileMantis / Help Needed

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

giServer - http://www.giserver.org

 

Please join out mailing lists:

[gadivintegrationserver-announcement]

[gadivintegrationserver-development]

[agilemantis-announcement]

[agilemantis-development]

 

Von: Schmitz, Jean
Gesendet: Donnerstag, 3. Juli 2014 17:02
An: 'Damien Regad'; 'mantisbt-dev <at> 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: dregad <at> gmail.com [mailto:dregad <at> 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 <alain.deurveilher <at> 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 <J.Schmitz <at> 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:alain.deurveilher <at> 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 <J.Koch <at> 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

Fax:

+49 (0)2245 / 9160-21

E-Mail:

j.koch <at> gadiv.de

Web:

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:alain.deurveilher <at> 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.

 

------------------------------------------------------------------------------
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-dev@...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
Schmitz, Jean | 3 Jul 17:02 2014
Picon

Re: 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: dregad <at> gmail.com [mailto:dregad <at> 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 <alain.deurveilher <at> 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 <J.Schmitz <at> 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:alain.deurveilher <at> 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 <J.Koch <at> 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

Fax:

+49 (0)2245 / 9160-21

E-Mail:

j.koch <at> gadiv.de

Web:

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:alain.deurveilher <at> 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.

 

------------------------------------------------------------------------------
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-dev@...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
yuriy | 27 Jun 05:42 2014

Permission for changes in Mantis logo

Hi, i want to make a few skins for mantis (as part of ThePoser plugin, 
so users will be able to switch between em), can i play with Mantis logo 
a bit?
I want to make 2 extra logos:
1) Same colours, but flat
2) Monochrome logo, which can be used as glyph icon
I'll keep current logo as default, just want to add a few more options.

Why?
Obvious example: skin with dark background.

The code is GPL, but logo is part of Mantis identity, maybe it is 
registered trademark? This is why i'm asking for permission.

--

-- 
--
Best regards,
Yuriy Okhonin
http://vihv.org
http://agavestorm.com
email: yuriy@...
skype: yoreck_o
+7 950 40 65 803

------------------------------------------------------------------------------
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
yuriy | 20 Jun 20:06 2014

Re: Request for plugin hosting

Sorry, i forgot to send github username, here it is: snowyurik

On 06/21/2014 01:59 AM, yuriy wrote:
> Hi, everyone!
> I want to contribute a small plugin that changes the look of Mantis. 
> See attached before.png and after.png
>
> Name: The Poser
>
> Description: Shiny look for Mantis.
>
> Why it will be useful?
> 1) Devs and testers are not the only people who use bugtracker. If it 
> is public - ordinary people, sometimes humanitarian people will use 
> it. If it is used to to manage enterprise apps - sales will use it, 
> various managers. And all they want is - something bright and shiny. 
> They do not care about features. The problem is - they can make your 
> life a pain.
>
> 2) People who report bugs (except professional testers) are not 
> satisfied with your product by definition. They expect your program 
> will work but it does not. And that they see on your website? For new 
> clients it is all bright and shiny but for those who have some 
> problems - it is.. ok, it is not so bad, but it looks like you does 
> not pay attention to the customers who need help. Like if you talk to 
> them and play video game in same time. "New clients are welcome, 
> existing clients are not so important". This people caught a bug, so 
> they are not happy already and it will be useful to pay a bit more 
> attention to design, so they will be a little more loyal.
>

--

-- 
--
Best regards,
Yuriy Okhonin
http://vihv.org
http://agavestorm.com
email: yuriy@...
skype: yoreck_o
+7 950 40 65 803

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
Victor Boctor | 15 Jun 18:59 2014
Picon

MantisBT 1.3 Release Status Check

I inspected the issues that are marked for v1.3 to see how far we are from the release and found 7 bugs targeted for 1.3.  I grouped them into what two groups based on my opinion of blocking vs. not.  It would be great for everyone to comment on what they are working on that they feel blocks us from putting out the 1.3 release candidate.  We can follow up with further fixes before the final releases.

Blocking and Specific to master:
--------------------------------

17437: Plugin breaks
- There are a few changes in 1.3 that breaks plugin, I think we should see if we can fix those.  i.e. keep helper_alternate_class() around just for plugins until we do the breaking changes with the db layer.  There are cases that are technically breaking, but the chance of breaking is rare, vs. the helper_alternate_class which I suspect will be more common for plugins that have configuration pages.  I suggest at least fixing the latter one.

16570: Page content in 'Report Issue' is forgotten when user clicks [Back] button in browser
- That is a really annoying bug.  Paul has a fix that seems to be pending more reviewers - https://github.com/mantisbt/mantisbt/pull/202

16878: Install triggers varchar to datetime conversion error on sql server 2008
- what's the status?

Shouldn't be blocking
---------------------

9885: Emails on relations is send to people who cannot see the related issue
- Open since 2008.  Does it really need to block the release?  If there is a targetted fix, let's do it?

11399: Deprecate $g_show_realname and use $g_show_user_realname_threshold instead
- I don't think this should block v1.3

12382: Long emails aren't sent and make Mantis freeze
- This is a corner case, is in 1.2.x and can be fixed in a dot release.  Even though it is good to fix, it is not blocking.

12144: changing to the next custom status does not work
- Nice to fix.  Fix can come in at any time.

Thanks,
-Victor
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
mantisbt-dev mailing list
mantisbt-dev@...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev
Victor Boctor | 15 Jun 18:57 2014

Release 1.3 status check

I inspected the issues that are marked for v1.3 to see how far we are from the release and found 7 bugs targeted for 1.3.  I grouped them into what two groups based on my opinion of blocking vs. not.  It would be great for everyone to comment on what they are working on that they feel blocks us from putting out the 1.3 release candidate.  We can follow up with further fixes before the final releases.

Blocking and Specific to master:
--------------------------------

17437: Plugin breaks
- There are a few changes in 1.3 that breaks plugin, I think we should see if we can fix those.  i.e. keep helper_alternate_class() around just for plugins until we do the breaking changes with the db layer.  There are cases that are technically breaking, but the chance of breaking is rare, vs. the helper_alternate_class which I suspect will be more common for plugins that have configuration pages.  I suggest at least fixing the latter one.

16570: Page content in 'Report Issue' is forgotten when user clicks [Back] button in browser
- That is a really annoying bug.  Paul has a fix that seems to be pending more reviewers - https://github.com/mantisbt/mantisbt/pull/202

16878: Install triggers varchar to datetime conversion error on sql server 2008
- what's the status?

Shouldn't be blocking
---------------------

9885: Emails on relations is send to people who cannot see the related issue
- Open since 2008.  Does it really need to block the release?  If there is a targetted fix, let's do it?

11399: Deprecate $g_show_realname and use $g_show_user_realname_threshold instead
- I don't think this should block v1.3

12382: Long emails aren't sent and make Mantis freeze
- This is a corner case, is in 1.2.x and can be fixed in a dot release.  Even though it is good to fix, it is not blocking.

12144: changing to the next custom status does not work
- Nice to fix.  Fix can come in at any time.

Thanks,
-Victor
------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
mantisbt-dev mailing list
mantisbt-dev@...
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev

Gmane