[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Debconf-team] Final numbers



Richard Darst dijo [Tue, Jun 14, 2011 at 11:10:01PM -0400]:
> > "The deadline for sponsored attendees' registration was May 19, so
> > your changes were not accepted. Contact registration@debconf.org if
> > changes are needed."
> > 
> > So there is some check in place.
> 
> I tried the same, and it seems that only DDs are blocked from
> registering sponsored.  Other debian statuses can still select
> sponsored.
> 
> Perhaps this should be fixed before sending the emails asking people
> to fix stuff.

Oops! That would be very bad indeed. But I really doubt it's the case
(not that I distrust your tests). The check being made is:

      # No more Sponsored Accomodation accepted after May 19 23:59
      if params[:dc_conference_person][:dc_participant_category_id].to_i == 118 and
          old_dc_conference_person.dc_participant_category_id.to_i != 118 and
          Time.now > Time.gm(2011,5,20)
          raise "The deadline for sponsored attendees' registration was May 19, so your changes were not accepted. Contact registration@debconf.org if changes are needed."
      end

Person type (DD/involved/interested/blah) is registered in a different
field (person_type_id).

But, of course, if reality contradicts code, then... there's a problem
with the code. And that'd be my fault.

> I actually think that it is the fact that category (sponsored, etc)
> depends on status (DD, ...) that gets causes a lot of problems.  if
> you change status, category can get reset (or you could lose
> sponsorship).  I can think of other ways this could fail...  But
> anyway, this is what we are left with...

I'm really worried about this assertion. Looking a bit further... I
start to cook up an "ugh" moment. Ok, it seems that (very intuitively
:-/ ) dc_participant_category_id does not refer to the
debconf.dc_participant_category table, but to
debconf.dc_participant_mapping... 

... And there, "sponsored registration" maps to 118 through 122

... So, in short: Richard, you are completely right, and I am
completely embarassed. Fixing this up _now_. We should check logs to
see if there have been requests we have to fix - I have to go
now(ish), so I'm not looking into that detail, but that should be done
right away.

Attachment: signature.asc
Description: Digital signature


Reply to: