Using modified MeetBot

2011/09/30 at 10:54 pm (2010) (, , , , , )

As part of my GSoC project I made some changes to MeetBot. If you want to use it you should:

  1. Install supybot. This should be easy, on Gentoo just
    emerge supybot
  2. Get a copy of modified plugin. You can download it from GitHub. Or if you have git installed you can clone official repository:

    git clone git://git.overlays.gentoo.org/proj/council-webapp.git

    or development repository:

    git clone git://github.com/ahenobarbi/Gentoo-Council.git
  3. Add
    $(sources_directory)/bot/ircmeeting
    to your PYTHONPATH (or link it to directory in which you will run supybot).
  4. Link$(sources_directory)/bot/MeetBotto your Supybot plugins directory. On Gentoo you can do it by executingln -s $(sources_directory)/bot/MeetBot /usr/lib64/python2.7/site-packages/supybot/plugins
  5. Configure supybot. Remember to enable MeetBot plugin:
    supybot-wizard
  6. Configure MeetBot. In directory with your supybot configuration create file
    meetingLocalConfig.py
    and in the file put customized version of (please fix indentation):
    class Config(object):
    # Meeting management urls
    voters_url = 'http://localhost:3000/users/voters'
    agenda_url = 'http://localhost:3000/agendas/current_items'
    result_url = 'http://localhost:3000/agendas/current_items'
    # Credentials for posting voting results
    voting_results_user = 'user'
    voting_results_password = 'password'
    # You must set this - it's turned off by default
    manage_agenda = True

    there are some more options but those above should be enough to get started.
  7. Run supybot and try out the bot:
    supybot $(your_config_name).conf
Advertisements

Permalink Leave a Comment

Need for some signed emails to test Gentoo recruiters application

2010/10/05 at 10:27 pm (2010, GSoC 2010, Hobo, Planet Gentoo, Ruby on Rails, WebApplication)

I did some work on web application for Gentoo Recruiters after end of Google Summer. One thing I (hopefully) finished is signatures validation. To make sure the application works properly I need sample singed emails from various email clients.

To help me testing please create a signed email using your email client and send it to jbartosik[at]gmail[dot]com (or save it and pastebin it if you prefer).  Please use detached/ mime signature. Also feel free to use outdated/fake keys.

Permalink 2 Comments

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

Released hobo-openid gem

2010/08/04 at 6:47 pm (2010, Hobo, Programming, Ruby on Rails, WebApplication)

I released hobo_openid to RubyGems ( here :) ).  It still needs work but is usable. To add OpenID support to your Hobo application install hobo_openid gem and change your application a bit.

Modify user model

First you need to add field storing OpenID to your User model. Open app/models/user.rb and add

openid        :string

field.

Modify users controller

Then add actions that will handle logging in and sign up to your UsersController. Open app/controllers/users_controller.rb and add following line to the controller class:

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

Create OpenID login page

With current version of Hobo it’s impossible to include taglibs in gems (probably it’ll be possible when next version of Hobo comes out), so you will need  to change some pages manually. Create app/views/users/openid_login.dryml with following content:

<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>

Add links to OpenID login page on login and signup pages

Create app/views/users/signup.dryml with content

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

and app/views/users/login.dryml with content

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

Create routes

Add this lines to config/routes.rb:

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}

Permalink Leave a Comment

Recruiters web application – please help testing

2010/08/03 at 7:21 pm (2010, GSoC 2010, Hobo, Planet Gentoo, Programming, Ruby on Rails, WebApplication)

Hello,
please help testing web application I’m developing for Gentoo Recruiters team.

Demo

Here is an instance of the application you can use for testing. If you do please remember a few things:

  • Don’t use your real email. There is no need to. There is no point to.
  • This instance can not send email notifications.
  • I will probably wipe its database from time to time so don’t put anything you don’t want deleted there.

Sources

If you want to read sources or run your own instance of the application you can obtain sources of the application from git repository on overlays.gentoo.org. When running your own instance of application remember a few things:

  • If you start application in ‘development’ mode it will be incredibly slow. You will be able to choose user from drop down list instead of logging in.
  • It’s tested for PostgreSQL and MySQL, probably will work with SQLite.

To get started do following:

git clone git://git.overlays.gentoo.org/proj/recruiting-webapp.git
cd recruiting-webapp
rake prepare:config db=mysql # you can use db=sqlite3 or db=postgres
nano config/config.yml # fill in usernames, passwords and database names
rake db:schema:load
rake gems:install # or `gem install hobo bluecloth`
./script/server -e production

then wait a few second for server to start (at my machine it takes about 10s) and visit 127.0.0.1:3000 .

Permalink 1 Comment

New terminal prompt

2010/06/22 at 7:58 pm (2010, Linux, Planet Gentoo) (, , )

When I was preparing to use Cucumber I watched a screen cast. I saw a cute promt there: it was single-char green happy face if last command was successful (returned 0) or single-char red sad face if it wasn’t. This motivated me to change my own prompt which was default prompt for Gentoo:

login@hostname /full/path/to/current/dir $

It wasn’t bad but it could get really long if I was deep in directory structure and I really know my login and host… My current promt is

current_dir HH:MM :)

If last command was succesful and

current_dir HH:MM :(

if it failed. I changed prompt for just my user by adding to ~/.bashrc

export PS1="\[\e[34m\]\W \[\e[0m\]\`if [ \$? = 0 ]; then
echo \[\e[32m\]\A \:\)\[\e[0m\];
else
echo \[\e[31m\]\A \:\(\[\e[0m\]; fi\` "

And a screenshot so you can compare how much space I’m saving when I’m in some deep directory:

Permalink 4 Comments

OwnedModel module completed

2010/05/10 at 3:50 pm (2010)

Today I finished my OwnedModel module and added owned_module function to remove some more duplication.
module OwnedModel
def create_permitted?
acting_user.signed_up?
end
def update_permitted?
owned?
end
def edit_permitted?(field)
owned_soft?
end
def destroy_permitted?
owned?
end
def view_permitted?(field)
owned_soft?
end
protected
def owned?
owner_is?(acting_user) and !owner_changed?
end
def owned_soft?
owner_is?(acting_user)
end
def must_be_owned
errors.add(:owner, "must be current_user") unless owned?
end
def included
validate_presence_of :owner
end
end
def owned_model(owner_class)
belongs_to :owner, :class_name => owner_class
never_show :owner
attr_readonly :owner
include OwnedModel
end

Permalink Leave a Comment