Last modified date with label expressions

[mjardemalm]

A nice additional feature for the already great function Label Expression would be to display the date of the last modification of a view or concept like $view{modifieddate}.   I have basic knowledge of how parts of Archi and coArchi works so i figure this would not be a straight forward implementation.   Is there a way to get Archi to hook up with events from a plugin? I guess this will require a more extensive implementation with at hook-editor and a set of pre-defined actions within Archi.   If a hook "Saved Object" are registered from coArchi and connected to a "Set Propery" action the existing label expressions will already cover the actual feature request.   Just a thought I’d like to share. The actual feature request would give me some great benefit. The thougths about a more generic solution just popped out of my head and could be totally ignored.

[Phillipus]

Thanks for sharing your idea.

But the first problem is that concepts and views don't register or fire a timestamp event when they are modified, whether that's in Archi or coArchi. Unless I misunderstand something?

[mjardemalm]

My initial thought was that since git is the backend, and every concept and view are individual files, git could be used to track changed concepts and views included in the commit.

”Saved Object” or ”modfified date” is then defined as the timestamp of the commit.

[mjardemalm]

But only the changed and added files will be commited? After a successful commit it should be possible to retrieve information about the commit and fire a hook for each "saved object".

[Phillipus]

I'll move this to coArchi...

This isn't something we're going to implenment in coArchi. In fact, coArchi 2 won't be using lots of XML files and will commit the whole *.archimate file.

[mjardemalm]

Oh! That will be a game changer. Then git probably won't be useful to get track of changes anymore. If not diff could extract changed parts of the whole *.archimate file.

[Phillipus]

We will implement a logical diff, not a textual diff. Git is still useful for everything else.

[mjardemalm]

Interesting. Then maybe the logical diff could be used to track changed concepts and views. I'll guess time will tell what coArchi 2 will offer. =)

[mjardemalm]

I couldn’t let this issue go without doing some research which ended up with a proof-of-concept to see what it takes to implement commit hooks in coArchi. It is quite costly for large models since the Grafico export must be made twice. The flow is

1. Save model
2. Export to Grafico
3. Identify changed and added files (if enabled)
4. Set properties for related items (if enabled)
5. Save model (if enabled)
6. Export to Grafico (if enabled)
7. Commit

where 3 and 4 are the new ones. The first export (2) must of course be made since it’s where the git repo is written and git is the source for identifying changed and added items (files). And since the new or updated properties will change the model the model needs to be saved (5) and exported (6) again before commit. In this proof-of-concept the ”hooks” and ”actions” are configurable globally in the Collaboration preferences tab and the original flow (1-2-7) is executed if no hooks are enabled.

I’ll attach a patch (format-patch) made from commit 627203c and a screenshot of the preferences page.

Commit hooks operates on every new or changed model item and could be combined with scripts that extract history from git (with bash or PowerShell) and written to existing model items (with jArchi). This should be made with commit hooks disabled since hooks will override changes made by the script.

Not heavily tested but used in production for about a week with a model currently containing 2027 elements, 3331 relationships and 202 views. Without hooks enabled the time between the click of the commit button and the commit dialog is between 5 and 6 seconds. With the hook enabled the time increases to 8-9 seconds. These tests was made with a Macbook Air 2013. With a Thinkpad T490 2019 tests without hooks takes about 7-8 seconds and with hooks 12-13 seconds.

Just wanted to share commit-hook.zip .

[jbsarrodie]

I couldn’t let this issue go without doing some research which ended up with a proof-of-concept to see what it takes to implement commit hooks in coArchi. It is quite costly for large models since the Grafico export must be made twice.

Interesting, thanks for sharing.

Another option that would work with coArchi 1 (but not with coArchi 2) is to "simply" add a contextual menu to elements inside the model tree that would do a git blame on the xml file associated with the concept and get the owner, date (and comment) of the most recent commit found. This would work without the need to actually change the model itself. That was how I was planning to implement this before we decide to move to coArchi 2 (which will require a completely different approach, yet to find).

[mjardemalm]

The blame option would give some great benefits. But my main use case is to display last committed date for views in notes ($view{property:Last committed}) and that won’t be possible with the blame approach if I understand your thoughts with execution from a contextual menu right.

From my understanding the blame approach is more related to the item history requested in #178? A bit OT then… But getting the item history from git in coArchi 1 wont be that hard but isn’t it a lot of work to trace changes for a single item when versioning the .archimate file?

[jbsarrodie]

But my main use case is to display last committed date for views in notes

In this case what would be needed is a way for a plugin to contribute new expressions (but in this case performances would be an issue)

From my understanding the blame approach is more related to the item history requested in #178? A bit OT then… But getting the item history from git in coArchi 1 wont be that hard

Yes, that's similar to this other issue.

but isn’t it a lot of work to trace changes for a single item when versioning the .archimate file?

For coArchi 2 we'll have to do it differently as blame won't be useful anymore. But as we'll do the diff/merge ourself, we'll be able to keep track of anything we want through metadata ("features" in Archi's implementation).

[mjardemalm]

In this case what would be needed is a way for a plugin to contribute new expressions (but in this case performances would be an issue)

I fully agree to this. And in fact, I felt that I just had to implement a proof-of-concept for this approach. A format-patch is attached, code is based on commit 627203c. It's a new renderer that responds to $prefex{commit:date|user}.

I've been running it for almost a week on the same fairly large model without experiencing any latency issues.   It is based on the naming convention used for new objects where the object identifier and the type of object is used for identfy the XML-file that hosts the versioned object on disk. The renderer applies for concepts, relationships and diagrams. Uncommited objects will show the label expression itself.   Valid prefixes are model, view, source, target, parent and all connection prefixes. The model prefix will read the last log entry for whole repository where the others will read the last log entry for the specific object.

commit-label-expression.patch.zip