Bug Report: Import of Macro Creates New Macro Group

[JMichaelTX]

Bug Report: Import of Macro Creates New Macro Group

Running Keyboard Maestro 9.0.2 on macOS 10.14.5 (Mojave)

When a Macro, previously exported, is imported it always creates a NEW Macro Group by the same name, even though the MG exists.

Steps to Reproduce:

1. Export a macro
2. Delete the macro
3. Change the properties of the Macro Group it was in (like change app availability)
4. Import the Macro
5. Observe that it puts the Macro into a NEW MG by the same name as the MG when it was exported, and still exists.

And what is worse, it does this without ANY warning or notice.

From: How to Import Macros -- KM Wiki

Note that the macro file ( .kmmacros ) may contain one or more macros, and will also create the Macro Group if it does not exist in your configuration. Otherwise, it will ==put the Macro in your existing Macro Group==.

Expected Behavior

1. If the MG exists, and has not changed, then the macro will be restored to the same MG.
2. If the MG has changed, ask the user whether to import into existing MG, or new MG. If new MG, a version# should be appended, like when pasting an existing file with the Finder.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

EDIT: 2019-09-12 18:14 GMT-5

The above is for a simple use case of where the KM export file contains only one macro, or in the worst case, one Macro Group with a number of its macros.

So, the question is, how should it be handled if the KM export file contains multiple Macro Groups, with regard to asking the user? My suggestion is to follow the behavior of the Finder: Ask the user for the first case, and then ask whether to apply that decision to all cases, or ask on each case.

The most important thing is to change the current behavior where a new Macro Group, or even a new Macro, is created when they already exist, and this is done silently without any warning or notification. If dups are created, at the bare minimum the user should be notified, and a version# added as a suffix to the name.

[JMichaelTX]

Here's a related issue:
Multiple groups when importing macro group into KM9 -- @rcraighead

[NaOH]

@JMichaelTX

• If the MG exists, and has not changed, then the macro will be restored to the same MG.
• If the MG has changed, ask the user whether to import into existing MG, or new MG. If new MG, a version# should be appended, like when pasting an existing file with the Finder.

The first option here seems potentially problematic for macros shared between users. For example, one user here shares a macro from a Safari group, but the sharing user's version of that group could have different criteria than a group of the same name for a macro-importing user.

Seems like the overall safest option would be to prompt users on import to which group they'd like to assign macros. Just by prompting users for where to assign macros, a bunch of clarity is ensured. Certainly, if there are also macros with the same names in that existing group, something like the Finder-style prompt could be presented.

[JMichaelTX]

@NaOH

The first option here seems potentially problematic for macros shared between users. For example, one user here shares a macro from a Safari group, but the sharing user's version of that group could have different criteria than a group of the same name for a macro-importing use

KM uses a UUID to uniquely identify both Macros and Macro Groups.
So if User 1 exports Macro "A" from Macro Group "MG1", then when User 2 imports that macro it will create a NEW Macro Group named "MG1" even though User 2 has a Macro Group "MG1" because the UUIDs of the two groups are different.

@NaOH

Seems like the overall safest option would be to prompt users on import to which group they'd like to assign macros. Just by prompting users for where to assign macros, a bunch of clarity is ensured.

I generally agree. However, if the MG UUID for a given macro in the macro import file matches the UUID of an existing MG, then it does make sense to import the macro into that group. However, it would still be useful for KM to notify the user of the action it plans to take, and offer options.

For example:

Please choose which Macro Group you would like to import the Macro "Open URL in Safari" into:

1. Existing Macro Group "Safari" that has the same Macro Group UUID
2. Existing Macro Group "Safari" that has a different UUID.
3. Another existing Macro Group (prompt for name)
4. NEW Macro Group? (prompt for name)

︎ Check to apply to all macros in import file

Default Answer: 1 (Existing with same UUID)

[NaOH]

I didn't know about the UUIDs for Macros and for Macro Groups. Makes a big difference with those in place.

The key, I think, is as you noted:

@JMichaelTX

However, it would still be useful for KM to notify the user of the action it plans to take, and offer options.

If something along those lines were introduced, I think it would be beneficial if the dialog box presents an option for creating a new Macro Group, akin to how Open/Save dialogs include an option to create a new folder.

[peternlewis]

This is not a bug. It is working as designed - if the macro group has different properties, then a new macro group is created. Only the macro name and properties match will it be added to the existing macro group.

@JMichaelTX

The most important thing is to change the current behavior where a new Macro Group, or even a new Macro, is created when they already exist, and this is done silently without any warning or notification.

