-
Notifications
You must be signed in to change notification settings - Fork 53
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
Comments
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. |
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. |
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. |
Please email it to info at archimatetool.com |
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 That's correct, because 4.7's |
I suspect a model corruption after a successful git merge:
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 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? |
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. |
FWIW, I did not use jArchi to change object types on this model. |
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:
|
@reed155 But send me your model if you like so I can attempt a manual fix. |
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 |
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. |
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? |
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.
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. |
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). |
@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! |
Hello, I have the same issue (Please see the #143). Best regards |
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
Please contact me privately of the error log if needed.
The text was updated successfully, but these errors were encountered: