OAUTH2-214 Semantic versioning #118
Conversation
…e only if they resolve to the same ScopeGrants
…nd may not support removeIf() operation
…ScopeAliases() so it is also persisted as a sorted list + Ignore blank scope aliasees for optimized persistence
Implement the logic in the `update` method. This is more easily backporteable and also we don't make other service responsible of the state of this service
…e.updateScopeAliases() so it is also persisted as a sorted list + Ignore blank scope aliasees for optimized persistence" This can't depend on the caller. It is part of the service API to store it sorted
|
To conserve resources, the PR Tester does not automatically run for every pull. If your code changes were already tested in another pull, reference that pull in this pull so the test results can be analyzed. If your pull was never tested, comment "ci:test" to run the PR Tester for this pull. |
|
ci:test:sf |
|
ci:test:relevant |
✔️ ci:test:sf - 1 out of 1 jobs passed in 2 minutes 30 seconds 566 msClick here for more details.Base Branch:Branch Name: master Sender Branch:Branch Name: pr-577-tomas-master 1 Successful Jobs:For more details click here. |
liferay-continuous-integration
added
ci:test:relevant - success
and removed
ci:test:relevant - pending
labels
|
I am wondering if it is confusing to have updateApplicationScopeAliases and updateScopeAliases() method in the two respective services. They have very similar parameters, and the only difference is the former will update the OAuth2Application with the modified date & foreign key. The more I look at it I feel the one in OAuth2ApplicationLocalService should just receive the foreign key and no List. Essentially moving the service orchestration out of the service layer and into the MVCActionCommand. Also I am wondering if we really need applicationId when creating OAuth2ApplicationScopeAliases. I mean multiple OAuth2Applications can share them? The only benefit I see right now is making it easier to tidy up / delete them when an OAuth2Application is deleted. @topolik? |
|
On second thought, I see the OAuth2ApplicationScopeAliasesLocalService doesn't have a remote counterpart, so maybe there would be no confusion between the similarly named methods. OAuth2ApplicationScopeAliasesLocalService is just an implementation detail in other words. |
liferay-continuous-integration-hu
force-pushed
the
master
branch
from
3515cd4 to
726fc07
Compare
stian-sigvartsen
force-pushed
the
master
branch
from
726fc07 to
a469b06
Compare
liferay-continuous-integration-hu
force-pushed
the
master
branch
from
a469b06 to
9627691
Compare
/cc @topolik
This is how I believe we should do it in master, with the new update method.
Let me know your thoughts or if I broke something.