Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Preferences overwritten on first launch #439

Closed
built2order opened this issue Aug 29, 2019 · 3 comments

Comments

@built2order
Copy link

commented Aug 29, 2019

Use Case
As an administrator, I want a user to install the application with default configuration.

Expected Behaviour
User installs application (including configuration) and configuration should be read and set during first launch.

Actual Behaviour
User installs application (including configuration) however preferences file is reverted to default during first launch.

Reproduction
Assuming Keka.app is available in /Applications folder

  1. open the Terminal and type this command:
    defaults delete com.aone.keka
  2. open the Terminal and type this command:
    defaults write com.aone.keka ZipUsingAES -bool TRUE
  3. open Keka and navigate to Preferences. Note that the value is not set.
  4. To confirm, open the Terminal and type this command:
    defaults read com.aone.keka ZipUsingAES
@gingerbeardman

This comment has been minimized.

Copy link
Contributor

commented Aug 29, 2019

This is because of sandboxing.

  1. Make sure you are replacing the prefs at correct sandbox location.
  2. When I have had to do this, I have to open the settings plist itself in PListEdit Pro and copy and paste the contents from one plist to the other. So I guess there is some way the OS recognises if the prefs file was created by the app (I have not looked into this).
@aonez

This comment has been minimized.

Copy link
Owner

commented Sep 2, 2019

You're both right. In theory at the first launch Keka should migrate the preferences in the non-sandboxed plist. I'll check that one.

@aonez aonez self-assigned this Sep 2, 2019

@aonez aonez added bug core labels Sep 2, 2019

@aonez aonez added this to the Look at milestone Sep 2, 2019

@aonez

This comment has been minimized.

Copy link
Owner

commented Sep 14, 2019

@built2order this should be fixed in the latests 1.2.0 development builds. I'm closing this one in favor of #15. Let me know there if you test that it works for you (I did).

@aonez aonez closed this Sep 14, 2019

@aonez aonez added the duplicated label Sep 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.