new features added directly into a folder aren't visible until after toggling folder visibility

[caver456]

After this code sequence:

fid=sts.addFolder('newFolder')
sts.addMarker(39,-120,'newMarker',description='desc',color='#00FF00',symbol='fire',size=4,folderId=fid)
sts.addLine([[-120,39],[-120.1,39.1],[-120,39.1]],title='newLine',description='desc',width=8,opacity=0.6,pattern='M12 -7M0 5M9 0A3 3 0 1 0 6 0 A3 3 0 0 0 9 0,2,20,T;M0 0L12 0,15,20',folderId=fid)

The objects in the folder aren't visible, and the left bar looks like this:

Burping the folder checkbox does make the new features visible (and populates their icon rows in the left bar).

[caver456]

This is a real problem, but, it doesn't seem like there's a way to control it with API calls - would have to directly toggle the checkbox from code. Should check with Matt at some point. Probably the GUI doesn't have to deal with this. But - what about importing into a folder?
Either way: removing from 2.0.0 checklist.

[caver456]

does the folder have any properties that can be changed via API? Maybe that could toggle visibility of children? Or a property at folder-creation time that corresponds to the first checkbox when you create a folder in the GUI:

[caver456]

Encountered this again while testing for #30.

Here's the network traffic, with the folder names representing a truth table of the two checkboxes:

(all calls are POST to https://caltopo.com/api/v1/map//Folder)

{"properties":{"title":"testFolder11","visible":true,"labelVisible":true},"id":null}

{"properties":{"title":"testFolder10","visible":true,"labelVisible":false},"id":null}

{"properties":{"title":"testFolder01","visible":false,"labelVisible":true},"id":null}

{"properties":{"title":"testFolder00","visible":false,"labelVisible":false},"id":null}

[caver456]

Currently, caltopo_python builds the addFolder payload like so:

        j['properties']={}
        j['properties']['title']=label
        j['properties']['folder-visibility']='visible'

It looks like the 'folder-visibility' property might be old, unless it indicates whether the folder should initially be checked for the user even if not visible for others?

Adding a folder from code as above, then editing the folder in the GUI, shows that the first checkbox is off, even though the folder and its children are checked in the left box. So, the real bug report is probably to point out that these are out-of-sync ('visible' = false judging by the checkbox, but items are checked in left bar, even thought they are actually not visible on the map).

But - best to first test out both the old 'folder-visibility' property, and the new 'visible' and 'labelVisible' properties, from code.

[caver456]

Tried these variations (basically doing what addFolder does, but with payload variation test cases):

# fid=cts.addFolder('newFolder')
j={}
j['properties']={}
j['properties']['title']='newFolder'
# j['properties']['folder-visibility']='visible'
# j['properties']['visible']=False
# j['properties']['labelVisible']=True

rj=cts._sendRequest('post','folder',j,returnJson='ALL')
fid=rj['result']['id']
cts.addMarker(39,-120,'newMarker',description='desc',color='#00FF00',symbol='fire',size=4,folderId=fid)

Observed behavior:

• no properties: 'buggy' - folder checked and expanded, with new object checked; but not visible on map, and no left bar edit/trash icons; all good after toggling folder cisibility checkbox
• folder-visiblity: old property, has no effect; behaves as above if this is the only property
• visible=True: objects initally visible; folder stays checked and expanded as new objects are added to it
• visible=False: objects not initially visible; folder stays unchecked and collapsed in left bar and in app as new objects are added to it

So, the 'buggy' behavior should probably be reported as a caltopo bug, but, it's obscure enough that there's no real need to wait for a fix.

Overall, this should all be addressed by improving cts.addFolder to accept and use the visible and labelVisible arguments, and to default both to True.

[caver456]

This is related to this caltopo ticket from early 2025, which seems like it might have been fixed. Regardless, caltopo_python should be edited as above, before trying to confirm if the ticket fix has been implemented.

https://help.caltopo.com/hc/en-us/requests/118033