Can't retain "plug-in access to user list" check box

[bart1]

This feels like a rite of passage since I can't imagine it hasn't happened before (or maybe its just to hard to search in the forum). But on the Setup->Network tab I check the box
but when I restart HS3PRO it becomes unchecked. Which prohibits HSTouch from running

I run a domain server and use an account that's non admin level, I run HS3 as admin and I ensure that permissions allow users to R/W the setup.ini file (assuming that's whats being updated). I've even ran HS3 in the ADMIN account. So what am I doing wrong? I have no insight from the log file.

[Rupp]

Possibly ensure the settings.ini file isn't read only? I've not heard of this issue but once before and it was a antivirus issue.

[rmasonjr]

That setting is not stored in the settings.ini - it's in the HomeSeer database.

I just tried it on a new install of HS3 and it doesnt work. The checkmark comes back on after a restart.

[bart1]

I ensured that the folder both at the config folder and HS3 folder level to be not read only. The file itself is not read only. assuming homeseerdata.hsd?

[rmasonjr]

It's not a permissions issue as Rupp was thinking. That setting is not in settings.ini - it's in the HS database. It looks to be a bug and needs to be reported to support@homeseer.com

[Rupp]

Yes, I thought this was in the settings.ini file but as Rob stated it is stored in the DB. What version of HS3 are you running? If it's the latest version (.540) then please report this issue at support@homeseer.com

[bart1]

version .548

[bart1]

also reported...hit reply too soon

[bart1]

Problem resolved but less then happy on the process.
1. took 40 back and forths on email
2. support attacked this via what appeared to be standard check list
a. provide config data, uninstall and reinstall
b. uninstall any virus protection (this created another very concerning problem which I'm posting separately on the omni plug in forum)
c. ensure file isn't read only
d. repeat.
3. finally after exhausting the list they talked with the lead engineer and suggested a simple settings.ini edit.
4. yes that worked with a caveat.
a. suggested adding gUserListScriptAccess=true to the file which I did and it worked
b. the original line actually said gUserListScriptAccess=obsolete which implies the line isn't used at all
c. there's a gUserListScriptAccess2= xxxxx (list of hex) which also implies the original flag is old
d. just removing the line also fixed the problem (most annoying part is all the work to get to this).
5. I believe this was all part of the batch process that created setting.ini file in the first place but doubt that that will
get fixed, I have no insight so expect this happening again.
6. This is the second issue where the process outcome was either solved by me or it could have been attacked much easier.