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.

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

Merged
merged 14 commits into from
Aug 12, 2023

Conversation

VKislov
Copy link
Contributor

@VKislov VKislov commented Jul 26, 2023

No description provided.

@VKislov VKislov added ✋🙂 Review please Comments are resolved, take a look, please 🚨 Migrations We have a database migrations here! labels Jul 26, 2023
Copy link
Member

@AleX83Xpert AleX83Xpert left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  1. Is this model will be used only for disabling the ability to send tickets?
  2. Is there a new domain needed? What about using one of the existing domains (organization, user, resident, ticket)?
  3. Also, please fix the code according to the linter rules.

@VKislov VKislov force-pushed the feat/condo/DOMA-6736/mobile-feature-configurator branch 3 times, most recently from b965a29 to 5b384fa Compare July 27, 2023 10:42
@VKislov VKislov force-pushed the feat/condo/DOMA-6736/mobile-feature-configurator branch from 5b384fa to 453132b Compare July 31, 2023 12:51
}

const MobileFeatureConfig = new GQLListSchema('MobileFeatureConfig', {
schemaDoc: 'Manages availability of some features in mobile application,' +
Copy link
Member

@pahaz pahaz Aug 1, 2023

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

MobileFeaturesConfig?

Copy link
Contributor Author

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)

Copy link
Member

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: {
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Member

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: {
Copy link
Member

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?

Copy link
Contributor Author

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

Copy link
Contributor Author

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: {
Copy link
Member

@pahaz pahaz Aug 1, 2023

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)

@Alllex202
Copy link
Contributor

pls add description for your pr

@VKislov
Copy link
Contributor Author

VKislov commented Aug 2, 2023

pls add description for your pr

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

@VKislov VKislov force-pushed the feat/condo/DOMA-6736/mobile-feature-configurator branch 2 times, most recently from 3ddbe5b to c14a6fa Compare August 2, 2023 11:10
@VKislov VKislov requested a review from Alllex202 August 2, 2023 11:11
@VKislov VKislov force-pushed the feat/condo/DOMA-6736/mobile-feature-configurator branch from aaea781 to a0becf7 Compare August 2, 2023 11:38
Comment on lines +33 to +43
return {
organization: {
OR: [
queryOrganizationEmployeeFor(user.id),
queryOrganizationEmployeeFromRelatedOrganizationFor(user.id),
],
},
}
Copy link
Member

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?

Copy link
Contributor Author

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: {
Copy link
Member

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

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: {
Copy link
Member

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', () => {
Copy link
Member

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)
Copy link
Member

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is true

Comment on lines 29 to 31
const hasMobileFeatureConfigurationFeature = useFlag(MOBILE_FEATURE_CONFIGURATION)
const hasTicketSubmittingSettingFeature = useFlag(TICKET_SUBMITTING_SETTING)
const hasOnlyProgressionMeterReadingsSettingFeature = useFlag(ONLY_PROGRESSION_METER_READINGS_SETTING)
Copy link
Member

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?

Copy link
Contributor Author

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/domains/settings/constants.js Outdated Show resolved Hide resolved
@VKislov VKislov force-pushed the feat/condo/DOMA-6736/mobile-feature-configurator branch from c8260a1 to 13da42e Compare August 8, 2023 10:37
@VKislov VKislov requested a review from Alllex202 August 8, 2023 10:37
@VKislov VKislov force-pushed the feat/condo/DOMA-6736/mobile-feature-configurator branch 2 times, most recently from 5ea4b04 to 9f8ff61 Compare August 9, 2023 05:01
@VKislov VKislov force-pushed the feat/condo/DOMA-6736/mobile-feature-configurator branch from b578cbc to ce9c05f Compare August 10, 2023 09:43
@VKislov VKislov force-pushed the feat/condo/DOMA-6736/mobile-feature-configurator branch from ce9c05f to 8b92716 Compare August 11, 2023 08:37
@VKislov VKislov force-pushed the feat/condo/DOMA-6736/mobile-feature-configurator branch from 8b92716 to 2ade841 Compare August 11, 2023 09:35
@Alllex202
Copy link
Contributor

Why don't you add this config automatically for all organizations? It's a 1 to 1 relationship, why not?

@VKislov VKislov merged commit c9eadcc into master Aug 12, 2023
7 checks passed
@VKislov VKislov deleted the feat/condo/DOMA-6736/mobile-feature-configurator branch August 12, 2023 17:58
toplenboren pushed a commit that referenced this pull request Aug 17, 2023
* 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 })
Copy link
Member

@pahaz pahaz May 13, 2024

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 = () => {
Copy link
Member

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')

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🚨 Migrations We have a database migrations here! ✋🙂 Review please Comments are resolved, take a look, please
Development

Successfully merging this pull request may close these issues.

5 participants