...
Topic | Description | Creator | Votes | Outcomes | if before debug-log | see comment in https://github.com/Taskana/taskana/pull/2003 | ||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
Rewrite Test in TaskControllerIntTest |
| Invert LoggingAspect blacklisting to whitelisting. | Currently the LoggingAspect works by blacklisting some methods. This has caused some trouble during TSK-1709. Should we change the blacklisting to a whitelisting, so that we don’t get confused when a given JointPoint gets weaved | |||||||||
License header | Sebastian and I have discussed the automatic generation of license header together with our NT expert. | |||||||||||
Extend ProcessEngineRequester for TaskanaAdapter | It would be nice to extend the ProcessEngineRequester, in such a way that we can retrieve more informations about tasks when getting tasks. For example the name of a task. | Extend HistoryEventManagerTest | We could check if there are untested scenarios involving HistoryEventManagerTest. They can be then added to HistoryEventManagerTest. | Getting rid of Thread.sleep | Sonarcloud complains about Thread.sleep (as Code smell). joerg.heffner proposed the idea of using Awaitlity (https://github.com/awaitility/awaitility ) for Taskana-Adapter to get rid of Thread.sleep. We should discuss if this solution is viable for Taskana too. | Yakup Ensar Evli (Unlicensed)Elena Mokeeva (Unlicensed) Norman Schmidt | ||||||
Add a zip-method to our | The zip-method should combine each element of two List as Pair and return it as a List. Example: Proposed piece of code: | Remove AbstractWorkbasketAccessItemQuery and AbstractWorkbasketAccessItemQueryImpl | Both classes are not used anywhere outside. | Use a helper method for creating TaskHistoryEvent in TaskServiceImpl | At the moment, we have the following very similar code snippet in TaskServiceImpl several times.  Should we create a helper method that has the constructor of the TaskHistoryEvent as method parameter? Elena Mokeeva (Unlicensed) | |||||||
Unclear naming for data list in TestFactory methods | We are heavily using the | ‘descriptionIn’ filter option for ClassificationQuery is missing | We only have the option descriptionLike for filtering using the description of a Classification. Are other filter options needed? | |||||||||
Rework Indices? | Currently our Indices are not complete and have to be reviewed again.
| |||||||||||
Unnecessary List | The Implementation of getting a workbasket using a List is unnecessary, because the list has maximum one element.  | James Reynaldi | ||||||||||
Rewrite ServiceLevelHandler | The logic in ServiceLevelHandler can be simplified or/and restructured. For example the usage of helper classes like DurationPrioHolder can be avoided. Wird nach dem 1.4. von Mustapha und Elena angegangen und ein konkreter Vorschlag unterbreitet. |
| ||||||||||
Test for sorting according to two parameters | I couldn’t find test cases for sorting according to two parameters. We should test this. |
| ||||||||||
Don’t set workbasketSummary twice | In createTask method in TaskServiceImpl we set workbasketSummary twice in some cases. |
| ||||||||||
Split CompleteTaskAccTest | CompleteTaskAccTest contains tests for both, completion and claiming. Should we separate the claiming tests from the completion tests? |
| ||||||||||
SqlConnectionRunner Autocommit | Currently we have some logic in jobs like this:
Should we put this logic more top-level? For example directly in the SqlConnectionRunner? |
| ||||||||||
TaskQuery start/end region Comments | What was the reason for introducing this? Do we want to keep it? | Removed region comments | ||||||||||
Rename GitHub repository + organization | we write TASKANA with caps. Our repository name is “taskana”, which technically is not ok. Furthermore our organization on GitHub is called “Taskana”, which is technically also not ok. Should we rename our organization and the repository? |
| ||||||||||
Undefined sorting order by Attachments | Currently the sorting order by Attachment is undefined. E.g. How to handle Tasks with multiple / no Attachments. In order to create a consistent API we have to discuss how we want to handle the sorting in those 2 cases. |
| ||||||||||
Slack Huddles | Slack just released huddles (https://slack.com/intl/de-de/help/articles/4402059015315-Wir-stellen-vor--Slack-Team-Check-in-eine-neue-Art-Live-Audio-Besprechungen-durchzuf%C3%BChren ) I would love to use that feature to create a virtual office. That way we know who is currently active and can interact a little easier. | We don’t want to use Slack huddles (for now) | ||||||||||
Why do we have a dedicated db2 SQL query | Currently the TaskQueryMapper has two implementations of |
| ||||||||||
Rework version management (Might be a misunderstanding from my side) | At this point, we have several versions of the some packages so it’s unclear which is used, because the version is not specified. The version of h2 was not specified, as well as hibernate. It seems to be chaotic, maybe we can somehow structure it? |
| ||||||||||
Decide on parameter names of intervals in TaskQuery, ClassificationQuery etc. | At the moment, some interval parameters are called just “intervals”, and others are called “modifiedWithin”, “createdWithin” etc. Which do we prefer?   |
| ||||||||||
Decide on composed parameter names in Query entities | At the moment, some composed filter parameters are called with their full name (e. g. | Change as discussed on the fly as referenced above | ||||||||||
BLOCKING RELEASE | We have a new module: How should we name it? Holger Hagen (Unlicensed) said that that name could be a little confusing. |
| ||||||||||
Add ‘skipAuthorization’ variable to TaskQuery | Currently, TaskQuery skips authorization checks if accesssIdIn=null. That might be confusing (There was a bug regarding this implementation). Proposal: add a ‘skipAuthorization’ variable. | postponed to TASKANA-201
| ||||||||||
Refactor TestPriorityServiceProvider to be simpler | Currently the | TestPriorityServiceProvider was deleted | ||||||||||
JavaDoc: Referencing getter/setter with @see | our JavaDoc Rules state in 7. b) that we should link our getter and setters together with @see. Currently this is not done anywhere. Therefore we want to discuss this rule. | Rule was crossed out | ||||||||||
JavaDoc: Enhancement for @return of getter methods | Currently the @return tag of our getter methods contains only trivial informations. Can we adjust the rules, so that we can get rid of those trivial informations?
| timebox 30-min and try to remove @return. If not possible use @return The <paramName>.
| ||||||||||
Move Current Release Notes Page | When we create a release while some PRs are not merged yet, their current release notes have to be removed manually. This is an unnecessary step. | We have adjusted the PR template instead. | ||||||||||
Make database limitations visible in Java API | We have database column restrictions for our entities. Should we make them visible in the java api? An example could be the usage of the javax validation API |
| ||||||||||
Aria Label | Aria-label is an attribute on HTML elements to provide text alternatives for users who use assistive technology e.g. screen readers. Currently, it is only used in one component. Should we delete the attribute or add it wherever it is needed? I prefer to be consistent everywhere. |
| ||||||||||
Implement conventional commits | Currently we don’t have a convention of how to write commit messages. We could adapt “Conventional commits” specification which is used widely in projects https://www.conventionalcommits.org/en/v1.0.0/#summary https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional | Mustapha Zorgati Tristan Eisermann Martin Sawilla (Unlicensed) |
| |||||||||
Naming of internal and api classes | Currently we name our variable inconsistently. Sometimes we name Examples:
Should we unify this? |
| ||||||||||
Exception Signature of our Controllers | Currently our REST-Controllers list every Exception they can throw explicitly. Sometimes the list of Exceptions can be multiple lines. Should we throw |
| ||||||||||
application-<database>.properties | Currently we have multiple application property files for each supported database. How do we want to ensure that the other property files are maintained? A different approch is setting the datasource manually and start the database docker containers automatically. Let’s talk about what’s reasonable and which usecases we have to consider | Postponed and to be explained by Mustapha Zorgati
| ||||||||||
Plural arguments in Queries | Currently, some arguments in Queries are in plural (ownerLongNames), and some in singular (attachmentClassificationId). Which one do we prefer? 
| Mustapha Zorgati Yakup Ensar Evli (Unlicensed) Elena Mokeeva (Unlicensed) | We agreed on using the plural form.
| |||||||||
‘descriptionIn’ filter option for ClassificationQuery is missing | We only have the option descriptionLike for filtering using the description of a Classification. Are other filter options needed? | we agreed not to do this now | ||||||||||
Use a helper method for creating TaskHistoryEvent in TaskServiceImpl | At the moment, we have the following very similar code snippet in TaskServiceImpl several times. Should we create a helper method that has the constructor of the TaskHistoryEvent as method parameter? |
| ||||||||||
Remove AbstractWorkbasketAccessItemQuery and AbstractWorkbasketAccessItemQueryImpl | Both classes are not used anywhere outside. |
| ||||||||||
Extend HistoryEventManagerTest | We could check if there are untested scenarios involving HistoryEventManagerTest. They can be then added to HistoryEventManagerTest. | Coverage is better now | ||||||||||
Getting rid of Thread.sleep | Sonarcloud complains about Thread.sleep (as Code smell). joerg.heffner proposed the idea of using Awaitlity (https://github.com/awaitility/awaitility ) for Taskana-Adapter to get rid of Thread.sleep. We should discuss if this solution is viable for Taskana too. |
| ||||||||||
if before debug-log | see comment in https://github.com/Taskana/taskana/pull/2003 |
| ||||||||||
Rewrite Test in TaskControllerIntTest |
|
|
