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

LC0035 - false positive for fields that aren't enabled #369

Closed
pri-kise opened this issue Nov 27, 2023 · 5 comments · Fixed by #372
Closed

LC0035 - false positive for fields that aren't enabled #369

pri-kise opened this issue Nov 27, 2023 · 5 comments · Fixed by #372
Labels
enhancement New feature or request

Comments

@pri-kise
Copy link
Contributor

We sometimes have fields on tables, that are there only as dummy fields to ensure that TransferFields won't be crashed by creating a field in a sibling table with a different type.

Those fields are having the property Enabled=false;

Those fields shouldn't trigger the info for Rule LC0035.

@pri-kise
Copy link
Contributor Author

The same applies for fields that are Obsolete.

At least with ObsoleteState = Removed;.

I'm not sure what's the best approach for ObsoleteState = Pending;

@Arthurvdv Arthurvdv linked a pull request Nov 27, 2023 that will close this issue
@Arthurvdv
Copy link
Collaborator

Thank you for the feedback, both points are valid and are indeed false positives.

The updated prerelease (same version number) should address both Enabled and ObsoleteState.

For now I'm not validating the value of the ObsoleteState. Just the presence of this property regardless of the value will not raise this rule. This because I'm also not sure what's the best approach for ObsoleteState = Pending should be 🤔

@Arthurvdv Arthurvdv added the enhancement New feature or request label Nov 27, 2023
@jwikman
Copy link
Contributor

jwikman commented Nov 27, 2023

I believe that fields with ObsoleteState = Pending should be treated as normal fields. They can be pending for quite a while, and why shouldn't they behave as regular fields during that time?

@Arthurvdv
Copy link
Collaborator

I don't think there's a right answer for this question. @jwikman, you're absolutely right about the pending for quite a while, but then again this property should already has been set when creating the field? But then we could discusses the use case on creating and new field and obsoleting the old one, then I would indeed like to raise that warning to be honest.

For consistency throughout the LinterCop, where all rules exclude pending and/or removed objects, I would like to apply the same here. It could becoming confusing when obsoleting the whole table versus obsoleting a single field. The LinterCop skips almost all rules when the object has a ObsoleteState property (regardless of the value).

@jwikman
Copy link
Contributor

jwikman commented Nov 28, 2023

True, we've got two scenarios - when we get this new rule on existing code, and when having this rule when writing new code. I was thinking about the first scenario - I would like the warnings on all fields, regardless of ObsoleteState "Pending" or not, when the rule applied on an existing project. :)
And for new code, the ObsoleteState Pending should not be a big issue.

And I think you are right to do the same in other rules (haven't thought through all of them, though 😉).
The only rules that definitely should take the ObsoleteState Pending into account are some of the AL rules (like AL0432)...

I hope I don't get to regret this... 😅

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants