Opened 6 years ago

Closed 3 years ago

#2754 closed defect (invalid)

Tag Permission Checks Should Have Parent Resources

Reported by: pacopablo Owned by: athomas
Priority: normal Component: TagsPlugin
Severity: normal Keywords: resource parent permission
Cc: pacopablo@…, rjollos, otaku42, jun66j5, osimons, mitar Trac Release: 0.11


Currently, the tag resources passed to the IPermissionPolicy interfaces have no parent resources. They should have parent resource to indicate where the tags exist

Attachments (0)

Change History (3)

comment:1 Changed 6 years ago by athomas

Can you recall where this was the case?

comment:2 Changed 5 years ago by rjollos

  • Cc rjollos added

comment:3 Changed 3 years ago by hasienda

  • Cc otaku42 jun66j5 osimons mitar added
  • Keywords resource parent permission added
  • Resolution set to invalid
  • Status changed from new to closed

Your complaint is rather artificial.

The only place where we currently use tag resources is in, and there both times it is to instantiate a resource object for render_resource_link() that doesn't utilize permission checks AFAIK.

No question, we don't have a way to auto-retrieve the corresponding parent (resource) when instantiating a tag resource. But we don't discuss something similar to attachments here. I consider this a next-to-nonsense task in a common TracTags application, where you normally find more than one resource tagged with a given tag, so there's no distinct parent to refer to. On top of this I guess, it would be just another performance hit (#4503). And what would the full list of tagged resources be good for inside every tag resource object?

Plus: In general permission checks in this plugin are done straight on the parent resource as required, as far as I can see. I.e. have a look at [10789] for hints where these places are.

Frankly I can't see a place where we would miss and need the tag resource parent. And in the absence of a reasonable use case this is a none-issue, right? Feel free to reopen, if you can provide details, that might let this defect report look more valid. It would still become an enhancement request then, I guess...

Add Comment

Modify Ticket

as closed .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from athomas. Next status will be 'closed'.
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.