From working on the 'radical' 2.x idea, I've concluded 3 things:
 
a) I like mantis
b) I dislike the mantis 1.2.x codebase
c) I'm not happy with the 2.x codebase
 
-> trying to convert X to an object, and looking at code paths, you find in some cases that if you do change Y by route Z, it'll not email, update whatever, and check permission A but if you do the same change by route ZZ, it'll check permission B, but email
 
And that's with me ignoring the soap api :)
 
It's quite a good game to play!
 


On Tue, Oct 1, 2013 at 10:16 AM, Damien Regad <dregad@mantisbt.org> wrote:

On 2013-10-01 10:32, Paul Richards wrote:
> On a different note, and your about to hate me :
> https://github.com/mantisbt/mantisbt/commit/ce3450aaabbd9d9feceb03d77d4358f195e7d966
> Surely, we want to store custom field ID as opposed to field name in the
> history table, such that if a custom field gets renamed, or two custom
> fields have the same name, the history table gets linked to the correct
> custom field.

No hate, really. This is a good point that I did not consider, since it
was a fix I just built on existing practice without thinking further.

Replacing the CF name by CF id would require either modifying the
update_history_long_custom_fields() helper function, or create another
UpdateFunction schema change step.

I'll file an issue to track this.

D

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
mantisbt-dev mailing list
mantisbt-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mantisbt-dev