Opened 6 years ago

Closed 6 years ago

#1892 closed improve feature (fixed)

Community transparency: Add functionality for treasurer to edit the donation list

Reported by: crumbking Owned by: shevek
Priority: critical Milestone: 1.5
Component: BW Admin Keywords:
Cc: mahouni

Description

Issue

Currently we lack of transparency for the donations as we get more donations as currently are displayed. There are differences between the accounts and the website because:

  • bank transfers are not shown on the website
  • sometimes the Paypal statistics are not updated on our page after the donation

solution proposal

  • add a small tool for the treasurer to edit the donation list entries and add a form to insert new ones
  • why we are at it let's move the treasurer query to activate the donation bar on the internal startpage in this page, too

Attachments (4)

adddonation.png (44.0 KB) - added by shevek 6 years ago.
donationlist.png (40.9 KB) - added by shevek 6 years ago.
startcampaign.png (28.0 KB) - added by shevek 6 years ago.
patch1892.diff (908 bytes) - added by shevek 6 years ago.
Allow editing of all entries in the donation list

Download all attachments as: .zip

Change History (68)

comment:1 Changed 6 years ago by shevek

Didn't we close a similar report lately? Or is this a duplicate?

comment:2 Changed 6 years ago by crumbking

Naa ... yes your are right we closed a couple. I will close another one as all the other proposals needs more to look deeper into Paypal API ;-)

Let's keep it simple: treasurer have the account lists and could simply add the missing ones in our DB.

comment:3 Changed 6 years ago by pablobd

  • Priority changed from minor to critical
  • Type changed from new feature to bug

I'm changing the type and priority since not showing the right amount can easily be called a bug and not a feature, if you see now the bar in http://www.bewelcome.org/donate the amount is probably less than the real situation, transparency is not a minor issue

comment:4 Changed 6 years ago by shevek

  • Milestone changed from unassigned to 1.5
  • Owner set to shevek
  • Status changed from new to assigned

Assigned to me. Will work on this based on stuff crumbking already provided.

comment:5 Changed 6 years ago by shevek

  • Component changed from unknown to BW Admin

Changed 6 years ago by shevek

Changed 6 years ago by shevek

comment:6 Changed 6 years ago by shevek

I added a admin interface for the treasurer. The treasurer can add a donation or edit a donation that was added before hand. For the sake of consistency I did not include the option to edit paypal donations or to delete any.

The rights system is pretty basic: One right 'Treasurer' level '10' scope 'All' (actually only 'Treasurer' is checked).

The interface looks like this (some translation missing):

comment:7 Changed 6 years ago by shevek

  • Status changed from assigned to local_testing

Commit: https://gitorious.org/~thisismeonmounteverest/bewelcome/search_and_set_location/commit/5125f45988b6561e3a4b2109d8a2b779c1bef41b

Before playing around with it you need to update the rights table:

INSERT INTO `bewelcome`.`rights` (`id`, `created`, `Name`, `Description`) VALUES (NULL, CURRENT_TIMESTAMP, 'Treasurer', 'This right enables the treasurer to keep the donations bar shown on /donate to be (more) accurate by adding bank tansfers to the database.

Only one level (10) needed (as there''s only one treasurer) and scope should always be "ALL".');

comment:8 Changed 6 years ago by crumbking

Great work!

What I forgot to say: Could you add the query to toggle the donation campaign? A simply link "Activate campaign/ Deactivate campaign in the action bar would do it. You find the query in "Queries for volunteers"

Ohh and you don't like sidebars on the left side? ;-)

comment:9 follow-up: Changed 6 years ago by crumbking

It would also be cool if the donation bar could be restarted once in a year from here during the GA.

comment:10 Changed 6 years ago by mahouni

local_testing on the mileston 1.5 branch: https://gitorious.org/~mahouni/bewelcome/mahouni-rox/commits/ms15_develop_20130129

Don't forget the Database update for ticket #1892 and #1858. Check: http://trac.bewelcome.org/wiki/DatabaseChanges

Last edited 6 years ago by mahouni (previous) (diff)

comment:11 in reply to: ↑ 9 Changed 6 years ago by shevek

It would also be cool if the donation bar could be restarted once in a year from here during the GA.

I have a look into it (for both comment 8 and 9).

Regarding left sidebars: I started with the mass mailing tool and there a right sidebar came natural as that was what was there. Switching for the treasurer tool would have been a stupid idea ;)

