This comes to my mind while I was writing e2e test for applications. Developers of different applications are highly likely naming their resource with a name which is potentially conflicted with another name in another application which they may not be able to see. It is indeed potential risk and we should allow the name conflicts especially when different application are isolated by access controls.
The more fundamental problem behind this is that we are not using UUID as the entity key, (to my best knowledge)
[ ] Bug
[ ] Feature
[ ] Enhancement
Detailed Description
We should first refactor and use UUID as the entity key in entity store, then provide an mechanisms to check name conflicts only within applications. When access control comes into place, the transfer will be much more smooth.
Context
Possible Implementation
Complexity
[ ] Low - Simple enhancement or bug fix, no architectural changes or refactoring
[ ] Medium - Change requires some thought, but is relatively isolated
[X] High - Significant architectural change or large refactor
Impact
[ ] Low - Annoyance, but does not impact business or functinality
[ ] Medium - Issue can be worked around, but is causing pain
This comes to my mind while I was writing e2e test for applications. Developers of different applications are highly likely naming their resource with a name which is potentially conflicted with another name in another application which they may not be able to see. It is indeed potential risk and we should allow the name conflicts especially when different application are isolated by access controls.
The more fundamental problem behind this is that we are not using UUID as the entity key, (to my best knowledge)
Detailed Description
We should first refactor and use UUID as the entity key in entity store, then provide an mechanisms to check name conflicts only within applications. When access control comes into place, the transfer will be much more smooth.
Context
Possible Implementation
Complexity
Impact
Your Environment