Can anyone help me confirm this is a bug, or possibly just something I might be doing incorrectly? It may also be the lack of a feature I'm assuming exists.

The problem is that add-on preferences only seem to get auto-saved when they are not within a property group branch. To replicate it, set this simple scenario up. You may already have something close enough - the properties do not need to be Boolean.

class PrefsSub(bpy.types.PropertyGroup):
SkipTestB : bpy.props.BoolProperty( name = "Skip Test B" )

bl_idname = "PROJECT_NAME"
SkipTestA : bpy.props.BoolProperty( name = "Skip Test A" )
sub : bpy.props.PointerProperty(type=PrefsSub)

def draw(self,context):
area = self.layout.column()
area.prop(self, "SkipTestA")
area.prop(self.sub, "SkipTestB)

1. Open Blender and Add-on preferences, modify Skip Test A, then close/open Blender. The SkipTestA state should remain intact, indicating that the property was automatically saved.
2. Open Blender/prefs, modify Skip Test B, close/open Blender. If you encounter the same issue, the property does not get saved. Is this a bug?
3. If you open Blender/prefs, then modify Skip Test A and Skip Test B, then close/open Blender, both properties appear to be saved.

It seems as if the auto-save triggering feature breaks down on property groups. Is this a known issue? And are there any workarounds for it? If this does not normally happen, can anyone guess something I may be doing incorrectly to cause it?

Really appreciate any knowledge about this. I have my preferences setup to use multiple property groups because I didn't realize this happened until it was too late. I can probably flatten the hierarchy, but would prefer to not do that if possible.

Edit: Some info and possible solution

• Forcing a root preferences value (prefs.prop) to change when a property group value (prefs.group.prop) changes does not trigger an auto-save.
• In fact, programmatically altering root preference values does not seem to trigger an auto-save at all. Which would mean states stored in prefs won't get automatically saved unless the user modifies a root preference value using the UI within the same Blender session.
• When a root preferences value is modified by the user through the UI, Blender will save all add-on preferences on exit - even those in property groups.
• My current solution is to add update functions to all preference properties, and have the update function set bpy.context.preferences.use_preferences_save = True.
• The solution I'm going with at the moment is to set bpy.context.preferences.use_preferences_save = True when my add-on starts up. Read about this state here: https://docs.blender.org/api/current/bpy.types.Preferences.html?highlight=use_preferences_save#bpy.types.Preferences.use_preferences_save . According to documentation, setting this to True will trigger modified preferences to be saved on exit. In my opinion, it seems like this should always happen.
• If anyone can think of a better solution, please let me know! I personally do not like forcing this value to be True on every Blender execution, but it seems like the simplest solution. I guess the best solution would be to avoid property groups altogether in preferences, and to only trigger an auto-save when procedurally changing preference properties internally. But since my add-on does this every time it executes, it makes sense to do it the lazy way.
• Suggest if you want people to test this, then make the script a minimal working addon, with bl_info and registration. Haven't noticed this behaviour. – batFINGER Nov 10 '19 at 2:34
• Yeah, I wanted to do that, but I don't have enough experience to throw one together. I've only worked with Python/Blender through a single multi-file project that is too convoluted to use as a test. Plus I figured quite a few add-ons in development would already have a setup very similar to the one above. – Robert Nov 10 '19 at 14:08
• I think I've confirmed this is happening to at least several other people. While researching solutions, I keep running into posts about preferences not being saved correctly, and the poster has them in property groups. Example: devtalk.blender.org/t/… – Robert Nov 10 '19 at 15:57
• @Robert you can use the Templates menu in the script editor to scaffold an add-on, you don't need to know how to do it from scratch – Moog Nov 17 '19 at 1:39