comment:12 Changed 6 years ago by shevek

Starting and stopping is pretty simple. Implemented.

Problem with donation limit is that we need to store it somewhere. I could write a file with this content

[donation]
needed_per_year = 1260
campaign_start_date = 2012-10-11

into '/data' and take the info from there if the file exists. Otherwise I default to the given values in DonateModel?->getDonationStats();

Shouldn't be a problem as a lot of stuff is written to /data.

Last edited 6 years ago by shevek (previous) (diff)

Changed 6 years ago by shevek

comment:14 Changed 6 years ago by shevek

A small addition (no ticket): Currently if the donation bar is shown the wrong tab is selected this is really annoying.

The following commit fixes this. Would be oh so nice, if we could add that to 1.4: https://gitorious.org/~thisismeonmounteverest/bewelcome/search_and_set_location/commit/13897d9d586a8f8ebaaccabc4c294d98082c1d01

comment:15 Changed 6 years ago by crumbking

2 thoughts:

  • Should we move the campain values not in rox.ini ? Why creating a new file in /data?
  • How to handle the donation bar wordcode? It's likely that we will change this once a year. To avoid redundant data we don't just update the translation. Could we change this wordcode in the above campaign form, too?

Anyway pretty awesome! thx shevek

+1 one for adding the tab fix in 1.4 (ask mahouni)

comment:16 Changed 6 years ago by shevek

  • Cc mahouni added
  • I can put it into rox_local.ini. But than I need to load it and rewrite it. With parse_ini_file that would delete all comments in the file. Just didn't want to write a sophisticated method.
  • The wordcode doesn't need to be changed anymore I'd say. We know the amount of money needed and the year the campaign starts. So we just do 'This term %1$s € have been contributed so far. Help us to reach %2$s € to cover our costs for %3$s!' and that's it.
  • Asked mahouni :-)

comment:17 follow-up: Changed 6 years ago by mahouni

It's okay for me. Do I get that right: only this commit would be added to 1.4: [1892] Make sure help the project is select if the donation bar is shown

The rest goes to 1.5?

comment:18 in reply to: ↑ 17 Changed 6 years ago by shevek

It's okay for me. Do I get that right: only this commit would be added to 1.4: [1892] Make sure help the project is select if the donation bar is shown

Yes, only the changes to personalstartpage.teasercontent.*.

comment:19 Changed 6 years ago by mahouni

okay, I pushed that to develop. The correct tab should be active then. https://gitorious.org/bewelcome/rox/commit/086be6e4be901866341deb61200e919d47eee014

comment:20 Changed 6 years ago by shevek

Due to popular demand the two values are now stored in the params table. Therefore all in all this SQL has to be executed now:

INSERT INTO `bewelcome`.`rights` (`id`, `created`, `Name`, `Description`) VALUES (NULL, CURRENT_TIMESTAMP, 'Treasurer', 'This right enables the treasurer to keep the donations bar shown on /donate to be (more) accurate by adding bank tansfers to the database.

Only one level (10) needed (as there''s only one treasurer) and scope should always be "ALL".');

ALTER TABLE `params`  ADD `neededperyear` INT NOT NULL DEFAULT '1260' COMMENT 'Amount needed per year as shown during the donation campaign.' AFTER `ToggleDonateBar`,  ADD `campaignstartdate` DATE NOT NULL DEFAULT '2012-10-11' COMMENT 'The date the donation campaign started, used to gather the donated amount in this campaign.' AFTER `neededperyear`

Matching commit: https://gitorious.org/~thisismeonmounteverest/bewelcome/search_and_set_location/commit/17a8f7daf97da328a519f50f2777be2574ba6dc8

comment:21 Changed 6 years ago by planetcruiser

i think the params table in its current form is not suitable for extension. having to add a column for a new key/value pair is a bit of an "unusual" idea. ;) looking at the current columns in the params table most of it is configuration that should be done in rox_*.ini in the first place. i think we should just close our eyes on this one and declare the table deprecated.

a common design pattern for this would be a generic key/value table with one row for each new entry (id, created, updated, key, value, comment). this way no database structure changes for further extensions are needed. however, such a table is usually a bad design choice, because it will be used as a general dump for assorted data fragments and probably even more configuration settings.

so, let's look at the required data model here. we have a donation campaign with:

  • goal (in EUR)
  • startDate
  • endDate
  • showOnStartpage (boolean)

let's add:

  • id
  • updated
  • created

..and we have a neat DonationCampaign entity with a donation_campaigns table. stir it up with a DonationCampaigns model, controller and view for admins (and maybe users) and we have a nice MVC meal, easy to digest for everyone. :) rows in the donations table get a foreign key for donationCampaign and we have predictable relational data structures.

comment:22 follow-up: Changed 6 years ago by shevek

And here I stand thinking we're in maintenance mode.

While I agree on the general pattern, if we move the showOnStartpage to the new generic table I need to alter old code. I would like to avoid that.

Did you do a code review of the changes I made? I encapsulated all access to the DB into the donation model which I thought appropiate.

PS: There is no end date.

comment:23 in reply to: ↑ 22 ; follow-up: Changed 6 years ago by planetcruiser

Replying to shevek:

And here I stand thinking we're in maintenance mode.

well, that seems to be question right now. but we should discuss this on the list. while this is not decided yet, let's try to produce quality code and move away from quick hacks.

While I agree on the general pattern, if we move the showOnStartpage to the new generic table I need to alter old code. I would like to avoid that.

understandable. old code as in ./htdocs/bw/ spaghetti monster? the question is, do we plan to extend the donation campaign feature in the future? at the moment things point that way. it plays an essential part in the existence of our organisation. so this would be additional motivation to straighten out the implementation.

Did you do a code review of the changes I made? I encapsulated all access to the DB into the donation model which I thought appropiate.

could you point me to the commit please? i am a bit confused by the different branches all over. maybe commit to develop if not already done yet and i review there.

PS: There is no end date.

i noticed that. but there really should be, right? this way we could program donation campaigns way in advance and don't need to press a button on 1 jan 00:00 for example. ;) but then again this might not be part of this ticket.

regarding the entity pattern being overkill: while adding an entity and a table for just one row probably is a lot of overhead, the params table is not a nice alternative. let's think a bit ahead: with campaign entities we have much more possibilities and they can be easily maintained. adding a new row for each donation run would allow much more transparency in the long run. users could look up for which campaign they donated etc..

a general advice: the original ticket description includes at least 2 issues (more like 3), which is problematic already. more than one issue per ticket makes it difficult to follow the development progress, fit things into schedule and to test them. we might need a quality control for new incoming tickets.

comment:24 Changed 6 years ago by jsfan

Please do not include database name in SQL queries for schema changes. The database name might differ for other developers as it can be configured freely. I've adjusted the query on DatabaseChanges .

comment:25 Changed 6 years ago by jsfan