Its not done without notification - you ask to import the macros, and they are imported. Macros and Macro Groups are created as necessary.

@JMichaelTX

The most important thing is to change the current behavior where a new Macro Group, or even a new Macro, is created when they already exist, and this is done silently without any warning or notification. If dups are created, at the bare minimum the user should be notified, and a version# added as a suffix to the name.

Wether an existing matching macro exists or not does not affect importing - importing imports the macros, creating new ones. They may have the same name as existing macros, macro groups may have the same name as existing macro groups. Keyboard Maestro does not care - there is no requirement for macros or macro groups to have unique names.

@JMichaelTX

Here's a related issue:
Multiple groups when importing macro group into KM9 -- @rcraighead

No, that is an unrelated bug in 9.0-9.0.1.

@JMichaelTX

I generally agree. However, if the MG UUID for a given macro in the macro import file matches the UUID of an existing MG, then it does make sense to import the macro into that group.

Not necessarily. You have changed the properties of the macro group deliberately, so who knows what or why, or wether the previously exported macro with its macro group and properties is now compatible with your intentions.

I am not going to add a prompt asking what you want to do with macros in macros groups that might exist but have different properties - if they have different names or different properties, they are not the same macro group any more, so they get a new macro group. If you want them in the original macro group, then you will need to move them manually, which is negligibly more effort than dealing with a confusing prompt anyway.

[JMichaelTX]

Request (TLDR;)

So, the point of all this is that many of us, or maybe just me, expect that when I import a Macro, and the UUID of its Macro Group, in the import file, is the same as the UUID of an existing Macro Group in my system, then the Macro will be imported into the ==existing Macro Group==.

It would greatly help us to manage a manual backup/restore of individual Macros if you would change the Macro Import behavior to work like this.

Discussion

@peternlewis

This is not a bug. It is working as designed

Then, with all due respect, I submit the design leaves much to be desired, and produces unexpected, counter-intuitive results.

I'm sure you will disagree with this, but you might consider the behavior from the perspective of a relatively new KM user, who did NOT design KM, and from experienced users who have used many backup/restore systems.

@peternlewis

If the macro group has different properties, then a new macro group is created. Only [if] the macro name and properties match will it be added to the existing macro group.

Again, this is counter-intuitive, and is inconsistent with every backup/restore and copy/paste of files and folders that I have used. Basically, I expect a KM macro import to work the same as the Finder does when inserting (pasting) a file into an existing folder. Or like Time Machine, if it restores a file, it will put it in the existing folder, even if that folder's permissions have changed. If the file already exists in the folder, it will prompt me to overwrite or create a new file.

And, your statement does not follow the KM Wiki description:

How To Import Macros -- KM Wiki

Note that the macro file ( .kmmacros ) may contain one or more macros, and will also create the Macro Group if it does not exist in your configuration. Otherwise, ==it will put the Macro in your existing Macro Group==.

From the Wiki and numerous discussions in the Forum, we have been led to believe that the UUID is the identifier for both Macros and Macro Groups.

In fact, the Wiki Glossary defines "UUID" as:

a Universally Unique IDentifier for Macros and Macro Groups and other purposes that remains the same ==even if you rename or modify a macro or macro group==, or import a Macro built on another Mac.

@peternlewis

Its not done without notification - you ask to import the macros, and they are imported. Macros and Macro Groups are created as necessary.

That is a very strange, non-standard definition of "notification".

When the KM Import process creates a NEW Macro Group with the SAME exact name as an existing Macro Group, it does not bother to tell me this (i.e. notify me of its unexpected action). So, it is not immediately obvious that a NEW Macro Group has been created. Surely you can understand this.

@peternlewis

If you want them in the original macro group, then you will need to move them manually, which is negligibly more effort than dealing with a confusing prompt anyway.

Wow! That is quite an outrageous assertion. I'm sure both of us, and many others, could design a very clear and helpful prompt. Clicking "Yes", "No", or "OK" is much, much easier and faster than manually moving macros.

Wrapup

Peter, I realize that what I am asking for is quite different from your design notions when you implemented the KM macro export/import processes. But please take a step back and examine this request on its merits, and ask yourself if most KM users would benefit from it.

I'm not expecting an immediate response, and certainly not an immediate change. But as I, and many other users accumulate many Macros (> 2,000) and many Macro Groups (> 150), the need to easily backup and restore individual Macros in an easy, consistent manner, grows every day.

Thanks for your consideration of this request.