462433 - Update blocklist schema to support severities

Status: RESOLVED FIXED

(Toolkit :: Blocklist Policy Requests, defect)

Description

[Dave Townsend [:mossop]]

We're going to need to update the blocklist database and script to support the severities for bug 455906. Technically it wouldn't be necessary to rev the url for this change, the new xml would get accepted by old clients.

Comment 1

[Dave Townsend [:mossop]]

We'll probably also need to revisit the existing blocklist entries and assign severities to them

Comment 2

[Michael Morgan [:morgamic]]

where is support for this on the roadmap?  when would you need this schema change?

Comment 3

[Michael Morgan [:morgamic]]

Dave?  Could you comment on timing?

Comment 4

[Dave Townsend [:mossop]]

mconnor was supposed to be working on the policy changes, we basically need the server side stuff done whenever that comes into place

Comment 5

[Michael Morgan [:morgamic]]

Oh hey, someone should fix this!

Comment 6

[Michael Morgan [:morgamic]]

Dave - I'm assuming policy and client support are in place now?   Ready to move forward?

What happens to pre 3.5 clients when a blocklist entry has a severity?  Don't they just see it as a regular entry?  That could have some consequences we're not anticipating?

Comment 7

[Dave Townsend [:mossop]]

I'm not sure whether a policy was ever drafted, mconnor?

Yes, the one backwards compatibility issue we must consider is that old clients will see a low severity blocklist entry as just a regular block so we need to decide whether that is ok, or whether the service needs to leave out low severity entries from the returned xml based on the client version that is sent along with the request.

Comment 8

[Mike Connor [:mconnor]]

I think the policy itself needs some looking, can do that this week.

I assumed that we'd serve different data to 3.5 clients than 3.0 clients, but I haven't looked at the blocklist code recently...

Comment 9

[Michael Morgan [:morgamic]]

Seems like the right thing to do would be to either backport everything or just have 3.0.x clients ignore entries with a severity set.  Other way to do it is exclude 3.0.x clients via the app version.

Comment 10

[Michael Morgan [:morgamic]]

What are we going to do here?  Does this even affect the client and what are our plans for 3.6?

Comment 11

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

We were so close!

Connor: did we get to policy that week?

Comment 12

[Mike Connor [:mconnor]]

No, we didn't, from digging into mail archives.  Though, tbh, I don't remember what policy was needed here, at this point!  Or, for that matter, why we blocked implementation on the policy.

What can I do to unblock this?  There was a lot of discussion around 12-18 months back, so I could write something useful/provisional today/this morning if needed.

Comment 13

[Dave Townsend [:mossop]]

(In reply to comment #12)
> No, we didn't, from digging into mail archives.  Though, tbh, I don't remember
> what policy was needed here, at this point!  Or, for that matter, why we
> blocked implementation on the policy.

The policy needed was to essentially decide what we would use the different severities for. We should have an open process for deciding what to block and how hard to do it rather than deciding on a case by case basis.

Comment 14

[Michael Morgan [:morgamic]]

So in cases where all we have is this:
<emItem id="{20a82645-c095-46ed-80e3-08825760534b}"/>

Do I have to add a versionrange even though there aren't any versions?  Can I add:
<versionRange serverity="1"/>

Or will that confuse Firefox?

Comment 15

[Michael Morgan [:morgamic]]

It's be nice if we could just do this in this case:
<emItem id="{20a82645-c095-46ed-80e3-08825760534b}" severity="1"/>

Comment 16

[Dave Townsend [:mossop]]

(In reply to comment #14)
> So in cases where all we have is this:
> <emItem id="{20a82645-c095-46ed-80e3-08825760534b}"/>
> 
> Do I have to add a versionrange even though there aren't any versions?  Can I
> add:
> <versionRange serverity="1"/>

Yes a versionRange element is needed to give a severity, but no minVersion or maxVersion will not confuse anything it will just leave the block affecting all versions. The idea was to allow for different block levels depending on the version of the item being blocked.

Comment 17

[Michael Morgan [:morgamic]]

Ok - so if both min and max versions for that versionRange are NULL we'll end up with:
<versionRange serverity="1"/>

Otherwise it'll just contain the versions as usual.  I will avoid the severity in an emItem or anything that isn't a versionRange.

Comment 18

[Michael Morgan [:morgamic]]

Attachment: v1, adds severities to blocklist service

Comment 19

[Michael Morgan [:morgamic]]

Attachment: v2, added changes to the remora.sql as well

Comment 20

[Michael Morgan [:morgamic]]

Checking in at r53641.

Comment 21

[Michael Morgan [:morgamic]]

http://www.screencast.com/users/morgamic/folders/Jing/media/b987f280-c857-4e2a-91fd-5bad1b09ba23 - regression tests passed.

Comment 22

[Mike Connor [:mconnor]]

(In reply to comment #13)
> The policy needed was to essentially decide what we would use the different
> severities for. We should have an open process for deciding what to block and
> how hard to do it rather than deciding on a case by case basis.

We should have a policy/plan for how we'll use it, but we already have defined the various behaviours available, in the client, so it doesn't make sense to have blocked implementation on knowing how we'd make use of that.  My mistake for not stating that clearly in May.