Wordcode AdminTreasurerDonator should be changed to AdminTreasurerDonor. Enough bad English in Rox already. (cf. http://www.usingenglish.com/forum/ask-teacher/15716-donor-donator.html)

A link to "start campaign" should also exist when the campaign is already running to be avble to change the goal (even if it's only for corrections).

I don't always seem to get accurate figures on the thermometer even though the figures are there in the donations listing for the treasurer. Possibly, this only happens if the campaign is ended and a new one is subsequently started.

Last edited 6 years ago by jsfan (previous) (diff)

comment:26 Changed 6 years ago by jsfan

  • Status changed from local_testing to needs_work

comment:27 in reply to: ↑ 23 ; follow-up: Changed 6 years ago by shevek

Replying to planetcruiser:

the question is, do we plan to extend the donation campaign feature in the future? at the moment things point that way.

Do they? I'm not aware of this.

Did you do a code review of the changes I made? I encapsulated all access to the DB into the donation model which I thought appropiate.

could you point me to the commit please? i am a bit confused by the different branches all over. maybe commit to develop if not already done yet and i review there.

see comment 20.

PS: There is no end date.

i noticed that. but there really should be, right?

The campaign always ends when the goal is reached, albeit not automatically. A new campaign is started on the trigger.

The donation page shows all donations given since campaign start. The campaign normally starts with the GA after the needed amount is defined.

I'd say we don't need to change anything there.

this way we could program donation campaigns way in advance and don't need to press a button on 1 jan 00:00 for example. ;) but then again this might not be part of this ticket.

If the campaign always starts on 1 jan 00:00 we probably wouldn't need a database table at all :-)

regarding the entity pattern being overkill: while adding an entity and a table for just one row probably is a lot of overhead, the params table is not a nice alternative. let's think a bit ahead: with campaign entities we have much more possibilities and they can be easily maintained. adding a new row for each donation run would allow much more transparency in the long run. users could look up for which campaign they donated etc..

Currently you can't even check if you donated. Only if the donation is in the last 25 results it's highlighted. Do we need to take this into account? That's something completely different.

a general advice: the original ticket description includes at least 2 issues (more like 3), which is problematic already. more than one issue per ticket makes it difficult to follow the development progress, fit things into schedule and to test them. we might need a quality control for new incoming tickets.

Well, I guess we need a place to define requirements for a feature. This ticket isn't a bug report.

comment:28 Changed 6 years ago by shevek

  • Status changed from needs_work to local_testing

Committed the changes for comment 25 (https://gitorious.org/bewelcome/rox/commit/3b2e40c4e5fcfcbe30fcbc32b4ec4a95faadd04f).

Change status back to local_testing.

Discussion if we need a new table or not can continue while the feature is tested.

Additionally I like to point out that this functionality is for exactly one person (at most the BoD).

comment:29 follow-up: Changed 6 years ago by crumbking

Actually we will have a community campaign but this we will not run through the startpage. We could prepare a DB for several campaigns. But the community c. will need more than just this backend. Therefore another ticket. This ticket is mainly about the edit function of the list.

comment:30 in reply to: ↑ 29 Changed 6 years ago by planetcruiser

Replying to crumbking:

This ticket is mainly about the edit function of the list.

yes, but the submitted fixes also contain a hack for setting the campaign start date via params table. that's the only problem i have with it.

comment:31 in reply to: ↑ 27 ; follow-up: Changed 6 years ago by planetcruiser

  • Type changed from bug to improve feature

Replying to shevek:

Did you do a code review of the changes I made? I encapsulated all access to the DB into the donation model which I thought appropiate.

could you point me to the commit please? i am a bit confused by the different branches all over. maybe commit to develop if not already done yet and i review there.

see comment 20.

ok, that's the move from ini to params table. while that's an improvement, i still think it could be optimised to feel less hackish. the params table doesn't even have an entity. if one has to write sql for updating just two fields, something is wrong.

would you be terribly offended if i rewrite this with a DonationCampaign entity as suggested in comment:21?

PS: There is no end date.

i noticed that. but there really should be, right?

The campaign always ends when the goal is reached, albeit not automatically. A new campaign is started on the trigger.

where does the data for the campaign come from? is the old one reused?

Currently you can't even check if you donated.

keeping the campaign a non-object certainly won't help to change this. ;)

Only if the donation is in the last 25 results it's highlighted. Do we need to take this into account? That's something completely different.

i agree. but the groundwork could (should?) be done while allowing the start date and goal to be set in the interface.

Well, I guess we need a place to define requirements for a feature. This ticket isn't a bug report.

hm.. looks at ticket type and wonders. ;) changed.

I like to point out that this functionality is for exactly one person (at most the BoD).

at the moment, yes. but let's give future extensions a solid foundation? that's what make good software architecture i believe. and good software design gives me the kicks, not just reaching a goal on the shortest way possible. if another developer looks at the code and thinks "wow, nice solution", that's already worth for me to go the extra mile. but then again, that's my personal approach, knowing that my code is public and for example people that hire me will look at it. bla bla bla, ok, i am stopping.. ;)

comment:32 in reply to: ↑ 31 ; follow-up: Changed 6 years ago by shevek

would you be terribly offended if i rewrite this with a DonationCampaign entity as suggested in comment:21?

Yes for two reasons. 1st one is that I want to learn something from that if we really have to do it. 2nd is that we really shouldn't do it.

The campaign always ends when the goal is reached, albeit not automatically. A new campaign is started on the trigger.

where does the data for the campaign come from? is the old one reused?

That was an update in the code till now. So no reuse, no nothing. And a release had to happen shortly after the GA.

Currently you can't even check if you donated.

keeping the campaign a non-object certainly won't help to change this. ;)

Keeping it a non-object will not hinder a reimplemtation either.

at the moment, yes. but let's give future extensions a solid foundation? that's what make good software architecture i believe.

There's another principle saying: You ain't gonna need it.

Do we want to waste time on this while we have critical tickets and the improvements new feature for that we lay foundations will be in welen and the feature will probably look completely different when we finally want to do it?

comment:33 in reply to: ↑ 32 Changed 6 years ago by jsfan

Replying to shevek:

would you be terribly offended if i rewrite this with a DonationCampaign entity as suggested in comment:21?

Yes for two reasons. 1st one is that I want to learn something from that if we really have to do it. 2nd is that we really shouldn't do it.

I'm a bit undecided who to follow here. Om the one hand I share Meinhard's passion for clean code on the other hand we have already conceded that Rox is beyond redemption and probably need to be a bit pragmatic about some things.

At the moment, I have a slight tendency towards Meinhard's suggestion. The reason for that is that it is more Symfonyish which means we can possibly keep the concept very similar when re-implementing in Symfony. On the other hand, I feel that there is not really enough known about Welen design to know if it makes sense to worry about this. Our bundle and thus entity structure could end up looking very different.

I am willing to accept the code as is (provided it passes testing) but would not object to design improvements, either.

comment:34 Changed 6 years ago by jsfan

Please make sure that there is a correct link to this tool in the /bw menus as well.

comment:35 follow-up: Changed 6 years ago by crumbking

  • I get a fatal error here:

http://bw/donate/list

Fatal error: Call to a member function getUsername() on a non-object in /home/crumb/webdev/bw/build/donate/templates/donate_list.php on line 52

  • while adding a donation done in the past it won't show up in the list after editing
  • older entries in the list(which I inserted manually in the DB before while) don't have a "edit" button

comment:36 in reply to: ↑ 35 Changed 6 years ago by shevek

Replying to crumbking:

Fatal error: Call to a member function getUsername() on a non-object in /home/crumb/webdev/bw/build/donate/templates/donate_list.php on line 52

The predecessor of that line calls $m = MOD_member::getMember_userId($T->IdMember?); So that doesn't return a member in that case. Could you please check your database if the entry is correct?

  • while adding a donation done in the past it won't show up in the list after editing

In which list? In the treasurer tool only entries that are inside of the current campaign are shown. In the donate/list they should be shown according to a comment I read that the treasurer always sees all entries.

  • older entries in the list(which I inserted manually in the DB before while) don't have a "edit" button

Right. We had a discussion off list and ticket to change that.

The attached patch would fix that. Please test locally.

Changed 6 years ago by shevek

Allow editing of all entries in the donation list

comment:37 Changed 6 years ago by jsfan

  • Status changed from local_testing to to_alpha

Please keep testing locally if you don't have the necessary permissions to test on alpha.

comment:38 Changed 6 years ago by jsfan

  • Status changed from to_alpha to testing

comment:39 follow-up: Changed 6 years ago by crumbking

  • with started campaign (1600 Euro and start date July 2013) the bar is not visible on the start page.

comment:40 follow-up: Changed 6 years ago by crumbking

  • we have two "treasur" rights on www now. let's fix that
  • campaign date and on/off startpage switch should be independent

comment:41 follow-up: Changed 6 years ago by crumbking

still a fatal error with treasurer rights

Fatal error: Call to a member function getUsername() on a non-object in /var/rox/deployment/alpha.bewelcome.org-d4aeb0f/build/donate/templates/donate_list.php on line 52

comment:42 Changed 6 years ago by pablobd

While trying to give Treasurer rights in http://www.bewelcome.org/bw/admin/adminrights.php I fing 2 treasurer items in the rights list, same here: http://www.bewelcome.org/bw/admin/adminrights.php?action=helplist

comment:43 Changed 6 years ago by jsfan

Yes, there was already a right "Treasurer"...

INSERT INTO `rights` (`id`, `created`, `Name`, `Description`) VALUES (22,'2007-11-25 17:16:56','Treasurer','This Right is for BV treasurer, it allow to see more details on the donations page');
INSERT INTO `rights` (`id`, `created`, `Name`, `Description`) VALUES (32,'2013-02-18 10:00:30','Treasurer','This right enables the treasurer to keep the donations bar shown on /donate to be (more) accurate by adding bank transfers to the database.\n\nOnly one level (10) needed (as there\'s only one treasurer) and scope should always be \"ALL\".');

Do we drop the new one again then?

comment:44 in reply to: ↑ 39 Changed 6 years ago by shevek

Replying to crumbking:

  • with started campaign (1600 Euro and start date July 2013) the bar is not visible on the start page.

Hm. Sounds reasonable if the campaign only starts in the future. Need to check if I implemented that though ;-)

comment:45 in reply to: ↑ 41 ; follow-up: Changed 6 years ago by shevek

Replying to crumbking:

still a fatal error with treasurer rights

As already said check if your table content is consistent. The rights do not have anything to do with this.

comment:46 in reply to: ↑ 40 ; follow-up: Changed 6 years ago by shevek

Replying to crumbking:

  • we have two "treasur" rights on www now. let's fix that
  • campaign date and on/off startpage switch should be independent

Why? The given date stays in the database and the donation bar on donate still accumulates the info.

Regarding start date in the future I see a donation bar on the personal start page. But I don't get one on /donate.

comment:47 in reply to: ↑ 45 ; follow-up: Changed 6 years ago by crumbking

Replying to shevek:

Replying to crumbking:

still a fatal error with treasurer rights

As already said check if your table content is consistent. The rights do not have anything to do with this.

Well it's the live database. I tested on alpha with treasurer rights (got them from Pablo for testing) The error is on the last column of the table. (which is hidden without treasurer rights) As the error seems to be the same as in the comment section of the profile I guess (without looking into code) it happened after your changes in the comment page.

What's really wired is that I have now full rights on all tools while Pablo granted me treasurer rights. I even have access to the rights tool and could play evil. Sounds like a security bug for me.

comment:48 in reply to: ↑ 46 ; follow-up: Changed 6 years ago by crumbking

