We want to have project-based semantic work package IDs. That means when we want to find the project for e.g. the `/wp/<identifier>` route (and all other routes containing work package IDs), we have 3 possible kinds of identifiers which we need to check for:

1. database ID (e.g. &quot;123&quot;)

2. semantic ID based on the current project identifier (e.g. &quot;SCO-5&quot; with a project with current identifier &quot;SCO&quot;)

3. semantic ID based on a previous project identifier (e.g. &quot;SC-5&quot; with a project with historic identifier &quot;SC&quot;)


Options to find work packages:

a) Overwrite `.find` Begin of the insertion(like e.g.End of the insertion Begin of the deletion likeEnd of the deletion `friendly_id` Begin of the insertionoffers to do)End of the insertion Begin of the deletion also doesEnd of the deletion

&nbsp;  Pro:

* easy to use - not controllers etc. need to be adapted, because they already do `.find` on `WorkPackage`

* same as `friendly_id` does on `Project`


Contra:

* maybe unexpected

* `.find` and `.exists?` should have matching behaviour - if `.find` returns a record, `.exists?` should return true. `.exists?` is harder to overwrite correctly, because it has more options (e.g. conditions)


b) Add a new `.enhanced_find` method (the name of the method is up for debate)

Pro:

* we don&#39;t need to overwrite `.exists?`


Contra:

* we need to adapt all controllers (and every future developer creating more controllers that work with work packages needs to use that, too)


c) Extend friendly\_id finder methods to cater for `find` and `exist?` functions