Anti-queue technique detected

[petterroea]

If an applying user suspects he or she is put in a wait list(f.ex if their friends are added but not them), they can delete their application and re-apply to have their name removed from the queue list. There is no way of tracking a users activity application-wise.

My suggestion is a table to track applications posted by participants. it should have the fields userId and groupId, and an entry should be added every time an application is posted. If there is more than one entry for that user, and that group, a warning should show up in the application, alerting the reviewer of a potential person trying to get past detection

[halvors]

This doesn't make any sense. The queue is for actual candidates when the crew is currently full. If it is this way, the problem is not the user but the chief accepting users and thereby bypassing the queue.

[petterroea]

It is being used by chiefs as a way to put certain people aside, maybe because the crew is full, maybe because they want to think over adding said person to the crew.

The point is that you can get out of this queue state, which might in some cases help you get in if the application processor forgets that he put you in a queue in the first place, etc.

[halvors]

Maybe we just should add a max size the crew sp that the chief can set for its crew. Then automatically add people being in a queue to the crew when a spot becomes available?

[petterroea]

I don't think that is a fix. i'd much rather just inform the application processor that "this user has already applied to this crew for this year", or something like that. Basically, it just remembers what you already have applied for.

[halvors]

But again. Problem is that chief's is exploiting the queue functionality. It's a queue (first in first out) not a personal thinkingbox. If they need time to think, just leave the application as it is until they do...

[halvors]

If this is the way the queue function is used, we're better off just removing it.

[petterroea]

Just because it isn't being used the way we want it to doesn't mean we should remove it.

The suggestion to this ticket can also apply to more than just queued applications though. An user could delete his or hers denied application, and re-apply, hoping that they have better luck. A "this user has already applied" feature has many uses.

[halvors]

A fix might be to just allow 1 application per group from a user for this event. There really is no reason why a user should apply twice to the same group (crew).

[petterroea]

I think it should be ok to apply more than once for corner-cases where that is wished, all i want is to tell the application processor that this isn't the first time this user applies for his crew.

[halvors]

Think we already have that. Or at least we inform what other crew's the user has applied for.

But is it really wanted to have more than one application per crew per event. Why would we want that?

Why is everyone wanting "buggy" half implemented solutions instead of a solid one?... And really, if a user should be added to a crew multiplie times during an event, the crew chief is free to add them manually...

[halvors]

This here is excatly the reason that there is so much work finishing the v3 frontend.

To much maybe that, or wait no. Or whatever, maybe we will do this for some special nasty case in the future, which should not be possible at all-logic.

I suggest that such cases should be handled manually, or the first application could be voided in order for the user to search again.

We should have strict rules, and it should be as simple as possible.

[petterroea]

You need to delete and re-apply to abuse this. What i suggest is marking deleted applications with a flag so we can keep track of them, but without them appearing on the website as an active application

[petterroea]

I talked to @dethsanius who has used this feature himself. He says it is more problematic than useful, so he suggests killing it off.

[SindreBrurberg]

Just to add more information on the topic. Since all people you have yet to process already are in a que you don't really need another que. And the people that get a message that they have been put in the que feels like they are not going to get into the LAN. I understand that this might be the intended usecase, but from experience people wont keep the dates saved, even it they get inn. So the reality of it is that, atleast on Infected, it is better to accept more people then to put them in a que. And since Infected never used this feature, it creates more confusion for the users.

[petterroea]

In this case, the user is not told they are put in a queue(IIRC). The queue is there for internal processing purposes. I think back in the warbo days, it was intended to be a place to put people you were unsure of, so they didn't clog the application list(After all, applications give you a notification, so you should either process it with a yes, or put them in a queue).

This is what i remember, but it isn't long until this site has existed for half of my life, so mileage may vary

[halvors]

@petterroea Should we just remove it then? :)

[petterroea]

I think we should rather let the feature be. If a chief uses it is up to them.