Replying to shevek:

Replying to crumbking:

  • we have two "treasur" rights on www now. let's fix that
  • campaign date and on/off startpage switch should be independent

Why? The given date stays in the database and the donation bar on donate still accumulates the info.

Because in future we might start a new campaign without activating the bar in the startpage. Reason could be we don't want be so persistent with the money begging because we might have enough members who donate via donate page. Or we might decide let's wait how donations go and activate in the middle of the year. So I would say a little checkbox with on/off startpage would do it. Independent of the campaign.

Last edited 6 years ago by crumbking (previous) (diff)

comment:49 in reply to: ↑ 47 Changed 6 years ago by shevek

Replying to crumbking:

Well it's the live database. I tested on alpha with treasurer rights (got them from Pablo for testing) The error is on the last column of the table. (which is hidden without treasurer rights) As the error seems to be the same as in the comment section of the profile I guess (without looking into code) it happened after your changes in the comment page.

That column just shows the user name of the donor, using a totally weird module that I didn't know existed till yesterday that doesn't seem to be connected to any rox code.

As you're treasurer now :-) Could you check how www behaves in that case?

What's really wired is that I have now full rights on all tools while Pablo granted me treasurer rights. I even have access to the rights tool and could play evil. Sounds like a security bug for me.

That's a different ticket, but: I just imported the rights table that Christian put online today and gave one member treasurer rights. Everything's fine there. Could you check which rights the rights tool says you have?

