Ticket #4137 (closed Bug: fixed)

Opened 7 years ago

It is not possible to edit "own" expired contents

Reported by: naro Owned by:
Priority: critical Milestone: 2.1
Component: Infrastructure Version:
Severity: Keywords:
Cc:

Description

In 2.0.x user may create content, set expiration date and list this content in the folder_contents everytime (and edit it, for example).

In 2.1 this content is lost, because catalog search filter out inactive portal content. No user, except Manager (by default), is able to show/edit own inactive content. This is bad in my opinion.

Change History

comment:1 Changed 7 years ago by alecm

Hm, you are correct, this is very bad. Unfortunately it is not easy to solve. searchResults is called with the catalog as context so a permissions check (for 'Access inactive portal content') on the folder being listed is not possible. Also, even if it did work, that would allow the owner of the listed folder to see expired objects they might not have the owner role over (i.e. due to PLIP 16 local role blocking). Any ideas?

comment:2 Changed 7 years ago by alecm

The possible (hacky) solutions I'm pondering right now are:

1) Add an optional parameter to portal_catalog.searchResults() which will disable the expiration check. The template/script itself may then use this when it determines that the caller has sufficient authority on the relevant folder to see expired content.

2) Have portal_catalog check the 'Access inactive portal content' permission on the paths passed in if there's a 'path' query instead of on the catalog itself.

Either way, we probably want to grant the 'Access inactive portal content' to the owner role and use that for this purpose. The first option is cleaner, but has the side effect of allowing anyone to turn off the expiry filtering for any query if they are a bit clever. The expiry stuff isn't really security, so I'm not sure this is critical, and it may be useful to turn it off in other contexts as well. The second solution is a bit more hacky but doesn't necessarily suffer from the above problem if implemented properly. Implementing it may be difficult, as it has to be able to deal with having multiple paths passed in and make expiry decisions based on each of them. This would potentially turn one catalog query into the sum of many, which is an ugly prospect, especially if the paths overlap.

The PLIP 16 issues are still here with both of these. But I think it is not too serious a concern, as this would only show expired objects that the user has 'View' permission on, but it would still violate local role blocking from a UI perspective. Making this completely PLIP16 safe would require creating another allowedRolesAndUsers type index that just tracks 'Access inactive portal content'. This in turn would require overriding reindexObjectSecurity using a monkey-patch, no fun!

comment:3 Changed 7 years ago by limi

"Either way, we probably want to grant the 'Access inactive portal content' to the owner role and use that for this purpose. The first option is cleaner, but has the side effect of allowing anyone to turn off the expiry filtering for any query if they are a bit clever."

+1 for the first approach. Expiry isn't security, so this is the best solution in my opinion.

comment:4 Changed 7 years ago by alecm

  • Status changed from new to closed
  • Resolution set to fixed

Fixed using solution 1) in 2.1 svn.

Note: See TracTickets for help on using tickets.