Break out off of https://bugzilla.mozilla.org/show_bug.cgi?id=811281#c25. If the permission for the app type is implicitly granted and is not a certified app, then the app permission should be read only (i.e. can be viewed, but not modified).

As I move throw building out these bugs, if either of you think I screwed up, let me know.

There is the open question also on this if we should even list implicit permissions.

I put the list of implicit vs. explicit permissions in bug 817031 comment 3

(In reply to Jason Smith [:jsmith] from comment #2) > There is the open question also on this if we should even list implicit > permissions. Correct; we should not list implicit permissions, let alone make them editable. Specs here (see second-to-last page): https://www.dropbox.com/sh/frgu76pka2h3qlj/7pwHYd8vhd

(In reply to Josh Carpenter [:jcarpenter] from comment #4) > (In reply to Jason Smith [:jsmith] from comment #2) > > There is the open question also on this if we should even list implicit > > permissions. > > Correct; we should not list implicit permissions, let alone make them > editable. Specs here (see second-to-last page): > https://www.dropbox.com/sh/frgu76pka2h3qlj/7pwHYd8vhd Okay. Updating bug title then to reflect this.

As part of bug 812289 I'm going to expose if a permission can be modified by an user or not. Marking this as dependant because of that.

Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.

If/when bug 812289 patch lands, PermissionSettings.get will return the permission and the type (as in "allow/explicit", "allow/implicit", "deny/implicit", "deny/explicit") and so on. As per this bug, this means that only permissions that are marked as "*/explicit" should be modifiable (and shown). If a permission is "*/implicit" then it should not be shown. By the way, I think that this bug and bug 817031 are one and the same. Both of them mean: "Only permissions that are explicit (/explicit) should be shown", don't they?

The current patch-in-process has changed what I said on comment 8. Now PermissionsSettings.get returns only "allow", "deny", "prompt", and "unknown" and there's (or there will be) a new method, PermissionsSettings.isExplicit() that returns true if the permission is explicit, false otherwise. So only the permissions that have PermissionsSettings.isExplicit returning true should be shown.

In sync with Antonio, who is working on the platform patch (bug 812289), to speedup and have the gaia part ready ASAP.

DONT MERGE TILL bug 812289 LANDS! Right now this is working against v5 patch in bug 812289.

(In reply to Antonio Manuel Amaya Calvo from comment #9) > The current patch-in-process has changed what I said on comment 8. Now > PermissionsSettings.get returns only "allow", "deny", "prompt", and > "unknown" and there's (or there will be) a new method, > PermissionsSettings.isExplicit() that returns true if the permission is > explicit, false otherwise. So only the permissions that have > PermissionsSettings.isExplicit returning true should be shown. Why did we abandon the approach of returning an JS object on mozPerms.get in order to add the missing infos? It looked like a more future-proof approach imho, I thought that was the plan.

I wasn't even aware of that plan. At first I tried to not touch the existing API (ergo the composed string of comment 8) and then, as per Jonas request, I changed it to be two different calls. If you prefer for get to return a jsval with .perm and .isExplicit attributes) for example, I can change it so it works that way without any problem. Still, I defer the decission on that to Jonas.

(In reply to Antonio Manuel Amaya Calvo from comment #13) > I wasn't even aware of that plan. At first I tried to not touch the existing > API (ergo the composed string of comment 8) and then, as per Jonas request, > I changed it to be two different calls. If you prefer for get to return a > jsval with .perm and .isExplicit attributes) for example, I can change it so > it works that way without any problem. Still, I defer the decission on that > to Jonas. Yep, sounds like the right person to defer the decision to :)

Duping to a more clean definition per Jonas's feedback about the confusion about 3 bugs open for one bug's purpose.

Removing target 12/21