Edgewall Software
Modify

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#9630 closed enhancement (worksforme)

Add an extension point to validate a wiki page deletion (o version deletion)

Reported by: anonymous Owned by:
Priority: normal Milestone:
Component: wiki system Version:
Severity: normal Keywords:
Cc: erne.castro@…, leho@… Branch:
Release Notes:
API Changes:

Description

I'm extending the tractags plugins (in house for the moment, when stable I will contribute it to see if this is usefull for somebody else) to allow marking a page like a special page.

For instance, in my job I'm using trac to publish our standards for coding or security in our network.

This pages are sensitive in the sense that they should only be modified by a small group.

I thought extending tractags so every page marked with @<something> (ex.: @standard) shows a special hint on top of the page will displaying (somthing like This page is a well known standard and is certified as valid) and further more, only allow modifing, tagging or untagging @standard for a given group.

Trac api allowed me to do 95% of this… but I have not found any way to participate in the process wiki page deletion so to deny it if the page is marked as @standard.

Such an extension point (as the one to validate user input in a wiki page) would be really nice to do things as this one.

Attachments (0)

Change History (9)

comment:1 by erne.castro@…, 9 years ago

added my self in copy…

comment:2 by erne.castro@…, 9 years ago

Cc: erne.castro@… added

comment:3 by Remy Blank, 9 years ago

Milestone: next-major-0.1X

Right, the IWikiChangeListener is only called after a change has been done. We could extend IWikiPageManipulator, or introduce pre-change hooks. Or introduce this possibility with the new generic IResourceChangeListener hooks.

in reply to:  description ; comment:4 by Remy Blank, 9 years ago

Replying to anonymous:

Trac api allowed me to do 95% of this… but I have not found any way to participate in the process wiki page deletion so to deny it if the page is marked as @standard.

Actually, this could be implemented as an IPermissionPolicy that would check the tags and deny WIKI_DELETE if @standard is present (except maybe for TRAC_ADMIN users).

Good enough?

comment:5 by lkraav <leho@…>, 9 years ago

Cc: leho@… added

in reply to:  4 ; comment:6 by anonymous, 9 years ago

Replying to rblank:

Replying to anonymous:

Trac api allowed me to do 95% of this… but I have not found any way to participate in the process wiki page deletion so to deny it if the page is marked as @standard.

Actually, this could be implemented as an IPermissionPolicy that would check the tags and deny WIKI_DELETE if @standard is present (except maybe for TRAC_ADMIN users).

Good enough?

Although I could use IPermissionPolicy for this (and I will for the time being) it seems to me that's more like a workaround than the correct way of doing this.

I mean, implementing a new IPermissionPolicy just for this seems overkill.

On the other hand, any permission related thing should be done using this mechanismo, thats true. One concern that I have is performance: for every wiki page that is loaded this will be called it will have to retrieve its tags and so on. The way I'm doing this now does not requiere to retrieve the tags as they are there just because of the TagSystem itself.

Just cant figure out if IPermissionPolicy is the correct way or just a workaround.

As you guys have way more experience whith this, decide upon this and, eventually close the ticket as worksforme (I guess).

in reply to:  6 comment:7 by Christian Boos, 9 years ago

Replying to comment:6:

Replying to rblank:

Just cant figure out if IPermissionPolicy is the correct way or just a workaround.

I'd say it's the best solution: you want to perform the 'delete' operation on a wiki page, but your local policy doesn't allow that for a given page / user combination.

Performance wise, you should test very early in your plugin if the action is a delete (WIKI_DELETE here), and then if the given resource is concerned.

In the future, to address the performance issue of the permission system in a more general way, we should perhaps think about the permission policies registering action/resource/user patterns, so that only the relevant policies get called.

comment:8 by erne.castro@…, 9 years ago

Resolution: worksforme
Status: newclosed

Ok, good enough for me. I'll close this as worksforme as me, as the reporter, have no further interest in elaborating around this issue.

Please reopen it if you think it's necessary.

comment:9 by Remy Blank, 9 years ago

Milestone: next-major-0.1X

Thanks for the feedback!

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from (none) to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.