Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

support multi tenancy #56

Closed
cbellone opened this issue May 19, 2015 · 3 comments
Closed

support multi tenancy #56

cbellone opened this issue May 19, 2015 · 3 comments
Assignees
@syjer
Milestone
1.5

Comments

@cbellone
Copy link
Member

Create a separate configuration for:

  1. system
  2. event
  3. category

the settings should be applied in reverse order.
In order to differentiate events and avoid name clashing, the events should be named as user/eventName
@cbellone cbellone added this to the 1.5 milestone May 19, 2015
@syjer
Copy link
Member

syjer commented May 30, 2015

Actually, it would be better to have the configuration at the following levels (add organization level):

  1. system
  2. organization
  3. event
  4. category

and the event should be on the organization/eventName url.

syjer added a commit that referenced this issue May 30, 2015
@syjer
#56 initial work for multitenancy, where possible, pass the most prec…
6295b73 
…ise 'context' to the ConfigurationManager
syjer added a commit that referenced this issue May 30, 2015
@syjer
#56 multitenancy work, stripe : pass event to configurationManager
0427698
@syjer
Copy link
Member

syjer commented May 30, 2015

TODO:

  • pass the most precise 'context' to the ConfigurationManager calls where possible
  • implement the db changes (new tables ? modify the current configuration table?)
  • implement the selection logic in ConfigurationManager
  • tests
  • implement admin GUI will be done in a next release
  • check all the use of ConfigurationManager, check if the keys are all used consistently with the same "path".

notes:

  • moving the events under org/event will be done in a separate task, there are too many changes involved.
  • check the use of Configuration.system() . In some case we only need to find the related category/event/org/

syjer added a commit that referenced this issue Jun 26, 2015
@syjer
#56 add configuration tables at event and ticket category level for m…
1f44b0f 
…ulti tenancy support
syjer added a commit that referenced this issue Jun 26, 2015
@syjer
#56 refactor+add org level configuration table
3a5de2d
syjer added a commit that referenced this issue Jun 27, 2015
@syjer
#56 initial work on the server side:
f150d5b 
- add configuration location in the configuration class
- modify related queries
- remove required attribute in html template
syjer added a commit that referenced this issue Jun 27, 2015
@syjer
#56 refactor configuration manager:
cf60346 
- centralize configuration value access in a single method
- rename all system related method
syjer added a commit that referenced this issue Jun 27, 2015
@syjer
#56 misc refactoring
f46c128
syjer added a commit that referenced this issue Jun 27, 2015
@syjer
#56 add selection logic + refactoring
706202a
syjer added a commit that referenced this issue Jun 27, 2015
@syjer
#56 initial tests for configuration manager
c7757a2
syjer added a commit that referenced this issue Jun 27, 2015
@syjer
#56 additional coverage for configuration manager
1065305
syjer added a commit that referenced this issue Jun 29, 2015
@syjer
#56 test configuration manager override mechanism
bc2288e
syjer added a commit that referenced this issue Jul 13, 2015
@syjer
#56 align all the configuration manager call to the same configuratio…
d72a5d9 
…n path
@syjer
Copy link
Member

syjer commented Jul 13, 2015

The backend is done.

@syjer syjer closed this as completed Jul 13, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@syjer syjer

Labels
None yet
Projects
None yet
Milestone
1.5
Development

No branches or pull requests
2 participants
@syjer @cbellone