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

Dear Ralf,

> 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.

Yes, I meant the "reversed logic" in my previous email. (Permission
aspect is a good point, but that is not a problem in my case, because
only co-workers use the system, and they are even allowed to edit
each other's issues. History will record everything. :)

> 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.

Yes, this is how I implemented it eventually (even before I asked this
question here). Even this is not a real speed issue, it bothers me a bit
that every page request starts with an unnecessary filtering in the web
layer (because listing queries are done in page.html, I add queries in a
submenu).

I was just curious how can this implemented nicely. (Sometimes I want
to retire many nodes at the same time.) In sum, it seems that detector
is the best solution here. (However, when I look into the code, I often
realise that nothing is so easy, many cases have to be handled. :)

> Ralf

Regards,
Gábor


_______________________________________________
Roundup-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/roundup-users