-
Notifications
You must be signed in to change notification settings - Fork 5
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.
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
call filters: autogenerate name for multi-tenancy purposes #401
base: master
Are you sure you want to change the base?
Conversation
1c854f8
to
35f3184
Compare
This change depends on a change that failed to merge. |
recheck |
Build failed.
|
Build failed.
|
Build failed.
|
b9d6385
to
44eb037
Compare
Build failed.
|
Build failed.
|
Build succeeded.
|
2b1d8b8
to
60775c9
Compare
Build succeeded.
|
60775c9
to
3f4ac46
Compare
Build failed.
|
recheck |
Build failed.
|
# NOTE(afournier): we use a UUID as if it was the callfilter UUID but it's not | ||
# Call filters do not use UUIDs yet |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it be hard to add the UUID column right now? This would avoid a painful migration (i.e. parsing names to get the UUID) later on when we do add the UUID column.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's another ticket completely. Call filters are far from being the only resource still using an integer ID.
It's also hard, requiring changes in function keys, fallbacks, etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
And how about adding the column uuid
but keeping the id
as primary key, only ensuring that the uuid
is unique? That way we have the uuid
in the database, we can use it for the callfilter name and the primary key migration id
-> uuid
will be easier.
3f4ac46
to
5dbc2a0
Compare
Build succeeded.
|
yield s.check_bogus_field_returns_error, url, 'name', 123 | ||
yield s.check_bogus_field_returns_error, url, 'name', None | ||
yield s.check_bogus_field_returns_error, url, 'name', True | ||
yield s.check_bogus_field_returns_error, url, 'name', {} | ||
yield s.check_bogus_field_returns_error, url, 'name', [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have any test covering the deprecated way by sending only a name? We still want to support that use case and it needs at least 2 tests (one for success, one for error/invalid data)
They do not use UUIDs yet
5dbc2a0
to
2312375
Compare
Build failed.
|
2312375
to
e064f14
Compare
e064f14
to
e53ede0
Compare
Kudos, SonarCloud Quality Gate passed! 0 Bugs No Coverage information |
Build failed.
|
recheck |
Build succeeded.
|
Depends-On: wazo-platform/xivo-dao#224
Depends-On: wazo-platform/xivo-manage-db#203