Edgewall Software
Modify

Opened 17 years ago

Closed 15 years ago

#2483 closed enhancement (wontfix)

raising exceptions from macros

Reported by: anonymous Owned by: Jonas Borgström
Priority: normal Milestone:
Component: wiki system Version: 0.9.2
Severity: normal Keywords: permission, wiki, macro
Cc: m@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

Per-page access permission is one of the ehancements I was planning for my company Trac instance, since we are going to open it for public access. It does depends of a small patch in mainline and is mostly based in a user-space wiki macro ('PagePermission'). Most of the code is contribution of matt_good & cmlenz, thank you both for the great help.

Attachments (2)

trac-reraising-macro-exceptions.diff (850 bytes ) - added by anonymous 17 years ago.
Simple diff for reraising macro exceptions
PagePermission.py (705 bytes ) - added by anonymous 17 years ago.
wiki-macro

Download all attachments as: .zip

Change History (5)

by anonymous, 17 years ago

Simple diff for reraising macro exceptions

by anonymous, 17 years ago

Attachment: PagePermission.py added

wiki-macro

comment:1 by Markus Tacker <m@…>, 17 years ago

Cc: m@… added

Wow, I need this badly. I just tested it and it workrs for me.

It would be nice to be able to use permission group names.

comment:2 by Matthew Good, 17 years ago

Summary: Per-Page permission handling implemented as a wiki-macroraising exceptions from macros

The macro can be contributed to the MacroBazaar, but I don't think that it will be integrated since it is only helpful as long as the people restricted from viewing pages don't have wiki editing permissions (or admin permissions if the pages are made read-only).

I'm going to keep this ticket open to possibly address the raising of exceptions from within a macro. However, as far as I can see the only reason to do that is for macros that want to block viewing of the entire page, which as I said before is unfortunately not a general solution to adding more granular wiki access control. In any other case I think it's better to have the exceptions caught and displayed as they are now so that it doesn't affect the rest of the page.

in reply to:  2 comment:3 by Christian Boos, 15 years ago

Resolution: wontfix
Status: newclosed

Replying to mgood:

… However, as far as I can see the only reason to do that is for macros that want to block viewing of the entire page, which as I said before is unfortunately not a general solution to adding more granular wiki access control.

Right, I don't think that's the appropriate solution. Fine grained permissions is addressed elsewhere (#654, PermissionPolicy, …).

In any other case I think it's better to have the exceptions caught and displayed as they are now so that it doesn't affect the rest of the page.

Agreed.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Jonas Borgström.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Jonas Borgström 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.