GSoC: Gentoo Recruiters web app summary

2010/08/19 at 9:02 pm (2010, GSoC 2010, Planet Gentoo, WebApplication)

Coding for Google Summer of code has ended on Monday so here is a quick overview of what application can do. It’s pretty basic web application, but should do the work in the beginning I’ll continue working on it so some shiny features I (and not only I) wanted in the application shall get here in the future.

Users

Each user in application has a role. Role can be guest, recruit, mentor or recruiter. There are also two groups with additional permissions: project leads and administrators. Every role has different permissions. User who is not logged in is guest, who can only view some questions and read question descriptions. After creating account user will be recruit or mentor. To be mentor after registration user should use OpenID https://dev.gentoo.org/~nick to register. Recruiters can promote recruits to mentors and demote mentors to recruits. Administrators can demote recruiters to recruits or mentors and promote recruiters to administrators. User must be recruiter to be administrator.

Mentors and recruiters must be Gentoo developers for at least 6 months so application requires them to provide their nicks. Application can check if mentors provided nick of Gentoo developer and if developer with this nick is with Gentoo long enough.

Application can also fetch list of (sub)*project leads from gentoo.org and mark users who are project leads as project leads.

Questions

Any signed up user may create a question. Questions created by administrators are public: all users can view them and answer them. Questions created by non-administrators are private (or suggested) questions: only creator and recruiters can view those questions. Administrator can approve suggested question and then it becomes a public question.

Questions belong to categories and groups. It probably could use a better wording to avoid confusion (as I explain below they are quite different things but names may be confusing).

Recruiters tell users questions in which categories they should answer. They do so by adding relationships between users and categories.

Question in group are alternative questions – user should answer only one question from every group. Application choses randomly question user should answer from every question group. Guests can’t see grouped questions – but they can see description of group (so they can prepare to answer question). Recruits can see only those grouped questions they should answer. Mentors can see grouped questions their recruits should answer. Recruiters can see all questions.

Question can have content of one of three types:

• Text questions. recruits write their answers. Recruiters and mentors then check answer. Mentor of recruit who gave the answer can make comments to help recruit improve answer. Recruiters can give reference answers for questions (only recruiters can see reference answers).
• Multiple choice questions. When recruit answers all multiple choice questions [s]he should [s]he will see a message on the home page indicating if all answers were correct or if there was at least one wrong. Application checks if answer is correct by comparing it to reference answers. All multiple choice questions should have reference – if there is no reference answer for question application will assume recruits answer was correct
• Email questions. To answer email question recruit sends email to application. The email should match specified conditions (not visible to recruits).

Email notifications

Application sends email in few cases: When recruit gives a new answer or changes existing answer application sends notification to mentor of the recruit. When mentor comments answer application sends notification to user who gave the answer. When new public question appears application sends notifications to recruits who should answer it.

OpenID

It’s possible to sign up and login with OpenID.

Feedback

When answering questions recruits can express their opinion about documentation.

Permalink 1 Comment

openid        :string

openid_login({ :openid_opts => { :model => User } })

<login-page>
  <form:>

    <labelled-item-list>

      <labelled-item>
        <item-label>OpenID</item-label>
        <input type="text" name="login" id="login" class="string"/>
      </labelled-item>

      <labelled-item if="&Hobo::User.default_user_model.column_names.include?('remember_token')">
        <item-label class="field-label">Remember me:</item-label>
        <input type="checkbox" name="remember_me" id="remember-me"/>
      </labelled-item>

    </labelled-item-list>

    <set user="&Hobo::User.default_user_model"/>

    <div class="actions">
      <submit label='Log in'/>
    </div>

  </form:>
</login-page>

<signup-page>
  <append-body:>
    Or <a href="&openid_login_users_path">sign up using OpenID</a>.
  </append-body:>
</signup-page>

<login-page>
  <append-body:>
    Or <a href="&openid_login_users_path">log in using OpenID</a>.
  </append-body:>
</login-page>

map.openid_login_users 'users/openid_login', :controller => 'users', :action => 'openid_login', :conditions => {:method => :get}
map.complete_openid_users 'users/complete_openid', :controller => 'users', :action => 'complete_openid', :conditions => {:method => :get}