Thanks @spmeesseman, I'll take care of that in the next few days !

I sent a message to the mailing list but it looks like it hasnt been used in years

Not used much, but still active.

Anyway, looks like your message never reached the ML - I never received it and it does not show on the archive
https://sourceforge.net/p/mantisbt/mailman/mantisbt-dev/

ok great, ill watch for your response for when you have gotten to it and completed. thanks!

@spmeesseman I had a very short look at some of the plugins.
You are using MIT license for them, e.g. https://github.com/spmeesseman/GanttChart2/blob/master/LICENSE.txt

At least some of your work is based on code that has been provided under GPL license, e.g. https://github.com/spmeesseman/GanttChart2/blob/master/pages/summary_gantt_chart.php

IANAL and have no time for deeper analysis, but it seems that MIT license can't be used.
https://opensource.stackexchange.com/questions/1640/if-im-using-a-gpl-3-library-in-my-project-can-i-license-my-project-under-mit-l

@atrol, no problem I will switch the license in the plugins to match the others in the community, will post back when completed

@atrol ok, i did it right away, all plugins now come with GPLv3 license

@spmeesseman some of those plugins contain code originally licensed under MIT license by other authors - i'd avoid changing those to the GPL. A number of the community plugins are MIT licensed. I was thinking of using one of the plugins, but if the license is changed to GPL, it would be easier to work on within my company if I were to fork the pre-gpl license version and develop on from that point.

@pucluslust hmmm ok, ill have to re-evaluate all of that, im pretty new to the modern day open source world so any help in regarding correct licenses to use for specific plugins is very much appreciated

As far as I know, the only code functionality wise used from other plugins is Releases (releasemgt), which has no license information, and GanttChart2 (GanttChart), which is licensed under GPLv2.

EDIT: and ApiExtend, which uses modified auth layer from MantiBT itself

@pucluslust Which were you referring to?

Well, taking your example - releasemgt used to be MIT - https://code.google.com/archive/p/mantis-releasemgt/

@pucluslust i will change Releases plugin to MIT then, my bad theres just no info on the GitHub repo about that

@atrol - for the other plugins, do you suggest I use something else other than GPLv3 for the others? At the moment they are all provided with GPLv3

@spmeesseman I sent you an invitation to join the mantisbt-plugins organization, please accept it.

I noticed that at least 2 of the plugins you listed, already exist in the org (not sure about the others):

• GanttChart2 ==> GanttChart
• Releases ==> ReleaseMgt

I believe it would make sense to update the existing repos with your fixes/improvements. Creating separate plugins would create confusion for potential users and require cross-reference links and updates to readme to avoid that.

@spmeesseman for the plugins you created from scratch, you can use whatever license you want.

If you started your work based on existing plugins, you should not remove/change any licensing information (e.g. you did in GanttChart2).

And +1 to the proposal of @dregad to update existing repos instead of creating separate ones.

@atrol - i would disagree with that suggestion

I originally came across this post as I happened to see the releases plugin vs releasemgt. We currently use the releasemgt plugin here with 3 internal changes, and having evaluated the plugin by spmeeseman, we would be looking to continue running the existing version as it fits our needs better.

Of our 3 internal changes, and considering them, I believe one of them would be something that we could consider sharing - the other 2 I believe are more likely to be specific to our internal setup.

Having similar plugins should not be a problem - we've not updated the releasemgt plugin as the current functionality and version fits our needs - in contrast, the new version has some functionality in it that we would need to remove. I'd consider it quite a common scenario that plugins will be developed by companies for their needs; and therefore may not be updated if they are not broken. In that scenario it should be possible for there to be a choice for users between plugin's

For a new user, they are likely to choose the plugin that looks like it is regularly updated etc.

Trying to force companies/users to follow a single path is likely to also be frustrating - for instance, we would need to strip out some of the changes done to the releasemgt plugin. We could of course solve that by sending a PR to the plugin for the changes that I believe are internal to our setup, but that would not be fair on other users of the plugins who do not have our setup for example.

Thanks for the acceptance! and the info on licensing, I guess that is common sense, and my bad

@dregad @atrol i really wouldn't want to rename/merge, I guess I could for the GanttChart2 plugin but definitely not for Releases as I have that url embedded everywhere now in my stuff. Both the releasemgt plugin and ganttchart plugin have not been touched on years and years, i think the ganttchart plugin i think hasn't been touched in over 10 years, and does not work in mantis v2, thus my renaming to ganttchart2.

i will hold off on transferring my plugins until I get your final feedback on that. My preference would be to not rename/merge either of them, but if necessary I would rename GanttChart2. The Releases plugin I would hold back and just keep it in my own account. I'm also assuming if the GanttChart2 plugin needs to be renamed/merged, i would become the sole committer for that?

@pucluslust thanks for the input

@dregad hmmm i dont see the invitation anywhere

EDIT: ah, i found it, had to go to the mantisbt-plugins page. i didnt get any kind of notification about it

@pucluslust
I understand your position, but IMO you can't expect us or plugin maintainers to take every specific, individual need into consideration, particularly in the absence of contribution to the development (i.e. pull requests). As you pointed out, there is always the possibility of maintaining your own fork with customizations.

@spmeesseman

i really wouldn't want to rename/merge

Note that it's really not about the name, but more a question of ensuring continuity in code history, as well as trying to avoid offering multiple plugins that basically do the same thing. In other words, my expectation would be that you apply your changes and improvements to the existing repository (either via pull requests or direct commits).

I guess I could for the GanttChart2 plugin

Then please do

definitely not for Releases as I have that url embedded everywhere now in my stuff.

I hear your point. Still, I'd like to try and convince you to consider a one-time search/replace operation.

If that is definitely not acceptable, I'd still like to have your plugin in the org, but in that case the old ReleaseMgt plugin would need an update to the readme, to clearly indicate that it's unmaintained and redirecting users to your plugin.

I'm also assuming if the GanttChart2 plugin needs to be renamed/merged, i would become the sole committer for that?

Indeed, you'd be granted push access to the existing repo(s). That said, since the MantisBT core team also has access, technically you'd not be the sole committer, but we generally don't touch community plugins unless they become unmaintained (like GanttChart).

I sent you an invitation to join the mantisbt-plugins organization, please accept it.

i didnt get any kind of notification about it

No idea why. I expected that GitHub would send you an e-mail.

@dregad Presumably the process to go through to contribute plugins is as at https://www.mantisbt.org/wiki/doku.php/mantisbt:plugins:start#hosting_a_new_plugin ?

@pucluslust Correct.

@spmeesseman Following feedback from GanttChart plugin author I have granted you access to the repository.

@dregad, I can meet you half way and merge GanttChart, but my apologies I have zero interest in merging Releases with releasemgt. Its not just a search and replace in a project, it is everywhere throughout everything I've done, files,scripts, READMEs, etc , as I plan to use this for all of my other projects.
I'll try to start the transfer processes today
Thanks again for acceptance into the community, I have thoroughly enjoyed working on this Mantis stuff.

@dregad @atrol Also, another question, I wrote an ExtJS npm module for ExtJs applications to talk to MantisBT, its a full fledge helpdesk view basically. It technically isnt a "plugin" though, and isnt complete yet. Any interest in having that in the community org?

@dregad we will look at contributing our changes to releasemgt as a new plugin. It has been updated internally by a colleague, so what used to be 3 changes is now substantially more. One potential issue I can see is we'd renamed the plugin to remove 'mgt' - and then plural'd it - So it had also been called releases; presumably that is not a problem, as the case is different. Our database schema is different and we've got over 50 internal databases across the globe that have this plugin initialised with that name.

I'm away on holiday for 2 weeks from today (summer holiday with the kids) - I will look at posting up about our releases plugin when I return in 2 weeks to the forum.

To avoid any confusion, I'll stop posting to here as this is about integrating someone spmeesseman's plugins and will continue/start the conversation about our plugin via the forum in 2 weeks.

@spmeesseman - really like the ServerFiles plugin - we've actually installed that here today as a test. We are trying to decide whether to make use of it or not as it could be security risk - do you have any intention yourself to allow control by different users? For example user X can edit file 1 and 2, but user & can only do file 1 and user Z can only do file 2 ? If you have plans to add that sort of functionality, I'd be interested to know (happy to move that to a ticket on github). Equally if it is a route feel is reasonable (safe/risk) to use, we may be able to contribute and put in a PR against the ServerFiles plugin - although that would not be until at least mid September at the earliest.

@pucluslust i can certainly add that to the todo list. One problem I just noticed today is I think the ServerFiles plugin is saving text with carriage returns. If youre not running windows, watch for that fix Ill have that fixed in the next few days.
Side note - Maybe I read that wrong, but your plugin is called 'releases'? That's what mine is called, I did the same thing dropped the mgt and added an s

@spmeesseman last message probably before I leave for vacation. I need to check what db table use - I know the mgt bit went (as that was giving spelling warnings on one of our internal tools when we first developed a mod). It is definitely in lower case aka release(s) - as opposed to your plugin that was Releases. The plugin_lang calls are case sensitive - so I know in the web ui the name is shown as releases. What I'm not sure if what the base-name of the plugin is - as that is what is used in the 50 DB's - currently it is going to be either releases or if really lucky release - will have to see where that goes and impact of it in 2 weeks

In terms of server files, i'd look at changing/checking the following:

diskfile - string_display_line - probably should be string_attribute

carriage returns - not an issue yet, we are currently using the plugin as a discussion. If we ran a plugin like ServerFiles, we would be able to reduce the number of accounts that would need access to ssh/db's etc, as some people could use the plugin for some maintenance. The downside is we increase the risk if a web account gets compromised as server files may be accessible/changeable.

@pucluslust

One potential issue I can see is we'd renamed the plugin to remove 'mgt' - and then plural'd it - So it had also been called releases; presumably that is not a problem, as the case is different

Mantis expects basenames to be unique, which means that only one of the plugins could be installed in a given MantisBT instance at one point in time.

Relying on case is not sufficient to fully differentiate the plugins, as some RDBMS (eg. MySQL, Oracle) are not case sensitive, so there would be a collision on plugin tables.

I would strongly advise to use a distinct name.

@dregad I transferred the ApiExtend plugin, I wanted to check with you first before I added the ojthers to make sure I did it right. The doc is a little confusing in that it says a team will be created for us "then" transfer the repository, but I see the section at the end of the doc targeted at org owners and there it makes it seem like you guys will create the team "after" I transfer.

Anyway, just wanted to make sure I did it correctly, Ill wait for your response and then get the others transferred as soon as I have a chance

The doc is a little confusing in that it says a team will be created for us "then" transfer the repository

Sorry for the confusion. GitHub changed the way these repo transfers work with regards to access rights within the target org, so the doc is somewhat out of date, I should update the wiki, but never got around to it...

I'm sure you did it right, but I'll check and let you know.

@dregad from this side, we only have the option to release a plugin called releases; as the table name in 50 db's can't be changed.

@spmeesseman

I'll check and let you know

Everything seems OK as far as I can tell.

Please review the badges in the README, I noted

• a broken link (app publisher)
• references to the repo's original home under your own GitHub account
• duplicated open issues badge

Also, if you're going to be using your own tracker for issues, then you should probably indicate that clearly in the README file, and deactivate the native GitHub issues.

@pucluslust

we only have the option to release a plugin called releases; as the table name in 50 db's can't be changed

I understand. In that case I would suggest to add a clear warning in the README file, to inform users about the conflict with the other plugin (including details about the potential consequences if you can).

@dregad ill take care of the notes you made b4 transferring the others. One question, the second item, where are these references to the old ? Or maybe that was something I fixed last night after transferring, I just pushed all those commits just now since I didnt have access anbymore last night. thanks for your help

One question, the second item, where are these references to the old ?

Details in https://github.com/mantisbt-plugins/ApiExtend/issues/1

Ill handle all that soon...

one more question, i want to host issues on my mantis site, but every time I turn on allow_signup, pornhub goes to work soon after, you just missed it I see you created an account right before that all happened earlier this morning (U.S). 5 users, 10 new tickets, and a comment on all my existing tickets, all within a few minutes. How do we protect against this while you have account_signup on? Is there something in the config that I'm missing where certain keywords can be blocked?

In any case, Ill try to have everything moved over this weekend.

Thanks again for your help

Sorry to hear it. Maybe they thought you like this kind of movies ;-) Joke aside, we get the occasional spam attack here too. When that happens we disable signup as well. We don't have keyword filtering unfortunately, but you can try to tweak the antispam settings in config_inc.php. If this happened via API, maybe you could restrict access to that.

They do actually sign up for accounts, then do get restricted by the anti-spam setting set at 5 requests per hour currently, Ill lower that even more. It could be handled in a few ways, (1) functionality to "approve" new accounts before they get created and (2) keyword filtering for added protection.

I found a ticket referencing (1), an old one but still open 0004112, would there be any future plans for this? If not I think I may take this task on, but would need some hooks in the application if I were to do it in a plugin probably. Or maybe this is not the place/ticket to ask these questions, I can start a new one or wait for a response on 0004112

am I able to edit the GitHub project page's "description" field in my repositories that I transfer? I can't edit the ApiExtend description, there is no "Edit" button showing for me

cant-edit-descrip-gh.png (8,554 bytes)   

cant-edit-descrip-gh.png (8,554 bytes)   

I can't edit the ApiExtend description, there is no "Edit" button showing for me

I believe that's a limitation of the Write permission level we grant to all plugin owners within mantisbt-plugins org.
We use that and not Admin, to ensure no destructive actions are possible.

I see now that GitHub have added a new Maintain role (in beta), I'll try to grant you that, let me know if that works.

I just transferred CommitReact, and was able to push to it right away. Is that supposed to happen? I can make commits to it without being on the plugins "team" yet? Or because I was the one who transferred do I still have push rights even before you create the team? Just seems wrong, I can't edit a simple description (0025946:0062482) on the project homepage but I can make commits....

Will do, thanks!

EDIT: works great, i can edit the description now, thanks!

I just transferred CommitReact, and was able to push to it right away. Is that supposed to happen?

Yes. When you transfer a repo, you retain Write access to it in the target org.
It would appear that the Team is no longer strictly necessary (but can still be convenient and useful, if there is more than one person working on the plugin).

Do let me know as you transfer each repo, and I'll make sure you have Maintain role.

Ah, ok that makes sense. I just now transferred "DefaultVersions". I'll try to get the rest of them transferred later tonight

EDIT: I squeaked in IFramed plugin as well, so far I have transferred: ApiExtend, CommitReact, DefaultVersions, and IFramed.

Will get to the rest tonight hopefully

Ok, I have them all transferred now, and I've updated the GanttChart plugin

i added an additional one i did tonight too, SecurityExtend

Have a little additional request, looks like I cant set up web hooks for my transferred plugins, even the ones you gave me the bump in permission for so far. Can you add the webhooks for me? The url is https://app1.spmeesseman.com/plugin.php?page=Source/checkin..., maybe you're familiar with this plugin url haha. Would just need a way to get you the api key, could i just post it here if i marked the note private?

@spmeesseman I can create the hooks for you, no problem (but not right now).

As for the API key, you can post it here as a private note if you want (in which case the other devs would see it) or send it to me via e-mail or Gitter.

@dregad ok, thanks, Ill post it here when I'm sure I have everything ready to go

@dregad @atrol - i have a project that is a Sencha ExtJs npm package that provides a portal view to the MantisBT ticketing system for ExtJs applications.

It technically isn't a MantisBT plugin, and in a raw stage, but wondered if you have any interest in having this one in the community org?

Sencha ExtJs npm package that provides a portal view to the MantisBT ticketing system for ExtJs applications
It technically isn't a MantisBT plugin [...] have any interest in having this one in the community org?

the mantisbt-plugins org's purpose is to host MantisBT plugins.
I don't think it would be appropriate to host other MantisBT-related software there. My note 0025977:0062530, explains why.

the mantisbt-plugins org's purpose is to host MantisBT plugins.
I don't think it would be appropriate to host other MantisBT-related software there

@dregad not sure if you are aware that this is not a plugin https://github.com/mantisbt-plugins/codev

not sure if you are aware that this is not a plugin https://github.com/mantisbt-plugins/codev

Yes I know. IMO it was a mistake back then to have accepted it in the org.
So now it's there, but at some point we may want to reconsider, especially if it comes to automating plugins management.

I guess this can be closed now :-)