b&w_logo Created with Sketch.
  • Get Started
  • Contact
  • Sign up
  • Sign in

sharks

get started

concepts

features

syntax

 

monkeys

intro

mods

REST API

 

platypuses

github

blueprints

tickets

 

everyone

support

ideas

contact

license

 

 
 

move account info into cards

help edit space_dashboard

Ticket

+status
closed
help edit space_dashboard
+priority
medium
help edit space_dashboard
+tag
accounts
refactor
Wagn 1.13
help edit space_dashboard
+commit
 

+issues

help edit space_dashboard

account info (emails, encrypted pws, etc), are currently in the users table.  We want them in the cards table.

 

+solution

help edit space_dashboard
terminology
Gerry = "accounted card"
Gerry+*account = "account card"
 
simple cards:
*email (exists)
*password (codename: crypted_password)
*salt
*status
 
sample representation
Gerry+*account+*status
Gerry+*account+*email
Gerry+*account+*password 
Gerry+*account+*salt
 
Gerry+*email must retrieve email
 
(all phrases for now)

 

We want to support a general ORM in cards feature as best we can.  It would be nice if we could just use ActiveRecord/Model features directly, for example validations, but Rails features like validations aren't really designed for variations that can be loaded onto the singleton classes as we do for other model extensions that can be specific to Wagn Sets.  That's not so bad since we have a very nice event system that is Set based from the start.  It means moving the validations into events and we don't just get all the standard validation patterns that Rails supports, but that just means a bit more explicit code for those.

So, this is not specific to the account info, but something we might use whenever we want to have "everything in cards".  Say I want to add an ecommerce gem, but I don't want to create a lot of models (external to Wagn, regular tables, not cards).  It seems like there would be significant adapting even with the ORM in cards feature, but this will still do a lot of the adapting from model rows to content in plus cards so the code will be very much the same as with Rails models.

For this specific case, we have already refactored Wagn so that Foo+*account is a card that is directly associated with an external model (User via the Account class).  The migration would simply take each of the fields of the User model that we are keeping (login for example is now redundant) and copy them to the cards:

 

 

 

Should handle:

  • allow user creation even if old email was denied
  • ?

accounts+tickets for item

 

 

help edit space_dashboard

So, this gets rid of the account "extension"?

 

And is dependent on implement triggers?


related to Refactor Out Admin and Account Controllers ?

--John Abbe.....2013-05-06 03:14:48 +0000

definitely related. could fuse. this is the better name, but there's more info on the other one (and the "admin" thing isn't so related). probably not worth cleanup yet...

--Ethan McCutchen.....2013-05-06 03:44:34 +0000

fyi that one's tagged 1.13 (didn't see it at first, cf handle truncated content in labeled view better)

--John Abbe.....2013-05-06 03:55:02 +0000

yeah, I think that was intentional but probably makes less sense now. will change this one. really need to focus on the action api stuff before digging further into this overhaul.

--Ethan McCutchen.....2013-05-06 03:59:06 +0000

We don't really have "extensions" in the old sense anymore. User model is the one remaining exception. We have a base card for this now, the +*account (codename :account) trait. The last part is moving the data accessed in the User model into cards. They will be plussed onto the +*account card, and we are planning a way where for specific traits of the :account trait (:email => *email for example) would look on the +*account card for a plus card first, then search to the parent (left) card.

--Gerry Gleason.....2013-06-11 15:58:38 +0000

 

+discussed in support tickets

help edit space_dashboard