Show all scenarios button is broken for reporting


Website Feedback


The show all scenarios button on the reporting page appears to be broken. When you click the show all scenarios button the drop down is empty.

I've checked this on Safari and Chrome on Mac (Yosemite) and on Windows 7 in Chrome.

Has anyone else noticed this?


It's been broken since Core was made available for reporting. A fix is apparently in the works, but no news on when.


Keolin Portara wrote:

The show all scenarios button on the reporting page appears to be broken. When you click the show all scenarios button the drop down is empty.

I've checked this on Safari and Chrome on Mac (Yosemite) and on Windows 7 in Chrome.

Has anyone else noticed this?

Yes.

Current work-around (if you "own" the reporting #) is to edit the event and add the scenario so that you can select it to report. Of course, if you don't own the #, you can't report it under that Event#.

There has been some discussion about website fixes, but it was also mentioned that there is a concern regarding the ability to report under Event #'s you don't own.

-TimD

Development Manager

TimD is correct, we do not (at this time) intend to restore the ability to add and report on scenarios for an event you are not the owner of. The owner should add the additional scenario via the normal edit functionality of the event. This is less a work around and more using the tool as intended :).


Hey, Cort.

I appreciate all of the transparency you've given us in some of these processes.
Regarding the intent, is there any chance you can elaborate on that further or direct me somewhere where it has been elaborated on?

Why I find it odd:

From what I understand, the reporting set up to both facilitate both game days and convention reporting. For convention reporting, I can see that the tool may actually work as it's for a limited # of scenarios over a limited time, for game days... not so much.

Game days often happen both regularly and irregularly at a specific and generally public venue, such as a game store, where multiple store liaisons may be responsible for scheduling &/or reporting games there over the life of the store. Store liaisons in what I'm understanding is the ideal PFS world, aren't necessarily the person GM'ing all of the scenarios, only scheduling, reporting and coordinating with the store. The reporting over multiple liaisons is where this gets to be a sticky widget.

With the reporting "fix" that was added some time back allowing non-owners to report under a specific store's ID# it allows a liaison to report & edit where needed and keeps a consistent reporting #.

With the current change, what PFS will likely see will be an increasing # of disconnects between what is reported on the Paizo site and what is on a chronicle sheet, which makes folks who try to both play and seem on the up-and-up a bit concerned. This will occur as GMs may correct or turn in reporting sheets late (in some cases very late) or if a coordinator becomes no longer involved in PFS or has limited bandwidth to give to PFS as the person reporting the game will have no option but to report it under another #, nor are they able to correct mistakes which may have occurred at the venue where they are reporting.

Is this disconnect between reporting and the actual chronicle sheets actually "working as intended"? or more "unintended consequences?".
This is not a hypothetical situation, it's happening now, but I was hoping that it would be a temporary glitch, not a "solution" to whatever issue is happening in the background we've been unaware of.

Apologies if I've animated a dead horse and beat it down once more, but I'm just not seeing where the advantage is for either Paizo reporting or the PFS folks in the trenches on this one. If it's purely a "the system can't handle it" issue, I understand - but that's not what seems to be going on.

Thanks again for taking the time to address these concerns, it's appreciated!

-TimD

Development Manager

Hey TimD.

You do know that Event creators can add delegated reporters, correct? If the concern is that the Event creator doesn't want to report all the events created, they can simply add the account email of other individuals involved, and they can do the reporting. That should, I hope, manage most of the use cases you mention.

The problem with the old system is anyone (and I do mean anyone) could report a session on anyone's event. So you could run a game day, and I could come along and report that I ran several scenarios there and my friends all leveled from them. Now I get that the vast majority of folks wouldn't abuse the system in this way, but sadly it only takes a few.

Our goal is to try to makes systems that allow the same freedom (delegated reporters) but in a manner that has at least some basic controls on it to avoid abuse.

Hopefully that gives you some insight on our thinking :)


Cort Odekirk wrote:

Hey TimD.

You do know that Event creators can add delegated reporters, correct? If the concern is that the Event creator doesn't want to report all the events created, they can simply add the account email of other individuals involved, and they can do the reporting.

Indeed I do, that's how I had been reporting on an event created at the venue I had taken over as the store liaison. The issue isn't in the reporting of scenarios that are loaded on the event, it's in the inability to add the scenarios that are actually being scheduled and run as time progresses as well as the inability to edit scenarios which may have been run and reported, but aren't loaded.

Effectively the event creator has become less involved, but all of the chronicle sheets that are being signed and given out use their event code as that's the event code for the venue. From necessity, I've recently been using an alternate event code (whose name in the reporting actually reads "Alternate Reporting") to report those sessions, but if there is ever any comparison between the event code on the Paizo site and those on the chronicle sheet, they won't match. This may be a mountain vs. molehill perception issue - I don't know what Paizo uses the information gained from the reporting system FOR or how often (if ever) it matters that the reporting code doesn't match what is actually on the chronicle sheet. I would hate for it to be an auditing issue at a convention for a player who has done everything right on their end however, and got a character bounced because of a dichotomy between their account and the chronicle.

I'm not sure if it's feasible with the way the system is built, but even a way to "pass off" the "ownership" of an event # might help if there are any other store liaisons who are now or will be in a similar situation in the future. That way the controls that Paizo wants would be maintained (only one person), but it gives a clearer picture of which scenarios were run where and when, and allows for corrections (such as when I mistakenly keyed 03-18 rather than 03-08 under the event for 35571 for 12/11/14, which I'm still unable to correct even though I'm both the GM and the one who reported that session).

If it's not feasible or not a direction Paizo wants to or is willing to go, I understand - I just wanted to make sure that the Powers That Be who make the calls on this understood why and how it was disrupting the reporting on the end-user side of things and what some of possible "downstream" ramifications (mismatched chronicles vs. reporting or wrong sessions that can't be corrected) would be.

Cort Odekirk wrote:
Hopefully that gives you some insight on our thinking :)

It does, thanks much for taking the time to engage in discussing this issue!

-TimD

Development Manager

Ah, OK, I understand your concern better now. It would be... interesting to implement in our current code base, but Org play is scheduled for a ground up code re-examination this year and knowing about this sort of desire is very useful for that point, if problematic in the short term timeframe.

I really need to work on my run on sentences....

Sovereign Court

eah, I just ran into this problem.

Our VC has basically delegated the organizing one one store to me. I make sure sessions get scheduled and such, and people hand me stuff to report. But now I'd first have to get the VC to add the scenario to the event before I can report on it.

It basically limits an event owner's ability to truly delegate.

Development Manager

For the short term, considering making the one store a separate event, with you as the owner. Then you would have full administrative rights.

Sovereign Court RPG Superstar 2009 Top 32, 2010 Top 8

Good, it wasn't just me.

I'd found some Emerald Spire scenarios I'd not reported, went to put them in and couldn't select any scenarios under an event I created. So I created a new event, but can only select Emerald Spire *not* the sublevels.


Here's another problem -

Can not report walk-up to a PFS game till they come to the boards and create a account. This is really bad for conventions as these walk-up might make up over half the table. Plus, these walk-ups might never come to the website and create a account.

This can cause the table not being reported at all as then there's not enough "offical" players to report. Denying both the 'official' players and the GM credit for playing/running that table.

Community / Forums / Paizo / Website Feedback / Show all scenarios button is broken for reporting All Messageboards

Want to post a reply? Sign in.