Skip to content

EXIF removal set to off by default #3043

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

Conversation

VitalyVPinchuk
Copy link
Contributor

Description (required)
Settings -> Privacy -> Manage EXIF TAGS -> all tags checked

Based upon discussion #2863 (comment)

What changes did you make and why?
Set default values to ON for manageExifTags preference.

Tested betaDebug on emulator with API level 28.

Copy link

@pullrequest pullrequest bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ A review job has been created and sent to the PullRequest network.


@VitalyVPinchuk you can click here to see the review status or cancel the code review job.

@codecov-io
Copy link

codecov-io commented Jun 28, 2019

Codecov Report

Merging #3043 into master will decrease coverage by <.01%.
The diff coverage is 0%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master   #3043      +/-   ##
=========================================
- Coverage    4.41%   4.41%   -0.01%     
=========================================
  Files         259     259              
  Lines       12309   12310       +1     
  Branches     1056    1056              
=========================================
  Hits          544     544              
- Misses      11726   11727       +1     
  Partials       39      39
Impacted Files Coverage Δ
...java/fr/free/nrw/commons/upload/FileProcessor.java 3.96% <0%> (ø) ⬆️
...fr/free/nrw/commons/settings/SettingsFragment.java 0% <0%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 6fb3331...2170020. Read the comment docs.

@ashishkumar468
Copy link
Collaborator

ashishkumar468 commented Jun 28, 2019

Hi @VitalyVPinchuk , I was looking into the code, In FileProcessor#getExifTagsToRedact. As far as I could understand, there is no where we check which tags need to be redacted

Set<String> redactTags = new HashSet<>(Arrays.asList(
                context.getResources().getStringArray(R.array.pref_exifTag_values)));

This is code which fetches the list of attributes to be redacted, but how does it verify the on/off state ?

@VitalyVPinchuk
Copy link
Contributor Author

Hi @VitalyVPinchuk , I was looking into the code, In FileProcessor#getExifTagsToRedact. As far as I could understand, there is no where we check which tags need to be redacted

Set<String> redactTags = new HashSet<>(Arrays.asList(
                context.getResources().getStringArray(R.array.pref_exifTag_values)));

This is code which fetches the list of attributes to be redacted, but how does it verify the on/off state ?

Hi @ashishkumar468
This line gets only the ticked tags
Set<String> prefManageEXIFTags = defaultKvStore.getJson(Prefs.MANAGED_EXIF_TAGS, setType);
and then
if (prefManageEXIFTags != null) redactTags.removeAll(prefManageEXIFTags);
excludes them from the whole set of tags.

@ashishkumar468
Copy link
Collaborator

@VitalyVPinchuk As far as I understand, the ticked one's should not be redacted, and those which are not ticked, those should be redacted. Would be better if one of @misaochan @neslihanturan @maskaravivek @nicolas-raoul could confirm this ?

@VitalyVPinchuk
Copy link
Contributor Author

e ticked one's should not be redacted,

Yes. This is exactly what it does. What seems to be wrong?

@ashishkumar468
Copy link
Collaborator

ashishkumar468 commented Jun 28, 2019

`Set prefManageEXIFTags = defaultKvStore.getJson(Prefs.MANAGED_EXIF_TAGS, setType);```

@VitalyVPinchuk This gives null when all of them are ticked, because of which, these attributes do not get removed from the attributes which need to be redacted, as a result of which, even the ticket attributes get redacted

@VitalyVPinchuk
Copy link
Contributor Author

Strange.
This should return set of strings with 7 elements when all the tags are selected.
And the method should return hashset of zero elements, which means there is nothing to redact.
It works for me this way, but I'll check once again.
Screenshot 2019-06-28 at 17 12 49
Screenshot 2019-06-28 at 17 13 24

@ashishkumar468
Copy link
Collaborator

ashishkumar468 commented Jun 28, 2019

Hi @VitalyVPinchuk , I rechecked, the value which is coming from preference is null

