Re: Two actions (retire and unlink) at the same time

On Fri, Apr 09, 2021 at 03:54:32PM -0400, John P. Rouillard wrote:
> Hi Nagy:
> 
> In message <20210409180732.22053099@Dell>,
> Nagy Gabor writes:
> >I investigated the "saved queries" management of 'devel' template. I
> >observed that the removal of a query is a bit complicated:
> >
> >If we retire a query, then it is still visible in the "queries" list
> >(multilink) of the user, because it is not automatically removed. So
> >the user still need to hide the query (i.e. remove from his queries
> >list).
> 
> Actually it is visible in the "queries" list of any user who chose to
> include it. This makes deletion tricky.
> 
> >In similar scenarios usually we want to perform two actions in the same
> >time:
> >1. Remove query1 from the queries multilink of user1. (This is an 'edit'
> >action on user1.)
> >2. Retire query1. (This is a 'retire' action on query1.)
> >
> >Can these performed in one "HTML form submission"? Which the nicest
> >solution here? Or how can I define a custom Action easily which
> >consists of performing these two db operations?
> 
> If the user is retiring a private query that has never been public, I
> think you can add an auditor that will also edit the multilink for the
> user. Note this will not work if another user has the same query. User
> A won't (in general) have the ability to edit User B's queries
> multilink.

In a detector (be it an auditor or reactor in that case) you have full
access to the hyperdb API. The permission checks happen in the Web
layer, so you *can* write a detector that modifies all multilinks
linking the the retired query.

> >Yes, I know that automatic multilink editing can be done using
> >rev_multilink, according to the documentation, but I am curious. (And I
> >am not sure that the default 'search' action would like that in case of
> >queries.)

I think the rev_multilink in that case would point from the query to all
users (it's a reverse link, the queries are multilinks from user to
query). So a rev_multilink might help you finding the users that link to
the retired query. And you *could* reverse the logic, i.e., remove the
queries Multilink in user and add a users Multilink in query and make
the rev_multilink of that with name 'queries'. When you do this,
retiring a query will automagically "remove" it from all user.queries
rev_multilinks. It won't actually remove everything but the generated
SQL for the reverse navigation will ignore retired items.
But that would mean every user will have to have edit permission on
query.users. That means they could remove other users from that query.

I think the easiest solution is probably in the query-template: Just
filter the displayed queries by their is_retired status. Just don't
display retired queries.

Ralf
-- 
Dr. Ralf Schlatterbeck                  Tel:   +43/2243/26465-16
Open Source Consulting                  www:   www.runtux.com
Reichergasse 131, A-3411 Weidling       email: [email protected]