archi-modelrepository-plugin icon indicating copy to clipboard operation
archi-modelrepository-plugin copied to clipboard

[BUG] Archi 4.7 Saving - Connection Relationship Errors

Open reed155 opened this issue 4 years ago • 20 comments

archi4_7Error.docx

Version of Archi

4.7 Early Access

Archi Plug-ins

Archi Excel Plugin Archi Scripting Lightbox

Operating System

Windows 10

Expected Behaviour

Should save without error as in 4.6

Actual Behaviour

Does not Save, presents an error.

Steps to Reproduce the Behaviour

  1. Edit model
  2. Attempt to Save

Please contact me privately of the error log if needed.

reed155 avatar Apr 13 '20 19:04 reed155

This suggests that somehow the connection does not have the correct relationship. Does it open and save OK in Archi 4.6? Try deleting the connection and re-adding a new one.

Phillipus avatar Apr 13 '20 19:04 Phillipus

Archi 4.7 has more error reporting for cases like this, so the bad connection may still be there in 4.6 but just not have an error message. The only way I can be sure is to have a copy of the model file.

Phillipus avatar Apr 13 '20 19:04 Phillipus

It opens and saves fine in 4.6. I may be able to share a copy of the file privately with some anonymization. Please let me know how to share it with you directly.

reed155 avatar Apr 13 '20 19:04 reed155

Please email it to info at archimatetool.com

Phillipus avatar Apr 13 '20 19:04 Phillipus

FWIW, one colleague very recently had the same issue. After some investigation, the issue was already there at the first time, but Archi 4.6 was not able to detect it. Archi 4.7 as able and raised the message. I had to manually fix the .archimate file.

@reed155 Do you use coArchi, the collaboration plugin, with this model ? If yes, did you also used some jArchi script to change the type of some objects ?

jbsarrodie avatar Apr 13 '20 20:04 jbsarrodie

...but Archi 4.6 was not able to detect it. Archi 4.7 as able and raised the message.

@jbsarrodie That's correct, because 4.7's ModelChecker now checks that a connection's source and target diagram objects match the connection's relationship's source and target elements. This will not raise an error in 4.6. The cause could lie elsewhere - in jArchi perhaps.

Phillipus avatar Apr 13 '20 20:04 Phillipus

This will not raise an error in 4.6. The cause could lie elsewhere - in jArchi perhaps.

I suspect a model corruption after a successful git merge:

  • two users work on a model which contains (between others) a relationship R from A to B
  • User A creates a new view V using R, then publish
  • User B changes R so that it now goes from A to C, then publish
  • Result is a model in which a view V exists with a connection from A to B, this connection is related to relationship R which is between A and C !

I once thought about this edge case but then forgot about it. I think we should make sure when reloading the model that all connections are in sync with underlying relationship, and if not simply update (if new source and/or target are still on the same view) or delete them.

jbsarrodie avatar Apr 13 '20 20:04 jbsarrodie

@jbsarrodie We should track this case on the coArchi issue tracker. But @reed155 has not listed coArchi in his list of plug-ins, so maybe not the case here?

Phillipus avatar Apr 13 '20 20:04 Phillipus

The model I derived my test model from leveraged the coArchi Plugin (Archi 4.6). And the case that @jbsarrodie mentioned seems like it very well could have happened. We have many users that merge to the same model using CoArchi.

reed155 avatar Apr 13 '20 20:04 reed155

FWIW, I did not use jArchi to change object types on this model.

reed155 avatar Apr 13 '20 20:04 reed155

OK, thanks for the info. I've transferred this issue to the coArchi issue tracker under the assumption that this is the cause. This way we can investigate a solution based on @jbsarrodie comments:

I think we should make sure when reloading the model that all connections are in sync with underlying relationship, and if not simply update (if new source and/or target are still on the same view) or delete them.

Phillipus avatar Apr 13 '20 20:04 Phillipus

@reed155 But send me your model if you like so I can attempt a manual fix.

Phillipus avatar Apr 13 '20 20:04 Phillipus

Hi,

I'm receiving the same error with very similar circumstances: Archi 4.6, coArchi, team of about 20 people using the model, branching, jArchi, and then towards the end of a merge process I get the missing folder.xml error message. When I loaded the model in 4.7, I started receiving the error indicated by @reed155. If I can provide any additional info or support, please let me know.

Michael

michaelansley avatar Jun 26 '20 10:06 michaelansley

PS: All of the team are using coArchi 7.2, although I have just (today) installed coArchi 0.8. It was with Archi 4.7/coArchi 0.8 that I received the error as indicated by @reed155.

michaelansley avatar Jun 26 '20 10:06 michaelansley

Michael, I think you are referring to jArchi. coArchi is on version 0.6.2. jArchi won't have any bearing on this issue. What error messages are you seeing?

Phillipus avatar Jun 26 '20 10:06 Phillipus

@michaelansley

I get the missing folder.xml error message

What you experience is not related to this issue but this one #130 (I suggest you read it carefully to understand the issue and its potential impacts with coArchi <0.6.2. The root cause is some views that have been both moved and notably updated by different people, leading Git to no more see the underlying view XML files as been the same. For the moment there is no real automatic solution. You have to find which views have been moved (the conflict dialog can help you in this) and then manually undo the move (which supposes that you still have the original folder in you model as it is identified by its internal ID, not its name). Once the move has been undo, you'll be able to merge your changes and publish them. You'll then be able to redo the move after.

I started receiving the error indicated by @reed155

This one is related to this issue (and may or may not be related to coArchi btw). @Phillipus devised a small jArchi script to fix it:

$('view').find('relationship').each(function(connection) {
    var relation = connection.concept;
    var relationSource = relation.source;
    var relationTarget = relation.target;
    var connectionSource = connection.source.concept;
    var connectionTarget = connection.target.concept;
    if(connectionSource.id != relationSource.id || connectionTarget.id != relationTarget.id) {
        connection.delete();
    }
});

This script will find nonvalid visual connection and remove them.

jbsarrodie avatar Jun 26 '20 11:06 jbsarrodie

This one is related to this issue (and may or may not be related to coArchi btw).

I wonder what else might cause this? Could there be an edge case bug in reconnecting connections, for example?

Phillipus avatar Jun 26 '20 11:06 Phillipus

I wonder what else might cause this? Could there be an edge case bug in reconnecting connections, for example?

TBH I do think this is caused by coArchi (as I can easily imagine a sequence of actions leading to this) but maybe there are some edge cases in jArchi (less likely though).

jbsarrodie avatar Jun 26 '20 11:06 jbsarrodie

@Phillipus, of course, the 0.8 that I was referring to was jArchi, not coArchi, I mixed them up. You are correct, I am using coArchi 0.6.2.

@jbsarrodie, thanks a lot for the info and the script reference. I will check it and get back with info.

Have a great weekend!

michaelansley avatar Jun 26 '20 15:06 michaelansley

Hello, I have the same issue (Please see the #143). I want to apply the script to fix the issue. Can you give me the access to JArchi Script to launch the script?

Best regards

arnaudsp avatar Aug 12 '20 11:08 arnaudsp