Attaching relevant screenshots
device-2019-06-28-205917

Screenshot 2019-06-28 at 9 00 27 PM

Screenshot 2019-06-28 at 9 01 03 PM

Screen
shot 2019-06-28 at 9 00 50 PM
Screenshot 2019-06-28 at 9 01 40 PM

@ashishkumar468
Copy link
Collaborator

A probable cause is that although these values are checked by default, they have no entries in the preferences and would be added only when we check/uncheck them and that is why null is being returned when we ask for it.

@VitalyVPinchuk
Copy link
Contributor Author

A probable cause is that although these values are checked by default, they have no entries in the preferences and would be added only when we check/uncheck them and that is why null is being returned when we ask for it.

Yes, you're absolutely right. Now I see. The values are added to preferences only after checking/unchecking them. I didn't know about that. Thanks!

Copy link

@pullrequest pullrequest bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm


Reviewed with ❤️ by PullRequest

@VitalyVPinchuk
Copy link
Contributor Author

Hello!
Default values from preferences.xml (android:defaultValue) are ignored.
So I've tried to setDefaultValues(this, R.xml.preferences, false). But Set<String> prefManageEXIFTags = defaultKvStore.getJson(Prefs.MANAGED_EXIF_TAGS, setType) still returns null, unlike
Set<String> prefManageEXIFTags = sharedPreferences.getStringSet("manageExifTags", new HashSet<String>()), which returns hashset of selected tags.

What is the best way to set defaults for preferences from xml file?

translatewiki and others added 2 commits July 1, 2019 09:22
* Removed hardcoded strings in DeleteHelper

* Revert "Removed hardcoded strings in DeleteHelper"

This reverts commit 4bc55fc.
@ashishkumar468
Copy link
Collaborator

ashishkumar468 commented Jul 3, 2019

Hi @VitalyVPinchuk , Apologies for the delayed response, you can use something like this
PreferenceManager.setDefaultValues(this, R.xml.preference, true);

See this

@VitalyVPinchuk
Copy link
Contributor Author

VitalyVPinchuk commented Jul 3, 2019

I wonder what I should do to set defaults from xml into defaultKvStore. I've already set defaults for shared preferences and they return right values.

@neslihanturan
Copy link
Collaborator

Hi @VitalyVPinchuk , please do not use shared preferences at all. Instead use defaultKvStore. You can simply search in settings fragment and see it's usages. And then please remove shared preferences added by you. An example:
defaultKvStore.putBoolean(Prefs.IS_CONTRIBUTION_COUNT_CHANGED, true);

@VitalyVPinchuk
Copy link
Contributor Author

Hi @neslihanturan , sure I will remove shared preferences. Just added the code for test reasons. But is there a way to use defaults from XML with defaultKvStore just like PreferenceManager.setDefaultValues(this, R.xml.preference, true);?

@neslihanturan
Copy link
Collaborator

Hi @VitalyVPinchuk , I think this line "addPreferencesFromResource(R.xml.preferences);" already gets all default preferences values. So multiSelectListPref should have the default values. Can you try seeing the default content of:

multiSelectListPref.getValues()

@VitalyVPinchuk
Copy link
Contributor Author

Thanks! It works.

But we also need to use defaults even without opening settings activity (where we load them). What could be done about that?

@ashishkumar468
Copy link
Collaborator

@VitalyVPinchuk Do you mean that the values are initialised only when SettingsActivity is opened ?

@VitalyVPinchuk
Copy link
Contributor Author

@VitalyVPinchuk Do you mean that the values are initialised only when SettingsActivity is opened ?

I guess so.

@ashishkumar468
Copy link
Collaborator

@VitalyVPinchuk Do you mean that the values are initialised only when SettingsActivity is opened ?

I guess so.

Then can we not initialise them in the App class , CommonsApplication ?

Copy link
Member

@maskaravivek maskaravivek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@VitalyVPinchuk Can you please make the suggested changes. Also, IMO we should simply check if shared pref has the exif values set or not. If its not set at all then we can assume that the user doesn't want us to remove EXIF information.

@VitalyVPinchuk
Copy link
Contributor Author

@VitalyVPinchuk Can you please make the suggested changes. Also, IMO we should simply check if shared pref has the exif values set or not. If its not set at all then we can assume that the user doesn't want us to remove EXIF information.

Hi @maskaravivek
I got your point and made those changes.

But still, I think we should read android:defaultValue from xml into JsonKvStore prior to opening SettingsFragment.

For example, if I change default value for android:key="uploads" from 100 to 5 and install app anew, it still loads 100 images.

@misaochan
Copy link
Member

Is this PR ready for testing? :)

@VitalyVPinchuk
Copy link
Contributor Author

Yes, it is.
Or do you mean that tests should be added?

Copy link

@pullrequest pullrequest bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✖️ This code review was cancelled. See Details

@misaochan
Copy link
Member

misaochan commented Jul 11, 2019

Don't worry about the unit tests - this is a bugfix anyway so no need for that. :)

Yes, I was planning on testing your PR as all PRs need to be manually tested before we merge them. But I just noticed that you have submitted your PR to master, whereas this bugfix is needed in 2.11-release. Could you rebase your PR on that branch and resubmit to it, please? Sorry for the inconvenience, we should have mentioned that earlier.

@VitalyVPinchuk
Copy link
Contributor Author

Don't worry about the unit tests - this is a bugfix anyway so no need for that. :)

Yes, I was planning on testing your PR as all PRs need to be manually tested before we merge them. But I just noticed that you have submitted your PR to master, whereas this bugfix is needed in 2.11-release. Could you rebase your PR on that branch and resubmit to it, please? Sorry for the inconvenience, we should have mentioned that earlier.

Hello @misaochan
Sure, I'll try to rebase though I've never done this before :)
Any help appreciated!

@maskaravivek maskaravivek changed the base branch from master to 2.11-release July 11, 2019 13:58
@maskaravivek
Copy link
Member

@misaochan @VitalyVPinchuk I just rebased the PR against 2.11-release. You can click on the Edit button on the right side of the PR title and change the base branch. In most cases, there won't be a merge conflict if the change is small.

@misaochan
Copy link
Member

misaochan commented Jul 12, 2019

@maskaravivek Changing the base alone is insufficient, though - as you can see, now there are 72 files changed. ;) The person submitting the PR still needs to rebase on 2.11-release via git.

@VitalyVPinchuk You can use git rebase upstream/2.11-release

Copy link
Member

@maskaravivek maskaravivek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approving the code changes. Wasn't able to test the changes.

@VitalyVPinchuk
Copy link
Contributor Author

@maskaravivek Changing the base alone is insufficient, though - as you can see, now there are 72 files changed. ;) The person submitting the PR still needs to rebase on 2.11-release via git.

@VitalyVPinchuk You can use git rebase upstream/2.11-release

Hello @misaochan @maskaravivek
Is it still necessary to do git rebase upstream/2.11-release?

@ashishkumar468
Copy link
Collaborator

Yes, @VitalyVPinchuk . Please do it. As you can see the number of file changes are 72, and relevant to yours would be 3-4 I guess :-)

@misaochan
Copy link
Member

Umm, there are still 66 changes, haha...

@VitalyVPinchuk , would it help if you created a new PR from scratch? You can create a local branch based on 2.11-release, copy your changes to that branch, and then submit your PR to 2.11-release, if that would be easier for you than trying to figure out the rebase.

Alternatively we can create the PR for you, but then it wouldn't be attributed to you, so we will try to avoid this if possible.

@VitalyVPinchuk
Copy link
Contributor Author

Ok, I'll make a local branch from 2.11-release and put the changes there.
I used to play with rebase command but never used it in real life so clearly I did something wrong.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants