[Barry]

Hi huckster512,

Under access control, when I block subscribers (from Roles to block) they are still able to add/edit events from the admin bar. When I check Block access to WordPress Admin, they are not able to add/edit events, but it totally removes the admin bar.

The Block access and Roles to block settings work together. In other words the roles you have chosen to block will not be blocked until the Block access setting is enabled.

So if we look at your second observation:

when I block subscribers and tick Block access to WordPress Admin, if user is logged in as a subscriber and goes to the direct link- http://www.site-url.com/events/community/add, said user is able to add an event.

That is by design and is the intended behaviour here – we aren’t stopping them from submitting events via the add events form – we’re just blocking them from entering the admin environment.

So to return to your question:

So what I need is to block the subscribers but not hide the admin bar.

It probably is possible but would be tricky and isn’t something we can really help with – you’d need either a good level of WordPress development know-how to put this together or else would need to engage a developer/designer to do it on your behalf.

Thanks!

[Barry]

Hi flaviarusso, if there are plugins out there that can do that I’m afraid I am not aware of them. Can you provide some background on why you want to do this?

[Barry]

No problem, I hope you get on track 🙂

[Barry]

I’m afraid not, Inventory levels will continue to be set at ticket level (you will not be able to “pool” inventory for an event between all of its tickets, in other words).

We still have this on our system as a proposed feature request – so it may make it into a future release – but I’m afraid it definitely isn’t going to be in WooTickets 2.0.

[Barry]

OK, thanks for the insight. WooTickets itself does not currently facilitate this and so posting on UserVoice would be worthwhile to help us guage the level of support for this (yours is so far the only time this has cropped up) – but I’ll definitely go ahead and log this as a possible feature request.

[Barry]

Hi Chris,

1) How do we know if something was done incorrectly in the database?

The best sign is that operations are progressing as normal.

You could definitely monitor your server’s error logs though for some extra assurance, and/or bring in a dev with particular experience in WooCommerce if you needed a manual audit of this.

2) I did remove the tickets from several events using the steps you gave, however, when I got back to the Event Summary for one of the events, the count is incorrect.

I suspect this may relate to an arguably unusual facet of WooCommerce, in that if product orders are deleted or manually added to the inventory count is not adjusted – if that’s so you would need to make the necessary adjustment manually through the product editor.

Does that help with this?

[Barry]

Hi xg5tat,

Great question.

Currently I don’t believe that’s possible without some custom development work – but it would be great to hear more about the rationale for this (as we haven’t seen this request before and it can often be useful for the team to have some context).

Is this to meet legal requirements of your own business? Are you acting as a proxy for other clients who are actually liable for these taxes?

Definitely could be worth posting this on our UserVoice page – that would give us an idea of how much support there is for this generally since other users can show their support, too:

https://tribe.uservoice.com/forums/195723-feature-ideas

Thanks!

[Barry]

No problem, I hope it helps ( even if it just forms the basis of a completely new approach) 🙂

[Barry]

Possibly, yes.

If you’re happy with the workaround you created though that’s the main thing (or if not there are some further troubleshooting steps we can run through to investigate if there is a conflict with your theme or another plugin – however it may be it’s easiest to leave things as they are so long as you made the change safely, ie by following the steps in our Themer’s Guide).

[Barry]

OK, that’s quite a long and involved thread so it’s definitely possible I’m missing something, but I don’t think I edited your custom events/single.php template (and am not seeing references to that in the other thread).

If you can highlight the actual change I suggested please do and I’ll take another look.

[Barry]

That’s possible, though that particular scenario isn’t something I’ve come across before – but it could definitely be worth deactivating/reactivating and otherwise mimicing the steps you described – thanks 🙂

[Barry]

Hi Alain,

I’ll just check in with another team member and see if there is an existing snippet somewhere that handles this.

Barry

[Barry]

My pleasure – and sorry for the delay while we worked toward the solution 🙂

[Barry]

Nabha – following from a slightly-related topic, you could also give the following workaround a whirl: take a look at this code (it’s a snippet you could drop in to your theme’s functions.php file) and used as-is it makes tickets visible in the WooCommerce storefront and changes their type to virtual/downloadable automatically.

That isn’t quite what you want, but you can see at the bottom of the snippet where those properties are defined. In your case you might not want that (and could remove/comment out the relevant lines) but you could try setting the tax_status and tax_class properties instead:

new Adapt_WooTicket_Type(array(
'tax_status' => 'non-taxable',
'tax_class' => 'untaxed',
));

Note that you may need to play around with those values (tax_class in particular) – I’m simply making an educated guess and you may need to check in with the boffins over at WooThemes to figure out what the actual values should be in your case … this is just a possible starting point you can try.

[Barry]

Hi Tim – did you need any further help here / does J-P’s solution work for you?

[Author]

Posts