Organisation identification and authorisation

[graphiclunarkid]

So that I can use the Site As an Organisation I want to identify and authenticate myself to the Site

Scenario: invited to use the site Given that I have received an invitation to use the site When I follow the instructions in the invitation Then I am taken to the Questions List

Scenario: returning user Given that I have identified myself to the site previously by following the instructions I received in an invitation When I visit the site subsequently (going directly, without necessarily following those instructions) Then I am authenticated and identified automatically And I am taken to the Questions List

[graphiclunarkid]

Reopening this as @EdwardBetts is currently working on an implementation. I'm not sure why @symroe closed it, but perhaps he can comment, as maybe there's something we've missed that would save us some time?

[symroe]

I think I assumed the feature was quite small. As in, the core of authentication is done and tested in a feature. There are other stories that define the views and other interactions.

So, for example, I didn't do email sending, but the story only says "given I've received an email", so I saw it as out of scope.

Maybe a bit too pure :)

[EdwardBetts]

I'm working on this right now. The candidate_questions project includes two defintions of an Organisation, there is one in the organisations app and another in the prototype app. I don't understand why there are two. My plan is to move the Organisation and organisation authentication from the organisations app to the prototype app. Is this the right approach?

[symroe]

Sorry yes. Prototype is a dead app that I should have killed. I was just sketching with it.

[EdwardBetts]

There are four apps: organisations, prototype, questions and token_auth.

The questions app is empty. Token_auth implements the token authentication scheme. Questions is empty. Daniel and I have been adding features to the prototype app. If prototype is deprecated then we should move our changes elsewhere.

I'm trying to figure out the best code layout. We can have organisations, candidates, questions and answers in the same app, this app would need a name. Alternative we could have a different app for the different kinds of users: admin, organisation, candidate and public. Any thoughts or preferences?

[symroe]

Django way would be to have lots of tiny apps. I made organisations and token_auth, and organisations contains the logic for authentication at the moment, plus the feature test.

Sorry for not removing the prototype.

[EdwardBetts]

I show a view with the details of an organisation and questions with a form to add another question:

http://questions.campaignreply.org/organisation/1

It isn't total clear to me how and why this should be split up into multiple apps.

[symroe]

It's generally good practice to make small apps.

I normally decide on this by grouping models together, and then figuring the rest out in the view layer.

If your example, organisation/1 is clearly getting an organisation object, so I would see it as living in the organisation app, importing the question ModelForm from the questions app. The organisation's questions will be on the questions_set property of an organisation, so listing them doesn't require an import.

[symroe]

However, I'm not going to be working on this iteration. If you find it easier to create a single large app then go for it – I can split them up later.

[graphiclunarkid]

Is it now the case that the prototype app is obsolete? If so, would anyone mind if I removed it?

Am I right in thinking the code for the static parts of the site (e.g. the homepage) now lives independently of any app? Should it?