Remove ROADMAP_ADMIN

[Emmanuel Blot]

Tiny ticket to track the removal of ROADMAP_ADMIN (alias of MILESTONE_ADMIN) in the next release of Trac.

[asmodai@…]

Removal of ROADMAP_ADMIN from Trac's repository @ 3179

[Christian Boos]

Any objections to the patch?

[coderanger@…]

In the database upgrade script there should probably be a search-and-replace.

[Christian Boos]

Well, ok for the search and replace, but I'll do that for 0.11, then.

[asmodai@…]

UPDATE permission SET action = 'MILESTONE_ADMIN' WHERE action = 'ROADMAP_ADMIN'; should solve the case where a user does not yet have MILESTONE_ADMIN. The UNIQUE(username,action) will of course cause problems for this query, so it will need to become a bit smarter.

[Christian Boos]

By first getting rid of the problematic rows?

DELETE FROM permission WHERE action = 'ROADMAP_ADMIN' 
 AND username IN (SELECT distinct(username) FROM permission 
                  WHERE action = 'MILESTONE_ADMIN');

UPDATE permission SET action = 'MILESTONE_ADMIN' 
WHERE action = 'ROADMAP_ADMIN';

[sid]

If removing ROADMAP_ADMIN, should ROADMAP_VIEW also be removed? It's just an alias to MILESTONE_VIEW from what I can tell..

[Matthew Good]

Replying to sid:

If removing ROADMAP_ADMIN, should ROADMAP_VIEW also be removed? It's just an alias to MILESTONE_VIEW from what I can tell..

ROADMAP_VIEW and MILESTONE_VIEW are separate permissions, though the reporter of #4292 also seemed to assume they were aliases. MILESTONE_VIEW only allows viewing individual milestones. ROADMAP_VIEW is required to actually view the "Roadmap" page.

[sid]

Yep, my mistake.

[Christian Boos]

Now that we have db21.py and hence an incompatible database_version between 0.10.x and 0.11, maybe we could do this one as well?

The current change is not important enough to justify a schema upgrade during 0.11.x, so it's either 0.11 or 0.12.

[ThurnerRupert]

nobody touched it for more than 8 months, its not a bug, so it seems to block 0.11 unecessarily …

[osimons]

I'm just setting milestone to 0.11 to get a decision on this. It does not make sense to do a db upgrade as part of a 0.11.x release, so either whatever should get done gets done before 0.11.0, or else it gets moved to 0.12.

My feeling is 0.12 simply because with the 0.11b1 out in the wild, it has just become too close to release for this version to introduce high-impact changes like database updates. I can't quite detect from above what actually needs to be done, the exact SQL needed, and the possible risks involved.

Do now or postpone?

[Christian Boos]

Post-pone.

If we modify the permission table so that it takes into account the fine-grained permissions in 0.12, then we can also do that conversion as a special case.

Currently we have:

CREATE TABLE permission (
        username        text,           --
        action          text,           -- allowable activity
        UNIQUE(username,action)
);

cboos	WIKI_VIEW
cboos	ROADMAP_ADMIN

We could migrate to:

CREATE TABLE permission (
        username        text,           --
        action          text,           -- allowable activity
        realm           text,           -- resource realm
        id              text,           -- resource id
        UNIQUE(username,action,realm,id)
);

cboos	wiki	view	*
cboos	milestone	admin	*

[Christian Boos]

Replying to osimons:

I forgot to say that I share your sentiment about doing a db upgrade in 0.11x at this point.