Azurestorageexplorer: Cannot set both public read access & access policy on the same container

[madmox]

Storage Explorer Version: 1.1.0
Platform: Windows
Architecture: ia32
Build Number: 20180507.1
Commit: bcc8990d

Steps to Reproduce:

1. Create an Access Policy on your blob container with full access (rwdl)
2. Set public access level to "public read access for blobs only" on your blob container

OR

1. Set public access level to "public read access for blobs only" on your blob container
2. Create an Access Policy on your blob container with full access (rwdl)

Expected Experience:

You should be able to have both an access policy (to let contributors manage files in your container) and public read access enabled (to let anonymous users be able to access the files) on your container.

Actual Experience:

• When setting public read access level on the container, all access policies are removed.
• When creating a new access policy on the container, the public access level is reset to "no public access".

[madmox]

Workaround: do not use access policies with public read access, but generate a SAS without using access policies. The solution is less flexible (can't revoke or extend accesses to contributors), but it works.

[craxal]

Yep, that's a bug! The same REST operation controls both ACLs and the access level, but we don't preserve both pieces of information when setting either of them.

[MRayermannMSFT]

Fix has been merged into master for 1.3.0.

[v-xuanzh]

The changed access level can’t be saved for one blob container, so create the new bug #380 which is related to this issue.

[dagood]

This is still broken for me after updating to 1.3.0. Specifically, the scenario in https://github.com/Microsoft/AzureStorageExplorer/issues/317 Changing container Access Policies sets Public Access Level to "Private" which was closed as a duplicate of this issue. About info:

Version: 1.3.0

Platform: Windows
Architecture: ia32
Build Number: 20180706.3
Commit: 5319bc48

Should I file a new issue, or will this one be reopened?

[MRayermannMSFT]

I've reopened the issue. Apologies for not actually fixing. We'll be releasing a hotfix ASAP.

[MRayermannMSFT]

1.3.1 notification was sent out last night. That version contains the full fix for this bug. I am now closing this issue.