givecampuk / givecrm.admin Goto Github PK

This issue is from the card created by Alastair on the LeanKitKanBan board we were using.

Which charities can I access? Keep this separate from Authentication for maximum flexibility

No description given.

This issue is from the card created by Alastair on the LeanKitKanBan board we were using:

Connection String
Blank database
Apply GiveCRM schema
Apply base data

No description given.

This comment is from Alastair on the LeanKitKanBan board we were using:

Activate a charity's site when the activation link is visited.
Configure subdomain using our default generated "short name"
Charity ID: pass to Core UI for setting up DB connection, etc. Take from activation URL?

This issue is from the card created by Alastair on the LeanKitKanBan board we were using:

IE6 (7?) probably shouldn't be supported.

No description given.

This issue is from the card created by Alastair on the LeanKitKanBan board we were using.

I don't have replication steps, unfortunately. Just this comment from Alastair on the LeanKitKanBan board we were using:

Common membership across charities
Persistent login cookie
Authorization (which charities you can access) is separate

This should be split into specific tasks when we come to it, as I know there are already a couple of guys looking into Auth/Authz.

There are some build artefacts checked in (notably in the Database Project), along with some git merge-produced .orig files.

It is not considered best practice to check NuGet packages in to the repository.

These items should be removed from the repository.

This may no longer be necessary since the introduction to the CRM and Admin site of Twitter bootstrap?

This should have been removed when the functionality was moved to GiveCRM proper.

Create new IIS website [or virtual machine, Azure instance, etc.]

There's some discussion about this not being strictly necessary, if we can tell (via host headers or through the URL) the CRM which database to connect to. This would be preferable, because then requests can be shared across a horizontally-scaled cluster, rather than siloing each charity to their own CRM instance.

No description given.

@nbarnwell commented:

I believe this may already have been done?

This is mostly enforced by the ASP.NET Membership Provider already. It is configured to:

• allow a maximum of 5 invalid password attempts
• require password of at least 8 characters
• require at least one non-alphanumeric character in a password

We need an AJAX-y check on the entered password to ensure it meets the password strength requirements before the user clicks "Sign up".

The PasswordStrengthRegularExpression configuration directive will probably come in useful with taking this feature further.

I don't have replication steps. Just this comment from Alastair on the LeanKitKanBan board we were using:

GiveCRM title
Email field
Password field
Sign in button