comment:50 in reply to: ↑ 48 ; follow-up: Changed 6 years ago by shevek

Replying to crumbking:

Why? The given date stays in the database and the donation bar on donate still accumulates the info.

Because in future we might start a new campaign without activating the bar in the startpage. Reason could be we don't want be so persistent with the money begging because we might have enough members who donate via donate page. Or we might decide let's wait how donations go and activate in the middle of the year. So I would say a little checkbox with on/off startpage would do it. Independent of the campaign.

Works perfectly by just starting a campaign and directly stopping it again :)

comment:51 Changed 6 years ago by crumbking

Update: While Christian removed the additional "treasurer" right I have only access to the treasur tool and all tools I had before on alpha.

+ accepeter right, strange. rox I love you ;-)

@shevek: I see on alpha and www the same table without any styles. Only difference on www I can't see the error message in the column: "For treasurer eyes only" ->last entry

I will import the rights table locally now.

comment:52 Changed 6 years ago by shevek

@crumbking: As treasurer you should see all entries while I only see 25.

Does the notice read trying to call something on a non-object or something else?

The code returns a 0 (zero) if no user with the given id is found. And as that isn't checked it's likely to throw a notice...

Last edited 6 years ago by shevek (previous) (diff)

comment:53 Changed 6 years ago by crumbking

Alpha:

12/09/14
10.00
Via paypal Completed
Unknown country
Fatal error: Call to a member function getUsername() on a non-object in /var/rox/deployment/alpha.bewelcome.org-d4aeb0f/build/donate/templates/donate_list.php on line 52

Probably there was no username.

comment:54 Changed 6 years ago by shevek

Just tried that here. With a bogus member id in the donations table I get the same error message.

Commit to fix the notice: http://gitorious.org/bewelcome/rox/commit/a063d1efb5bcb5967226813f6e66dbd59183d2a5

comment:55 in reply to: ↑ 50 Changed 6 years ago by crumbking

  • Status changed from testing to needs_work

Replying to shevek:

Replying to crumbking:

Why? The given date stays in the database and the donation bar on donate still accumulates the info.

Because in future we might start a new campaign without activating the bar in the startpage. Reason could be we don't want be so persistent with the money begging because we might have enough members who donate via donate page. Or we might decide let's wait how donations go and activate in the middle of the year. So I would say a little checkbox with on/off startpage would do it. Independent of the campaign.

Works perfectly by just starting a campaign and directly stopping it again :)

You are right. A logout/login did it. We might want to mention that in the notice after saving... I guess a new treasurer won't get that ;-)

PS: donate/list: works now. great :-)

comment:56 Changed 6 years ago by crumbking

  • Status changed from needs_work to to_alpha

comment:57 Changed 6 years ago by shevek

Change status to testing as obviously deployed on alpha.

comment:58 Changed 6 years ago by shevek

  • Status changed from to_alpha to testing

comment:59 Changed 6 years ago by shevek

@crumbking: Could you please test this and close if appropiate?

comment:60 Changed 6 years ago by crumbking

there are several issue & comments:

  • old entries have no edit button (editing not possible)
  • bank account balance shows surname / name the tool asks for username and checks DB, better: free text field to add/edit surname / name
  • comment section should be availibe via add/edit
  • use systemcomment column for tracking info: "Added /edited by USERNAME"

comment:62 Changed 6 years ago by shevek

I agrred with crumbking to postpone the open points to a later release therefore I suggest to split the issues to a new ticket and close this one as fixed.

comment:63 Changed 6 years ago by shevek

Added missing translations.

Created ticket #1956 ('Improve treasurer tool').

Closing this as fixed.

comment:64 Changed 6 years ago by shevek

  • Resolution set to fixed
  • Status changed from testing to closed
Note: See TracTickets for help on using tickets.