Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Archi 4.7 Saving - Connection Relationship Errors #136

Open
reed155 opened this issue Apr 13, 2020 · 20 comments
Open

[BUG] Archi 4.7 Saving - Connection Relationship Errors #136

reed155 opened this issue Apr 13, 2020 · 20 comments
Labels

Comments

@reed155
Copy link

reed155 commented Apr 13, 2020

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.

@Phillipus
Copy link
Member

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
Copy link
Member

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.

@reed155
Copy link
Author

reed155 commented Apr 13, 2020

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.

@Phillipus
Copy link
Member

Please email it to info at archimatetool.com

@jbsarrodie
Copy link
Member

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 ?

@Phillipus
Copy link
Member

...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.

@jbsarrodie
Copy link
Member

jbsarrodie commented Apr 13, 2020

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.

@Phillipus
Copy link
Member

@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?

@reed155
Copy link
Author

reed155 commented Apr 13, 2020

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
Copy link
Author

reed155 commented Apr 13, 2020

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

@Phillipus Phillipus transferred this issue from archimatetool/archi Apr 13, 2020
@Phillipus
Copy link
Member

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
Copy link
Member

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

@michaelansley
Copy link

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
Copy link

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.

@Phillipus
Copy link
Member

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?

@jbsarrodie
Copy link
Member

@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.

@Phillipus
Copy link
Member

Phillipus commented Jun 26, 2020

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?

@jbsarrodie
Copy link
Member

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).

@michaelansley
Copy link

@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!

@arnaudsp
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants