Skip to content
This repository has been archived by the owner on Nov 23, 2021. It is now read-only.

#622: implemented (added AccessControlConfig) #631

Merged
merged 2 commits into from
Jun 29, 2018
Merged

#622: implemented (added AccessControlConfig) #631

merged 2 commits into from
Jun 29, 2018

Conversation

hohwille
Copy link
Member

@hohwille hohwille commented Jan 30, 2018

This PR implements #622:

  • Provides a new class AccessControlConfig that implements AccessControlProvider. It can therefore be used as a drop-in replacement for access-control-schema.xml and AccessControlProviderImpl.
  • Includes an example config and a JUnit test that verifies that all is working as expected.

Feedback to improve the config "API" is most welcome.
I did not (yet) deprecate the code that may not be used anymore such as AccessControlProviderImpl and AccessControlSchema, etc.
First I want to await feedback from others but I am quite convinced that the old XML stuff is kind of odd compared to the new approach. We still have issues with referencing and code-generation from the XML. All solved as a single source of truth with the new approach where everything is in one place.

Copy link
Member

@maybeec maybeec left a comment

Choose a reason for hiding this comment

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

I like the idea of declaring perimission constants directly in Java. The XML approach was kind of an old design decision based on common experiences, which should be revised.

IMHO you can even deprecate the old stuff or even remove it if we go to EVE release. However, than the currently generated constants from the XML spec should be easily usable by the new approach with minor adaptions.

AccessControlConfigSimple.PERMISSION_FIND_STAFF_MEMBER, AccessControlConfigSimple.PERMISSION_FIND_TABLE);
assertThat(readMasterData.getInherits()).isEmpty();

// and when
Copy link
Member

Choose a reason for hiding this comment

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

"and when" Anti-pattern. Please seperate tests to let them as of just one reason (in theory).

Copy link
Member Author

Choose a reason for hiding this comment

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

Sometimes being a little more pragmatic that the ideal theory is fine for me. I do not see any added value by separating this but I will do as it is faster done than further discussion...

Copy link
Member

Choose a reason for hiding this comment

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

It is always easier to be someone's hero, than later teach him why you did it wrong and he should not.

// then
assertThat(chief).isNotNull();
assertThat(chief.getId()).isEqualTo(AccessControlConfigSimple.GROUP_CHIEF);
assertThat(flatten(chief.getPermissions())).containsExactly(AccessControlConfigSimple.PERMISSION_SAVE_OFFER,
Copy link
Member

Choose a reason for hiding this comment

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

Why do they have to be in order?
I think this should be InAnyOrder as well as below.

Copy link
Member Author

Choose a reason for hiding this comment

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

I am fine with that and will change this accordingly.

@hohwille
Copy link
Member Author

@maybeec thanks for your review feedback.
I have updated and improved the test accordingly. Hopefully everything is fine now.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants