Mantis Bug Tracker Workflow

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0025044Community[OCCT] OCCT:Meshpublic2014-07-01 14:232019-08-18 14:27
Assigned Toabv 
PlatformWindowsOSVC++ 2010OS Version64 bit
Product Version[OCCT] 6.6.0 
Target Version[OCCT] 7.4.0*Fixed in Version 
Summary0025044: BRepMesh tweaks
DescriptionAt the code base 6.6.0 I made several modifications to BRepMesh code in order to receive more consistent mesh for my model data base. At the current code base, my modifications also perform equally or better in 80% cases. Unfortunately, it's almost impossible to merge properly my modifications to the current code base, therefore I commit them as they are.
Besides the better mesh results, my modifications can use ProgressIndicator in order to represent the meshing progress and to abort processing.
According to my performance comparison, my modifications perform up to 10% slower as the current code base (for the most of the models the difference is 1-2%).
Steps To Reproducepload ALL

stepread bicycle.step a *
renamevar a_1 a

tclean a

set faces [explode a f]
set nb [llength $faces]
for {set i 1} {$i <= $nb} {incr i} {
  set info [incmesh a_$i 0.31]
  set status [lindex $info 6]
  if { [string compare $status "NoError"] != 0 && [string compare $status "Reused"] != 0 } {
    puts $i; puts " - "; puts $status
Additional information
and documentation updates
Changes from 0024923 are also include in this commit.
TagsNo tags attached.
Test case number
Attached Files? file icon Checking Fixture Clamping.STEP (1,552,563 bytes) 2014-08-13 13:00
zip file icon (774,124 bytes) 2014-08-13 19:43
zip file icon Median cx-fs01 bicycle ( kerékpár ).zip (4,443,025 bytes) 2019-08-07 10:31

- Relationships
related to 0024923closedbugmaster Community BRepMesh_CircleTool produces bad circles 
related to 0025061newoan Open CASCADE BRepMesh should skip internal wires with self intersections to produce mesh for the shape anyway 
parent of 0025113assignedoan Community Progress indication and user break functionality for BRepMesh component 
Not all the children of this issue are yet resolved or closed.

-  Notes
drazmyslovich (developer)
2014-07-01 14:26

The tweaks are committed, please, review them
oan (developer)
2014-07-30 18:22


Sorry for late reply. First of all, thank you a lot for your commitment.
We had to finish several activities related to BRepMesh and now I am going to explore tweaks you pushed to repository.

I have briefly inspected the changes and I immediately noticed a magnificent thing, the draft for progress indication functionality. I am going to integrate it first!
The bad news are that it is very difficult to recognize changes in BRepMesh_Delaun due to huge modifications made since 6.6.0. These modifications include functionality resolving some problematic cases as well as new approach of adjusting of a mesh to face boundaries and hence they are highly correlated with code in your branch.

Considering this fact it is preferable to check current state of OCCT for consistency with your model data base, therefore, I kindly ask you to provide models related to each tweak made in BRepMesh if possible. After that we can add them to OCCT non-regression testing base that will allow us to consider these cases for further evolution of the component. In order of private nature of that models we can place them to the base of private shapes that assures that they will not be available to anyone except of us. Concerning changes in general, could you please provide brief description for particular tweak? It is necessary to identify parts of code implemented in context of distinct problem as well as the problem itself.

Additionally, I suppose to split current issue on several ones in order of proper check for regressions and modifications if necessary. This will help us to apply changes more safely.

With best regards,
drazmyslovich (developer)
2014-08-04 15:58

Hello, oan,

Thank you for your feedback.

For sure, I checked the current state of OCCT BRepMesh module, and naturally it performs much better as 6.6.0 original state, but still in comparison with my modified version of 6.6.0 module it lacks in a lot of cases, as I've written in the description only in 20% of models the current OCCT BRepMesh module performs better as 6.6.0 with my modifications.

And unfortunately, due to the huge changes in BRepMesh module since version 6.6.0 it's almost impossible to merge my modifications directly into the current code base. I've discussed this situation already once with abv and he has recommended me to commit my changes as they are. I can provide you with unified diff of all my modifications in BRepMesh folder for 6.6.0, if it will help to identify the changes.

Regarding the models with failed meshes - it's quite hard for me to provide you with any kind of relevant models, because my models database consists from customers' models and we've signed do not share them further... The only thing I can do: I can extract 1,2 failing faces from models. But such analysis will take time...

So, how is it better to proceed further on your opinion? Should I just provide you with the unified diff? Or do you want me first to merge as much as possible with creating child tickets and the rest give you as unified diff?

oan (developer)
2014-08-08 19:39
edited on: 2014-08-09 01:36

Hello, Dima,

Concerning identification of changes in general, I have an idea: we can try to create a new branch with your changes relatively tag V6_0_0 (commit hash b9d558fc5725ee3ac272e8cb3ec90fb83a4d9e6e), not the current master. Like this, we can eliminate stratification of changes made since that version and retrieve actual modifications. So, I suppose that there is no necessity to prepare a unified diff.

If I get you right, you did not use some source control software on your workstation to track changes related to particular problem. If I am wrong, it would be nice if you provided a set of diffs with changes implementing some functionality in context of a single problem. If not, it would be quite helpful if you prepared some small description for the cases you fixed. On the other hand, test models contain such description in itself.

As for the test cases, it would be even more suitable if you provided only problematic parts of models. I suppose that you have accumulated an extensive database and extraction of problematic cases can take a lot of time, so I would suggest to automate this process using Draw. For instance in the following way:

pload ALL
set name <some_model>

#in case of BREP file
restore $name a

# in case of STEP files the code might be the following:
stepread $name a *
renamevar a_1 a

tclean a

set faces [explode a f]
set nb [llength $faces]
for {set i 1} {$i <= $nb} {incr i} {
  set info [incmesh a_$i 10]
  # deflection can be set to another value

  set status [lindex $info 6]
  if { [string compare $status "NoError"] != 0 } {
    save a_$i ${name}_face${i}.brep
Best regards,

drazmyslovich (developer)
2014-08-11 16:05

Hello, Oleg,

Thanks for a tip to fast extracting the faces, this will definitely help me!

We use SVN on our side for source controlling, but unfortunately due to bad internal repository policy I wasn't allowed to commit each change with the proper messages, therefore my svn log messages won't help at all.

But I'll embed the comments with some problem descriptions to all my changes.

Finally, regarding the merging of my changes, I think, that the most effective way will be the following:
1. I'll try and merge as much as it's possible with the current master, because some my modifications aren't overlapping with the general 6.7.0 changes. I'll check how does it improve the result mesh and commit all these changes.
2. I guess, that the rest of my changes are the changes, which are already integrated in the current master, but due to the big number of modifications in 6.7.0 code base, aren't recognizable any more.

I hope, this way will comfort you as well.

drazmyslovich (developer)
2014-08-12 15:11
edited on: 2014-08-12 15:11

Hello, Oleg,

I'm currently busy with merging my code with the current BRepMesh master and found very strange modification of the code. Could you please verify if it's done correctly:
6.6.0 code base BRepMesh_Vertex.cxx: Line 65
Standard_Boolean BRepMesh_Vertex::IsEqual(const BRepMesh_Vertex& Other)const
  if (myMovability!=BRepMesh_Deleted && Other.myMovability!=BRepMesh_Deleted)
    return (myUV.IsEqual(Other.myUV, Precision::PConfusion()));
  return Standard_False;

Current master BRepMesh_Vertex.hxx: Line 111
  Standard_EXPORT Standard_Boolean IsEqual(const BRepMesh_Vertex& theOther) const
    if (myMovability != BRepMesh_Deleted ||
        theOther.myMovability != BRepMesh_Deleted)
      return Standard_False;

    return (myUV.IsEqual(theOther.myUV, Precision::PConfusion()));

The functionality of IsEqual is completely inverted... Is it correct?

oan (developer)
2014-08-12 15:49

Hello, Dima!

Your observation is valid. It is disappointing misprint and I will correct it in context of 0023106.

Fortunately there is no code block or data collection in BRepMesh using this method explicitly or implicitly, therefore it has not led to any regression.

Thank you for attentiveness.
git (administrator)
2014-08-12 20:16

Branch CR25044_1 has been created by drazmyslovich.

SHA-1: 2d13f2972dfe99d1a8ce9daac438b10b88a90c09

This branch includes the following new commits:

       new 2d13f29 0025044: The merged version of BRepMesh tweaks

Detailed log of new commits:

commit 2d13f2972dfe99d1a8ce9daac438b10b88a90c09
Author: razmyslovich
Date: Tue Aug 12 18:16:03 2014 +0200

    0025044: The merged version of BRepMesh tweaks
drazmyslovich (developer)
2014-08-12 20:24

Oleg, I've just committed the merged version of my tweaks. Please, review them. I'll attach tomorrow the relevant models/faces.
drazmyslovich (developer)
2014-08-13 13:00

Due to the big size of the model, I just provide the link, where it can be free downloaded [^]
drazmyslovich (developer)
2014-08-13 19:48

Oleg, I've uploaded 58 faces from my models database, which can't be meshed by the current master mesh code, but can be meshed after applying my modifications (including the faces from the models I uploaded earlier today)
I would like to point, that the file contains only the faces, which are effected by my modifications; I still have other 143 faces, which can't be meshed even with my modifications.
I hope this data helps you.
msv (developer)
2018-11-02 17:49

Dear Dmitry, please check the bug state after integration of the fix for 0026106.
oan (developer)
2018-11-16 22:53
edited on: 2018-11-17 23:12

About half of problematic faces from attached archive are successfully meshed using current master (actually, next week integration branch).

Another half seems similar to 0025588, i.e. faces with open wires where gap is covered by tolerance. These ones should result in closed discrete contours of null area formed by two straight links causing error of meshing algorithm.

Model "2.stp" from the archive 0025588 is meshed without errors according to tricheck command.

Model "Checking Fixture Clamping.STEP" contains several invalid faces according to checkshape report. However, all faces contain triangulation either correct or partially corrupted.

Meshing was performed implicitly by calling vdisplay command.

oan (developer)
2018-11-17 23:05

Correction, all faces from the archive can be meshed using more fair angular tolerance producing several points along the border edges via

incmesh a 0.1 -a 5
git (administrator)
2019-08-07 10:22

Branch CR25044_2 has been created by drazmyslovich.

SHA-1: ebfd9b54b6c0b08e23b6139d54ee7ecd09735383

Detailed log of new commits:

Author: build
Date: Wed Aug 7 09:20:07 2019 +0200

    0025044: Improve the meshing results for tiny faces - use smaller UV deflection threshold; recognize a small face with 1 wire and 2 small edges as a face for refinement; frontier edges with no connections should never be removed; improve frontierAdjust function to detect all possible intersections; fix the recognition of glued edges in GeomTool
drazmyslovich (developer)
2019-08-07 10:30
edited on: 2019-08-07 10:32

Hello, Oleg,

I ported my changes for BRepMesh module to the current 7.4.0 master. Surely, most of the issues were fixed after your refactoring of the module. Still, the cases with tiny faces are not handled properly.

As an example model I used the bicycle from grabCAD [^] I attach it also to the ticket. Before my changes 7 faces are left without mesh; with my changes 4 faces are left without mesh

Please, review the changes committed to the branch CR25044_2
Thank you very much


git (administrator)
2019-08-07 13:15

Branch CR25044_2 has been updated by oan.

SHA-1: db734ec401ab49847094441bdb5ebc180dc36d9f

Detailed log of new commits:

Author: oan
Date: Wed Aug 7 13:13:23 2019 +0300

    # Minor code corrections

kgv (developer)
2019-08-07 13:42
edited on: 2019-08-07 13:42

build <>

Are you sure your git settings are correct?
You've used "razmyslovich" instead of "build" in previous patches.

drazmyslovich (developer)
2019-08-07 14:08
edited on: 2019-08-07 14:08

You are right, sorry - my computer was exchange recently...
I fixed it.

oan (developer)
2019-08-08 11:14

Test reports are available at (unfortunately, only internally):
http://occt-tests/CR25044_2-master-OAN-OCCT/Windows-64-VC14/summary.html [^]
http://occt-tests/CR25044_2-master-OAN-OCCT/Debian80-64/diff_summary.html [^]

Test results are the following:

Significant improvements:
bugs mesh bug25827
mesh standard O5
mesh standard U7
mesh standard V7
mesh standard W4
mesh standard V4

bugs mesh bug25307 (no free links)
bugs mesh bug25738 (no free nodes)

bugs moddata_2 bug22746_3
bugs modalg_2 bug21060

bugs mesh bug28500 (minor, changed status)
bugs vis bug22849 (minor, changed status)

mesh standard C7 (free links)
mesh standard P8 (free nodes)
mesh standard R2 (free nodes)
mesh standard U5 (free nodes)
mesh standard X2 (free nodes)
mesh standard W5 (face without triangulation)

bugs mesh bug25586_3 (face without triangulation)
bugs moddata_1 bug22761 (missed triangulation on some faces)
mesh standard B5 (incorrect triangulation near the hole)

bugs vis bug21578 (difference in visualization)
bugs mesh bug24594 (difference in visualization)
bugs mesh bug24593_1 (difference in visualization)
bugs mesh bug24593_2 (difference in visualization)
bugs modalg_2 bug20827 (difference in visualization)

bugs modalg_6 bug26701 (incorrect insertion of frontier links!)
bugs modalg_2 bug22830 (incorrect insertion of frontier links!)

bugs modalg_6 bug26130 (exception, division by zero?)

Unstable behaviour (without relation to changes):
de iges_3 A7
de step_2 C2
de step_2 F2
de step_2 U7
de step_4 C1
de step_4 H7
heal surface_to_revolution_advanced ZE8
offset shape_type_i_c XK4
offset shape_type_i_c XK7
offset shape_type_i_c XL8
offset shape_type_i_c ZL5

Other changes are just changed number of nodes and triangles in mesh.
oan (developer)
2019-08-08 11:27

Dear Dima,

Unfortunately, patch in its current state leads to some regressions, so it cannot be integrated as is.

I suppose that these regressions could be the result of changes in BRepMesh_Delaun class.

For instance:
bugs modalg_6 bug26701
bugs modalg_2 bug22830

Could you please give some hints about new functionality in this particular tool.
Will the fix for tiny faces work without these changes?

Probably, results would be different if we try to exclude modifications of BRepMesh_Delaun and check functionality that handles tiny faces in BRepMesh_ModelHealer only.

What do you think about it?

P.S.: I am not sure that shapes from the report above can be shared to resolve remaining problems, but I can figure it out.

Best regards,
git (administrator)
2019-08-15 14:00

Branch CR25044_2 has been updated by drazmyslovich.

SHA-1: 835c9803fcfd9f961b673912e2c977142c162f78

Detailed log of new commits:

Author: drazmyslovich
Date: Thu Aug 15 12:58:15 2019 +0200

    Merge branch 'CR25044_2' of into CR25044_2

Author: drazmyslovich
Date: Thu Aug 15 12:53:11 2019 +0200

    0025044: Revert the unrelated changes

drazmyslovich (developer)
2019-08-15 14:01

Dear Oleg,

I have tried to exclude the changes in BRepMesh_Delaun and run tests on my side with out models database. And I would agree, that these part of the changes can be excluded.

The changes in BRepMesh_Delaun are related to more sophisticated checks of face boundaries, particularly I have added a check for triangles, which intersect the boundary edges (frontier). These changes still improve the mesh results in some cases, but also introduce some regressions, therefore let's exclude them for now and as soon as I found some critical faces, which need this logic, I will propose the refined changes for BRepMesh_Delaun in a separate ticket.

Still, the changes for tiny faces are located not only in BRepMesh_ModelHealer but also in BRepMesh_DefaultRangeSplitter. As tiny faces can have UV sizes smaller as default deflection UV, it's necessary to consider UV sizes for tolerance values.

I reverted all other changes in CR25044_2 branch. Could you please try again to run your tests?

Thank you.

git (administrator)
2019-08-15 18:18

Branch CR25044_master has been created by oan.

SHA-1: 578436a8d8cb44482eb32dc125ccfbf1e81135c7

Detailed log of new commits:

Author: drazmyslovich
Date: Thu Aug 15 18:13:43 2019 +0300

    0025044: Revert the unrelated changes

Author: build
Date: Wed Aug 7 09:20:07 2019 +0200

    0025044: Improve the meshing results for tiny faces - use smaller UV deflection threshold; recognize a small face with 1 wire and 2 small edges as a face for refinement; frontier edges with no connections should never be removed; improve frontierAdjust function to detect all possible intersections; fix the recognition of glued edges in GeomTool
oan (developer)
2019-08-16 11:51


Here are the testing results for the updated patch:
http://occt-tests/CR25044_master-master-OAN-OCCT/Windows-64-VC14/diff_summary.html [^]
http://occt-tests/CR25044_master-master-OAN-OCCT/Debian80-64/diff_summary.html [^]

Generally, they are OK, except "mesh standard P8" where a single free node has appeared.

I suppose, the difference in behaviour is caused by amplification of an edge containing plain loop in 2D that can be considered as self-intersecting in context of applied patch (however, no status is returned for this particular use case). There is an additional discretization point on the loop causing "free node" status.

So, personally I do not consider it as a regression, but the result of edge discretization algorithm with specific parameters.

Please make decision about patch integration or possibility of sharing the reference shape from "mesh standard P8" test publicly.

Improvements (absence of cross-face errors and faces without triangulation):
bugs mesh bug25827
mesh advanced B2
mesh advanced B3
mesh advanced B7
mesh advanced_shading A7
mesh standard H5
mesh standard O5

Changed statuses (additional self-intersecting status):
bugs mesh bug28500
bugs vis bug22849

Changed number of triangles:
bugs iges buc60823
bugs iges bug306
bugs mesh bug23513
bugs mesh bug29149
bugs mesh bug29962
bugs moddata_1 bug15519
bugs moddata_1 bug22759
bugs moddata_2 bug258_1
bugs moddata_2 bug428
git (administrator)
2019-08-17 21:43

Branch CR25044_test1 has been created by abv.

SHA-1: 3ad1d7884e6f4757178471c5fd4de039abcb7038

Detailed log of new commits:

Author: drazmyslovich
Date: Wed Aug 7 10:20:07 2019 +0300

    0025044: BRepMesh tweaks - degenerated faces
    BRepMesh+ModelHealer - recognize a small face with 1 wire and 2 small edges as a face for refinement
git (administrator)
2019-08-17 22:26

Branch CR25044_test1 has been updated forcibly by abv.

SHA-1: 9736cc087bfd672ea54aa716ef58f1ca1230b563
abv (manager)
2019-08-18 09:28

Oleg, we need to add faces provided by Dmitry to the test database, and add relevant tests, this shall allow us to verify the change and see improvements and not only regressions.

I observe that the final version of the branch effectively contains two changes only:
- detection of degenerated faces in BRepMesh_ModelHealer.cxx
- decrease of working tolerance in BRepMesh_DefaultRangeSplitter.cxx

I have created separate branch CR25044_test1 for the first one, to test it separately.
The results of tests are:

Changed statuses (additional self-intersecting status):
bugs mesh bug28500
bugs vis bug22849

mesh advanced_shading A7
mesh standard_incmesh O5
mesh standard_incmesh_parallel O5
mesh standard_shading O5

Visual differences look like improvements (eliminated meshing artifacts) on several cases:
advanced_shading A7
bugs xde bug23969
bugs iges bug22487_1
bugs step bug30628

However, on one test it looks like regression (small gap in the object)
bugs modalg_4 bug697_4

Thus this change overall looks like improvement, however to complete it we need to update tests accordingly, and check more carefully the bug697_4 to verify that it is not regression.
git (administrator)
2019-08-18 09:49

Branch CR25044_test2 has been created by abv.

SHA-1: 0b8afacfd67203c8793800ecf4c8f5590ed4e799

Detailed log of new commits:

Author: abv
Date: Sun Aug 18 09:46:38 2019 +0300

    0025044: BRepMesh tweaks - Improve the meshing results for tiny faces
    Use smaller UV deflection threshold
git (administrator)
2019-08-18 10:02

Branch CR25044_test2 has been updated forcibly by abv.

SHA-1: 3c0f0e0a3379b2aa1389794812c8e64033168f4d
git (administrator)
2019-08-18 14:16

Branch CR25044_test2 has been updated forcibly by abv.

SHA-1: 1fbd74da4015b24a7a349ab45a45d27624e71fa7
abv (manager)
2019-08-18 14:16

Branch CR25044_test2 is made for testing change in DefaultSplitter.

That change causes regression on test mesh standard_incmesh P8, due to tolerance decreasing from 1e-5 to 1e-6 on line .

First I tried it in variant without changing 1e-5 to 1e-6. The result is: no regressions reported, visual improvements (no green wireframe artifacts) on two tests:

bugs iges bug22394
bugs step bug5708
git (administrator)
2019-08-18 14:27

Branch CR25044_test2 has been updated forcibly by abv.

SHA-1: 14f8de043523bc58fb055edd28553c7e796c4c58

- Issue History
Date Modified Username Field Change
2014-07-01 14:23 drazmyslovich New Issue
2014-07-01 14:23 drazmyslovich Assigned To => oan
2014-07-01 14:26 drazmyslovich Note Added: 0029934
2014-07-01 14:26 drazmyslovich Status new => resolved
2014-07-01 14:27 drazmyslovich Relationship added related to 0024923
2014-07-01 14:27 drazmyslovich Additional Information Updated View Revisions
2014-07-30 18:22 oan Note Added: 0030496
2014-07-30 18:22 oan Assigned To oan => drazmyslovich
2014-07-30 18:22 oan Status resolved => feedback
2014-07-30 18:33 oan Relationship added parent of 0025113
2014-08-04 15:58 drazmyslovich Note Added: 0030559
2014-08-04 15:58 drazmyslovich Assigned To drazmyslovich => oan
2014-08-05 19:29 abv Target Version => 6.8.0
2014-08-08 19:39 oan Note Added: 0030642
2014-08-08 19:39 oan Assigned To oan => drazmyslovich
2014-08-09 01:36 oan Note Edited: 0030642 View Revisions
2014-08-11 16:05 drazmyslovich Note Added: 0030657
2014-08-12 15:11 drazmyslovich Note Added: 0030682
2014-08-12 15:11 drazmyslovich Note Edited: 0030682 View Revisions
2014-08-12 15:15 drazmyslovich Assigned To drazmyslovich => oan
2014-08-12 15:49 oan Note Added: 0030684
2014-08-12 15:49 oan Assigned To oan => drazmyslovich
2014-08-12 20:16 git Note Added: 0030691
2014-08-12 20:24 drazmyslovich Note Added: 0030694
2014-08-12 20:24 drazmyslovich Assigned To drazmyslovich => oan
2014-08-12 20:24 drazmyslovich Status feedback => resolved
2014-08-13 13:00 drazmyslovich File Added: Checking Fixture Clamping.STEP
2014-08-13 13:00 drazmyslovich Note Added: 0030712
2014-08-13 19:43 drazmyslovich File Added:
2014-08-13 19:48 drazmyslovich Note Added: 0030729
2014-10-16 13:26 oan Target Version 6.8.0 => 7.1.0
2016-10-25 17:39 oan Target Version 7.1.0 => 7.2.0
2017-07-20 12:43 oan Target Version 7.2.0 => 7.3.0
2018-02-25 21:09 abv Target Version 7.3.0 => 7.4.0*
2018-11-02 17:49 msv Note Added: 0080651
2018-11-02 17:49 msv Assigned To oan => drazmyslovich
2018-11-02 17:49 msv Status resolved => feedback
2018-11-16 22:31 oan Relationship added related to 0025061
2018-11-16 22:53 oan Note Added: 0081132
2018-11-17 23:05 oan Note Added: 0081136
2018-11-17 23:12 oan Note Edited: 0081132 View Revisions
2019-08-07 10:22 git Note Added: 0086046
2019-08-07 10:30 drazmyslovich Note Added: 0086047
2019-08-07 10:30 drazmyslovich Assigned To drazmyslovich => oan
2019-08-07 10:30 drazmyslovich Status feedback => resolved
2019-08-07 10:30 drazmyslovich Steps to Reproduce Updated View Revisions
2019-08-07 10:31 drazmyslovich File Added: Median cx-fs01 bicycle ( kerékpár ).zip
2019-08-07 10:32 drazmyslovich Note Edited: 0086047 View Revisions
2019-08-07 13:15 git Note Added: 0086055
2019-08-07 13:42 kgv Note Added: 0086057
2019-08-07 13:42 kgv Note Edited: 0086057 View Revisions
2019-08-07 14:08 drazmyslovich Note Added: 0086060
2019-08-07 14:08 drazmyslovich Note Edited: 0086060 View Revisions
2019-08-08 11:14 oan Note Added: 0086084
2019-08-08 11:27 oan Note Added: 0086085
2019-08-08 11:27 oan Assigned To oan => drazmyslovich
2019-08-08 11:27 oan Status resolved => assigned
2019-08-15 14:00 git Note Added: 0086260
2019-08-15 14:01 drazmyslovich Note Added: 0086261
2019-08-15 14:02 drazmyslovich Assigned To drazmyslovich => oan
2019-08-15 14:02 drazmyslovich Status assigned => resolved
2019-08-15 18:18 git Note Added: 0086268
2019-08-16 11:51 oan Note Added: 0086271
2019-08-16 11:51 oan Assigned To oan => abv
2019-08-17 21:43 git Note Added: 0086315
2019-08-17 22:26 git Note Added: 0086316
2019-08-18 09:28 abv Note Added: 0086317
2019-08-18 09:49 git Note Added: 0086318
2019-08-18 10:02 git Note Added: 0086319
2019-08-18 14:16 git Note Added: 0086320
2019-08-18 14:16 abv Note Added: 0086321
2019-08-18 14:27 git Note Added: 0086322

Copyright © 2000 - 2019 MantisBT Team
Powered by Mantis Bugtracker