3scale/issues-test — Issue #438: extra-fields (and model fields) should be editable and visible on setting
Author: HakubJozak
Created: 2012-02-13 17:54:06+00:00
State: open

the provider should be able to set whether a field on the models (account/user/application) is a) visible to the buyer, and b) readonly. Providers can always see and edit, but the buyer no.

This affects the extra fiels and the specification on the application.yml, get rid of that too.

Tasks
- create fields ui
- move everything to instance level
- remove old extra fields remanents like app.yml and cap tasks for it
- validations and old records
- check extra_fields javascript ask jakub
- take user password and password_confirmation out of extra_field? method
- fixed views
- fix form builder
- form builder validations
- (re)move handle_extra_fields_for and set_extra_fields_for (to model)
- move hack from provider to Provider.fields_definitions properly
- write tests
- hide field from buyers
- edit for buyers if allowed
- ISSUE buyer user details show too many fields
- define db_columns available for providers to define (e.g. they should not access cinstance.plan_id)
- tests for FieldsDefinition model
- on deploy: seed the fields for existing enterprise servers
- unify labels on app edit, account edit
- check signup page for hidden and non editable fields
- make sure choices fields do not accept other values
- check pos on every buyer view
- replicate fields scenarios for providers
- users index for buyers shows fields, check hardcoded fields all over
- add validation to fields on db made required with fields_definitions
- double check fields_definitions boolean combinations i.e. required fields and required set to false
- country field is special given its internal_functionality
- should provider has validations when updating buyer? => ask josep
- choices should only accept values in choices
- do cucumbers for all views touched
- check FD.create_all label for org_name
- classes inject themselves into FD.targets
- check js on signup (app new, account edit) forms on every server to move them to the signup layout
- check contents of existing signup layout and js behaviour
- TODO profile arrays of constants values (CompanyTypes, CustomerTypes)
- on deploy do account legal_address required by hand
- write email about Profile, config valid obsolence y layouts
- can a hidden or read_only field be forged by buyer?
- country scenario since it is a special case

https://www.pivotaltracker.com/story/show/17615915