-
Notifications
You must be signed in to change notification settings - Fork 30
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
feat(condo): DOMA-6736 schema MobileFeatureConfig with tests #3662
feat(condo): DOMA-6736 schema MobileFeatureConfig with tests #3662
Conversation
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.
- Is this model will be used only for disabling the ability to send tickets?
- Is there a new domain needed? What about using one of the existing domains (organization, user, resident, ticket)?
- Also, please fix the code according to the linter rules.
apps/condo/domains/settings/utils/clientSchema/MobileFeatureConfig.ts
Outdated
Show resolved
Hide resolved
b965a29
to
5b384fa
Compare
5b384fa
to
453132b
Compare
} | ||
|
||
const MobileFeatureConfig = new GQLListSchema('MobileFeatureConfig', { | ||
schemaDoc: 'Manages availability of some features in mobile application,' + |
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 unclear. It assumes that you have one model per one feature.
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.
MobileFeaturesConfig
?
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.
but google translate says that MobileFeatureConfig is ok)
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.
I think @pahaz means that you will not be able to customize other features using this model. See my questions too.
type: Text, | ||
}, | ||
|
||
ticketSubmittingIsDisabled: { |
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.
Is ticket submission disabled
or is tickets disabled.
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.
Naming the fields like that, I proceeded from a different logic. Now there are 5 fields needed to configure 2 features. When there are 30 fields, finding the right one will be a difficult task both on the client and on the server. Therefore, I write the feature prefix and then the field itself. That is, the feature ticketSubmitting
and then what the field stores. If you change ticketSubmittingIsEnabled
to ticketSubmission
, then searching for all fields related to the ticketSubmitting
feature will be impossible and you will have to manually search for everything.
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.
What about using the same prefix for auxiliary field naming?
}, | ||
}, | ||
|
||
onlyProgressionMeterReadingsIsEnabled: { |
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.
How to be with meter counter overflow?
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.
Didn't understand what you mean. Haven't heard of counter overflow
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.
In this case, the resident will call the organization and they will manually enter the testimony through CRM, after which the resident will be able to submit again
}, | ||
}, | ||
|
||
onlyProgressionMeterReadingsIsEnabled: { |
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.
Is allow only greater then previous meter reading submission enabled :)
(Like others Boolean flags)
pls add description for your pr |
apps/condo/domains/settings/components/ticketSubmitting/OnlyProgressionMeterReadingsForm.tsx
Outdated
Show resolved
Hide resolved
apps/condo/domains/settings/components/ticketSubmitting/OnlyProgressionMeterReadingsForm.tsx
Outdated
Show resolved
Hide resolved
apps/condo/domains/settings/components/ticketSubmitting/OnlyProgressionMeterReadingsForm.tsx
Outdated
Show resolved
Hide resolved
...ndo/domains/settings/components/ticketSubmitting/OnlyProgressionMeterReadingsSettingCard.tsx
Outdated
Show resolved
Hide resolved
apps/condo/domains/settings/components/ticketSubmitting/TicketSubmittingSettingCard.tsx
Outdated
Show resolved
Hide resolved
apps/condo/pages/settings/mobileFeatureConfig/onlyProgressionMeterReadings/index.tsx
Show resolved
Hide resolved
apps/condo/pages/settings/mobileFeatureConfig/onlyProgressionMeterReadings/index.tsx
Outdated
Show resolved
Hide resolved
apps/condo/pages/settings/mobileFeatureConfig/ticketSubmitting/index.tsx
Show resolved
Hide resolved
apps/condo/pages/settings/mobileFeatureConfig/ticketSubmitting/index.tsx
Outdated
Show resolved
Hide resolved
The title has a task. You need to open it task and there is all the context / links / pictures. I think writing the same thing in 100 places is a waste of resources |
3ddbe5b
to
c14a6fa
Compare
aaea781
to
a0becf7
Compare
apps/condo/domains/settings/components/ticketSubmitting/OnlyProgressionMeterReadingsForm.tsx
Outdated
Show resolved
Hide resolved
return { | ||
organization: { | ||
OR: [ | ||
queryOrganizationEmployeeFor(user.id), | ||
queryOrganizationEmployeeFromRelatedOrganizationFor(user.id), | ||
], | ||
}, | ||
} |
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.
Are every employee can read this model (technician staff)? Maybe canReadMobileFeatureConfigs
should appear?
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.
Yes, and I think that's right. The organization
settings page is available to everyone at the moment. Special rights are only used to check editing rights. I think it will be correct to repeat the behavior of the other sections of the organization
settings
const MobileFeatureConfig = new GQLListSchema('MobileFeatureConfig', { | ||
schemaDoc: 'Manages availability of some features in mobile application,' + | ||
' stores data required in disabled state of a feature.', | ||
fields: { |
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 not understandable how auxiliary fields belong to feature (enabled/disabled) areas.
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.
This data is necessary for the mobile application to determine what to display. In the case of the feature of disabling tickets - displaying the desired phone.
If you are describing the full changes that will occur in the mobile app when you disable/enable a feature, it will mean that this place must be maintained when changes are made in the mobile app, otherwise this data source will mislead the backend developer.
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.
What about using the same prefix for auxiliary field naming?
that's how it happens. All fields required for feature management are marked with a prefix. That is why the ticketSubmittingIsDisabled
field is called so incorrectly (from the point of view of the English language). Pahaz asked for some fields, for example, the org phone, which will be reused with a high probability, not to attach to a specific feature, but to leave commonPhone
type: Text, | ||
}, | ||
|
||
ticketSubmittingIsDisabled: { |
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.
What about using the same prefix for auxiliary field naming?
}) | ||
describe('CRUD tests', () => { | ||
describe('accesses', () => { | ||
describe('admin', () => { |
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.
If we decide in the future to restrict access for support users, the tests will not show any errors. For now, we have a separate type of user and have no test for them.
|
||
const hasSubscriptionFeature = hasFeature('subscription') | ||
|
||
const { useFlag } = useFeatureFlags() | ||
const hasMobileFeatureConfigurationFeature = useFlag(MOBILE_FEATURE_CONFIGURATION) |
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.
Looks like I still have the ability to create a model using graphql API directly.
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.
this is true
const hasMobileFeatureConfigurationFeature = useFlag(MOBILE_FEATURE_CONFIGURATION) | ||
const hasTicketSubmittingSettingFeature = useFlag(TICKET_SUBMITTING_SETTING) | ||
const hasOnlyProgressionMeterReadingsSettingFeature = useFlag(ONLY_PROGRESSION_METER_READINGS_SETTING) |
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.
Is every feature controlled by two feature flags combination?
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.
Yes, this is a business requirement. It is necessary that the org manages this itself. But at the same time, we do not want every user to see all the settings. Since we are developing them, not so that they would be turned off, but so that they would be used. This task is a rare case when it is necessary
apps/condo/pages/settings/mobileFeatureConfig/onlyProgressionMeterReadings/index.tsx
Outdated
Show resolved
Hide resolved
apps/condo/pages/settings/mobileFeatureConfig/ticketSubmitting/index.tsx
Outdated
Show resolved
Hide resolved
apps/condo/domains/settings/components/ticketSubmitting/TicketSubmittingSettingsForm.tsx
Outdated
Show resolved
Hide resolved
apps/condo/domains/settings/components/ticketSubmitting/OnlyProgressionMeterReadingsForm.tsx
Outdated
Show resolved
Hide resolved
c8260a1
to
13da42e
Compare
5ea4b04
to
9f8ff61
Compare
apps/condo/domains/common/components/settings/MobileFeatureConfigContent.tsx
Outdated
Show resolved
Hide resolved
apps/condo/domains/settings/utils/MobileFeatureConfigSchemaValidations.js
Outdated
Show resolved
Hide resolved
apps/condo/pages/settings/mobileFeatureConfig/onlyProgressionMeterReadings/index.tsx
Outdated
Show resolved
Hide resolved
apps/condo/pages/settings/mobileFeatureConfig/onlyProgressionMeterReadings/index.tsx
Outdated
Show resolved
Hide resolved
apps/condo/pages/settings/mobileFeatureConfig/ticketSubmitting/index.tsx
Outdated
Show resolved
Hide resolved
apps/condo/pages/settings/mobileFeatureConfig/ticketSubmitting/index.tsx
Outdated
Show resolved
Hide resolved
b578cbc
to
ce9c05f
Compare
apps/condo/domains/settings/utils/MobileFeatureConfigSchemaValidations.js
Outdated
Show resolved
Hide resolved
apps/condo/pages/settings/mobileFeatureConfig/onlyProgressionMeterReadings/index.tsx
Outdated
Show resolved
Hide resolved
apps/condo/pages/settings/mobileFeatureConfig/ticketSubmitting/index.tsx
Outdated
Show resolved
Hide resolved
ce9c05f
to
8b92716
Compare
…d to ticketSubmittingIsDisabled. Rm emergencyPhone field
… for manage access
… onlyGreaterThanPreviousMeterReadingIsEnabled
some optimization on front, rm redundant react state. add tests for support. move FF constants to common/constants/featureFlags. fix schemaDoc for meta
8b92716
to
2ade841
Compare
Why don't you add this config automatically for all organizations? It's a 1 to 1 relationship, why not? |
apps/condo/domains/common/components/settings/MobileFeatureConfigContent.tsx
Outdated
Show resolved
Hide resolved
Co-authored-by: Alllex202 <[email protected]>
* feat(condo): DOMA-6736 schema MobileFeatureConfig with tests * fix(condo): DOMA-6736 change field name from ticketSubmittingIsEnabled to ticketSubmittingIsDisabled. Rm emergencyPhone field * fix(condo): DOMA-6736 fix imports * feat(condo): DOMA-6753 frontend of MobileFeatureConfig * fix(condo): DOMA-6736 schemaDoc of some field of MobileFeatureConfig * fix(condo): DOMA-6736 review fixes * feat(condo): DOMA-6736 added permission canManageMobileFeatureConfigs for manage access * fix(condo): DOMA-6736 rename onlyProgressionMeterReadingsIsEnabled to onlyGreaterThanPreviousMeterReadingIsEnabled * fix(condo): DOMA-6736 replace catchErrorFrom to expectToThrowGQLError * fix(condo): DOMA-6736 use valuePropName * fix(condo): DOMA-6736 add deletedAt filter * fix(condo): DOMA-6736 review fixes some optimization on front, rm redundant react state. add tests for support. move FF constants to common/constants/featureFlags. fix schemaDoc for meta * fix(condo): DOMA-6736 some code improvements * chore(condo): DOMA-6736 fix imports Co-authored-by: Alllex202 <[email protected]> --------
if (user.isAdmin || user.isSupport) return {} | ||
|
||
if (user.type === RESIDENT) { | ||
const residents = await find('Resident', { user: { id: user.id }, deletedAt: null }) |
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.
You need to check others models. We need to get organizations from ServiceConsumer
|
||
const CONTENT_GUTTER: Gutter | [Gutter, Gutter] = [0, 40] | ||
|
||
export const MobileFeatureConfigContent: React.FC = () => { |
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.
Confusing naming. It's look like some guard or some wrapper for feature flag checks.
It will be better to create some wraper or HOC for this task. For example:
const CardsContainer = ...
const CardsContainerWithAccessCheck = addFeatureFlagIsEnabled(CardsContainer, 'MOBILE_FEATURE')
No description provided.