openkfw / trubudget Goto Github PK

In GitLab by @gonzochic on Oct 2, 2017, 09:55

Inputfield Labels are sometimes overflowing for french-translations. I think the only thing we can do right now is to simply make the fields a bit wider. Not the best solution but should work for now.

This is to ensure the issue numbers in GitLab and GitHub are the same

This is to ensure the issue numbers in GitLab and GitHub are the same

In GitLab by @kevinbader on Jul 30, 2018, 09:30

Let's figure this out on the backend first, then add a follow-up task for including the location in the UI.

In GitLab by @dominik on Apr 3, 2018, 14:44

Find out if fastify requires additional configuration for production

In GitLab by @kevinbader on Aug 9, 2018, 14:53

In GitLab by @Stezido on Dec 13, 2018, 14:33

If the uploaded document is 100 MB or larger the api throws an error 413 "Payload Too Large".
Note: Error message on frontend is empty!

In GitLab by @kevinbader on Aug 14, 2018, 11:25

From #47:

Currently the history item when the order of the workflowitems change looks like:

mstein changed the workflowitem ordering 

It would be nice to get details about what exactly changed.

This is to ensure the issue numbers in GitLab and GitHub are the same

This is to ensure the issue numbers in GitLab and GitHub are the same

This is to ensure the issue numbers in GitLab and GitHub are the same

This is to ensure the issue numbers in GitLab and GitHub are the same

In GitLab by @Stezido on Aug 10, 2018, 11:49

In GitLab by @kevinbader on Jun 13, 2018, 13:08

to be solved at api/global.createUser

This is to ensure the issue numbers in GitLab and GitHub are the same

This is to ensure the issue numbers in GitLab and GitHub are the same

In GitLab by @saschak_94 on May 3, 2018, 08:21

Currently it is not possible to display users with their avatars on the frontend.
To solve the problem we need to store the avatar with the user on the chain.

This is to ensure the issue numbers in GitLab and GitHub are the same

In GitLab by @Stezido on Nov 19, 2018, 11:02

This is to ensure the issue numbers in GitLab and GitHub are the same

In GitLab by @saschak_94 on Dec 10, 2018, 13:48

Currently the history item when the order of the workflowitems change looks like:

mstein changed the workflowitem ordering 

It would be nice to get details about what exactly changed.

This is to ensure the issue numbers in GitLab and GitHub are the same

In GitLab by @kevinbader on Aug 9, 2018, 14:54

In GitLab by @kevinbader on May 28, 2018, 08:39

Instead of the additional calls to user.list, the API responses should carry the user information with it (organization, displayName).

This is to ensure the issue numbers in GitLab and GitHub are the same

In GitLab by @kevinbader on Jun 4, 2018, 10:45

This is to ensure the issue numbers in GitLab and GitHub are the same

This is to ensure the issue numbers in GitLab and GitHub are the same

This is to ensure the issue numbers in GitLab and GitHub are the same

In GitLab by @Stezido on Nov 19, 2018, 10:50

This is to ensure the issue numbers in GitLab and GitHub are the same

In GitLab by @Stezido on Sep 25, 2018, 10:26

There exist only a few unit tests.
Every endpoint should have at least one unit test showing that the endpoint is working properly.

We should have meaningful tests and I would propose to have a test coverage somewhere around 80%.

This is to ensure the issue numbers in GitLab and GitHub are the same

In GitLab by @saschak_94 on Oct 9, 2018, 17:26

Currently we validate Jaeger Tracing

Branch "jaeger-tracing"

This is to ensure the issue numbers in GitLab and GitHub are the same

This is to ensure the issue numbers in GitLab and GitHub are the same

This is to ensure the issue numbers in GitLab and GitHub are the same

This is to ensure the issue numbers in GitLab and GitHub are the same

In GitLab by @Stezido on Aug 10, 2018, 11:42

In GitLab by @saschak_94 on Oct 25, 2018, 09:18

This is to ensure the issue numbers in GitLab and GitHub are the same

In GitLab by @mathiashoeld on Oct 11, 2018, 10:40

Current: Root user can add projects and subprojects and only when a workflow item is added, an error is thrown. (Missing assignee error, although there is an assignee set)

Should be: Root user cannot add projects, subprojects or workflow items and a fitting error message should be displayed

In GitLab by @kevinbader on May 16, 2018, 09:28

Merge "subproject.viewSummary" and "subproject.viewDetails" into "subproject.view" (affects the frontend as well). This makes things like filtering out projects a user is not allowed to see easier and clearer in the code base, and splitting the view intent is not dictated by any requirement at the moment (or is it??). Until this is done, filtering subprojects is done by means of the "subproject.viewSummary" intent.

This is to ensure the issue numbers in GitLab and GitHub are the same

This is to ensure the issue numbers in GitLab and GitHub are the same

In GitLab by @kevinbader on May 22, 2018, 17:22

This is to ensure the issue numbers in GitLab and GitHub are the same

In GitLab by @kevinbader on Jun 19, 2018, 09:57

• If multichaind dies unexpectedly (exit code != 1), multichaind is not restarted and it says Connect: Success!, which is obviously wrong.
• If the node has already been registered in an earlier run, multichaind connects right away and address is not set, causing registerNodeAtMaster to busy-wait.

Related: #90

In GitLab by @kevinbader on Jul 30, 2018, 10:40

Problem

When assigning someone to a project or subproject, the assignee is not granted any permissions. This should stay that way, but there is an unfortunate side effect: it may happen that an assignee doesn't even have permissions to view the project or subproject she's assigned to, which clearly is unexpected behaviour to the user.

Proposed Solution

Instead of adding any automatic permission changes to *.assign intents, the UI should check whether the current assignee has all expected permissions. If not, the UI should offer to change the assignee's permissions, using a modal dialog. If the current user is not allowed to grant additional permissions, the check doesn't need to be done and the dialog should not appear.

This is to ensure the issue numbers in GitLab and GitHub are the same