Re: Manging forward and reverse links

In message <[email protected]>,
Ralf Schlatterbeck writes:
>On Tue, Mar 05, 2013 at 09:07:45PM -0500, John P. Rouillard wrote:
>> Ah ok, I didn't explain myself well enough. I want a single edit box
>> that can be used for both:
>>    adding/removing links from this issue to another
>> and
>>   adding/removing links from another issue that points to this one
>> so an entry for the depends property would look like:
>> 
>>    1 3 5 (9) (22) (10)
>> 
>> which would be interpreted as:
>> 
>>   this issue depends on issues: 1, 3 and 5
>> 
>>   issues 9, 22 and 10 depend on this issue
>
>There certainly is no widget for this -- but you may want to code
>your own.

As far as I know there is no way to code anything and get it to the
detectors without putting it into a database field. Is that correct?
(I think I figured out how to do map an arbitrary form field onto the
database, see below.)

>I wouldn't put numbers with different semantics into the same editing
>widget, though.

That's why one of them is decorated with the ()'s to differentate a
normal forward link (a plain number) from a reverse link (a
parenthesized number).

>If you can live with two widgets,

I would prefer to have just one widget because of the space it takes
up on the page. For each multilink widget for issues that I put up I
also include a clickable/hoverable link that shows the current state
of the issue and has the title of the issue display on hover.

This fills up the screen too much and requires more scrolling to
access the messages attached to the issue but if that's the only way
to do it...

>it should be possible to create an edit field that contains the
>issue numbers of depending issues with a separate submit button
>next to it that triggers an action that edits all the other issues
>when pressed.

I would prefer all the changes to all the fields on the form are
submitted in a single action. If you push the main form submit button
and have changed the reverse (depending issues) edit field you should
submit those changes as well as any others you have made. I think the
multi step method (commit the 2 or 3 reverse link fields and then
commit the rest of the data) is just asking for user frustration and
loss of changes.

>For edit actions see roundup/cgi/actions.py and documentation
>http://roundup.sourceforge.net/docs/customizing.html#defining-new-web-actions

Hmm, I wonder does this make sense:

Assuming I am editing issue 30. If I set these fields in the form:

   @add@issue1@depends=30
   @add@issue2@depends=30
   @add@issue3@depends=30
   @remove@issue5@depends=30

will they add a link to issue30 to the depends property on issues 1, 2
and 3 and remove a link to issue30 from the depends property on
issue5?

If so then can I modify EditItemAction::handle to recognize form
variables like:

    @rlink@issue@depends=1,2,3

which is parsed as:

  this is a reverse link request
  on the depends property
  of the issue class.

Then the action can execute a database query to find all issues where
the depends property has item 30. Let's say the response is
2,3,5. Then it creates the self.form fields:

   @add@issue1@depends with value 30
   @remove@issue5@depends with value 30

which IIUC should be the proper syntax for performing the action I
want right? It must also delete the @reverse@issue@depends=1,2,3
entry.

Then this modified form should be able to be passed through to
parsePropsFromForm() (as called from EditItemAction::handle) and then
to all the rest of the form setting machinery without issue right?

--
				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.

------------------------------------------------------------------------------
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev