Jump to content

Raffles System


Recommended Posts

Not an issue or bug, just a suggestion.

The way I am using this product it would be nice to see a total # of prizes just like there is a total number of Participants. In the pic below I have 10 Participants and 15 Prizes so it would make sense to me that the # of Prizes be shown here as well. Just like the Participants, the Prizes should increment if I add or subtract a Prize or two.

Just food for thought.

2017-11-24_22-46-04.jpg

Edited by JTHastings
Link to comment
4 minutes ago, Nebthtet said:

That's a pity, I thought more people would ask for that because it seems as a good way to avoid all tax-related problems with charging for tickets. Anyway, then I'll just have to make a workaround with manual transaction accepts via admin panel.

I didn't say I wouldn't. I said that I'd need to hear more clients on this. That's not a move I want to do by myself. Anyway, you can make it in your install by simply editing a file: applications\raffles\extensions\nexus\Item\Tickets.php.

Find:

	/**
	 * @brief	Can use account credit?
	 */
	public static $canUseAccountCredit = FALSE;

Change to:

	/**
	 * @brief	Can use account credit?
	 */
	public static $canUseAccountCredit = TRUE;

I'll take a look if I can make it as a new setting so admin makes their own choice.

Link to comment
43 minutes ago, Nebthtet said:

That's a pity, I thought more people would ask for that because it seems as a good way to avoid all tax-related problems with charging for tickets. Anyway, then I'll just have to make a workaround with manual transaction accepts via admin panel.

Hi, this does sound a a great idea to get around the issues selling tickets.

What plugin are you using to add credits to a member account?

Link to comment

I'll be doing that manually for some users and for new transactions we have donations set up as purchases (i.e. user "buys" a token worth specific price). I plan to reconfigure these "products" so the purchases would add account credit on top of the donator badge user receives currently.

Even if I have to credit them manually we have small enough volume of transactions that it wouldn't pose a problem. Still - if I can automate I will. 

Edited by Nebthtet
Link to comment

Also I have a strange issue: we have defined various currencies on the site (including one virtual). But even if I define various prices for a raffle ticket it tries to charge the customer with proper amount of currency but in improper one (default currency on the site is Polish złoty) but when the customer picks something else i.e. EUR, USD, or SCP (the virtual one) it always tries to charge in Polish złoty.

image.thumb.png.f16bfe7d2f6177318363dc2ad806e97d.png

image.thumb.png.10e4509cb6359aa1fa8d6d6304e0460f.png

Yet on the checkout screen there's PLN (Polish Złoty).

image.thumb.png.687d5f49a18197dffffa4045b8bc57f8.png

Am I doing something wrong or is this an error?

Link to comment

I've made a change today.. probably will fix it because it handles currencies (default or member language/currency). Try it yourself. Open applications\raffles\modules\front\raffles\view.php and find:

			/* Generate the invoice */
			$invoice 			= new \IPS\nexus\Invoice;
			$invoice->member 		= \IPS\nexus\Customer::loggedIn();

Change to:

			/* Generate the invoice */
			$invoice 				= new \IPS\nexus\Invoice;
			$invoice->currency 		= ( isset( $_SESSION['currency'] ) and in_array( $_SESSION['currency'], \IPS\nexus\Money::currencies() ) ) ? $_SESSION['currency'] : \IPS\nexus\Customer::loggedIn()->defaultCurrency();
			$invoice->member 		= \IPS\nexus\Customer::loggedIn();

Let me know if it fixes, otherwise I will take a look closer.

Link to comment

I've found another (maybe) bug: if when creating a raffle you define a price for only one currency then it applies said price to any currency the site supports. It should be impossible to pay in another currency IMO.

Also when editing the price in an existing raffle it forces you to define any price > zero for every currency. You can't fill unwanted currencies with zeroes. Is it intentional?

Link to comment
8 minutes ago, Nebthtet said:

I've found another (maybe) bug: if when creating a raffle you define a price for only one currency then it applies said price to any currency the site supports. It should be impossible to pay in another currency IMO.

Also when editing the price in an existing raffle it forces you to define any price > zero for every currency. You can't fill unwanted currencies with zeroes. Is it intentional?

No, that doesn't work like that and I can't reproduce.

In images:

f3pSs1B.png

 

Pe3WfU5.png

 

8MYtfPR.png

 

If you haven't filled the price in one specific currency, user won't be able to purchase on it.

It's in the video and the screenshots above.

Link to comment
49 minutes ago, Nebthtet said:

OK, now it works just like on your video. Seems the problem has been caused by the fact that the raffle that acted improperly has been created before I made changes to view.php file.

Nope, it is like that since version 1.0.0. Was this raffle created by you? Probably the user entered same value for all currencies. 

Link to comment

No, I've been testing on a different account. And yes, one of the raffles had same prices in every currency. Any chance that the requirement of filling every currency when editing ticket price of existing raffle will be removed? Or please tell me if I can remove it myself somehow. It's strange that such requirement exists on edition when it isn't present when you create the raffle.

image.png.e2112ee31e09d5a42614687c7acfc46f.png

Link to comment
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...