bugBo-Keep - Bugs: bug #32814, trust plugin can exception out...

 
 

bug #32814: trust plugin can exception out when there are no trustors

Submitter:  Mark Jenkins <markjenkins>
Submitted:  Wed 16 Mar 2011 09:06:15 PM UTC
   
 
Category:  None Severity:  3 - Normal
Item Group:  None Status:  Fixed
Privacy:  Public Assigned to:  paritjamie
Open/Closed:  Closed
* Mandatory Fields

Add a New Comment Rich Markup
   

Tue 19 Apr 2011 05:37:19 PM UTC, comment #4: 

The choice to allow the user to continually create new transactions (and as a result be able to next/prev browse amoungst them) isn't the cause of this bug -- it's an intentional design decision in the shell. So, with respect to this bug at the trust plugin level, yes, that's okay and fixing this bug doesn't require addressing that. That's the expected behavior from the shell.

I'd welcome the suggested change to be pushed.

What I wasn't clear on in this thread and eludicated more on in
this post (http://lists.nongnu.org/archive/html/bokeep-devel/2011-04/msg00000.html) was that for either design 1 and 2 it does make sense that the trust plugin raise BoKeepTransactionNotMappableToFinancialTransaction when get_financial_transactions is called if no trustor is selected. (because selecting a trustor is essential)

With that in place, a shell can be as gun loady or as cage making as it likes; and that is where I'd like those design decisions to be made; not by the plugins.

So lets close out this bug as described and take discussion on how the shell ought to be designed to the mailing list as I already started to attempt...

Mark Jenkins <markjenkins>
Group administrator
Tue 19 Apr 2011 12:07:29 AM UTC, comment #3: 

I did approach 2, at least with respect to the plugin's interface, not the core interface.

The related question is, does it make sense to let the user keep doing "new" and "next/prev" when what they're browsing through are merely empty husks, or should they be blocked from saving something that's clearly useless?  If so, then the plugin IS affecting the bo-keep shell.  If not, the user is creating junk.  Is it the same argument that one often hears with respect to c, where we're loading the gun and pointing it at the user's foot and what they do after that is up to them?

If yes, I can check in what I've got, as it behaves as described..

Jamie <paritjamie>
Group administrator
Thu 14 Apr 2011 08:56:54 PM UTC, comment #2: 

I don't think it's appropriate that a plugin be able to interfere with a user's use of the Bo-Keep shell. I don't want hooks for that.

Or, at least this case hasn't convinced me.

The "Bo-Keep way" is to disable interactive widgets when context means they make no sense -- so if entered information is just going to be lost the user shouldn't be able to enter it in the first place.

The other side of the "Bo-Keep way" (well, in the main window...) is that we never take data from a user and toss it. If they get the chance to enter it, retainment is automatic, no "we'll only keep it if you do these other things stuff" and "if you don't do it the right we annoy you with pop up stuff"

So two ways to do this
1. a Trust transaction can be associated with no trustor and the user can edit everything else and everthing else is automatically retained. But, the get_financial_transactions function could refuse to pass it on to the backend if no trustor is selected.

2. We say that all trust transactions must be associated with a trustor and we don't let the user edit anything else (by disabling the other widgets) until a trustor is selected.

The other thing to figure out -- when there is at least one trustor available do we automatically default to it (meaning this issues only applies when no trustors are available), or do we default to no trustor and make the user choose one (before anything else).

Mark Jenkins <markjenkins>
Group administrator
Wed 13 Apr 2011 11:26:10 PM UTC, comment #1: 

The easy fix for the exception is, if no trustor exists matching the requested one (including, obviously, None) then don't do the transactional association.

The resultant behaviour is, no exception, and it lets you do new and browse around and such, but the entered amount vanishes.

The followup question is : should there be associated validation behaviour to at least warn the user that they're about to lose their entered amount information?  Right now as far as I can tell the transition logic ALWAYS goes forward or backward as long as there's somewhere to go to, it doesn't appear to permit any delegation of that decision to the plugin itself.  Is that true or am I missing subtle callback hooks hidden in there somewhere?

If the answer is "no, if the user loses their value then whatever" then I can commit what I have now and the issue can be closed, otherwise need to go deeper into the rabbit hole.

Jamie <paritjamie>
Group administrator
Wed 16 Mar 2011 09:06:15 PM UTC, original submission:  

trust plugin can exception out when there are no trustors

Mark Jenkins <markjenkins>
Group administrator

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by paritjamie (Posted a comment)
  • -email is unavailable- added by markjenkins (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 3 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-04-20 paritjamie StatusNone Fixed
        Open/ClosedOpen Closed
    2011-04-13 paritjamie Assigned tomarkjenkins paritjamie

    Back to the top

    Powered by Savane 3.13-bb6a.
    Corresponding source code