Bug: address overlaps with the "Manage" button

[utkarshpra78]

Describe the bug
in the /orglist route If we add a longer address, it overlaps with the "Manage" button, causing the button to hide part of the address

To Reproduce
Steps to reproduce the behavior:

1. setup the project locally
2. Login as admin
3. go to the route /orglist
4. make a new organisation which has large address name
5. you see that address overlap with the "Mange" button

Expected behavior
"Manage" button should be placed slightly below

Actual behavior
A clear and concise description of how the code performed w.r.t expectations.

Screenshots

[github-actions]

Congratulations on making your first Issue! 🎊 If you haven't already, check out our Contributing Guidelines and Issue Reporting Guidelines to ensure that you are following our guidelines for contributing and making issues.

[utkarshpra78]

i can work on this issue. Kindly assign me this issue.

[Dante291]

@utkarshpra78 assigned

[PurnenduMIshra129th]

can i work on this issue ? Is it possible to work more than one user on same issue?

[PurnenduMIshra129th]

can i work on this issue? I have some idea to make it dynamic.

[Cioppolo14]

We only assign one person per issue. If the issue has already been assigned, please don't ask to be assigned. We want everyone to get a chance. Please check out other open issues, we would love your help.

[github-actions]

This issue did not get any activity in the past 10 days and will be closed in 180 days if no update occurs. Please check if the develop branch has fixed it and report again or close the issue.

[palisadoes]

Unassigning. Inactivity. No PR

[PurnenduMIshra129th]

assign me. I will do it

[palisadoes]

We are now focusing on three types of issues as priority areas:

1. The improvement in the reliability of our code base. There are many issues created to test existing code. It is a good place to start if you want to understand the operation of various apps. When you submit PRs, we automatically check to see whether the code you submitted has been covered by testing and that each file meets the minimum standard level of the repository as a whole. You won’t be able to avoid understanding testing regimes to contribute to Talawa.
2. The fixing of bugs and features that seriously hamper the user from using the application. The apps have various shortcomings. The most obvious ones are where the apps do not work as expected. For example buttons that don’t work, errors or messages that are not displayed to make the user understand what to do and many more. Think of any difficulty you have had in getting things working, there could be a bug there waiting for you.
3. Coding of screens for issues created by our Contributor team based on our soon to be updated design guide. This may include updates to existing screens.
4. The creation of additional or updated documentation that helps with improving both the experience of the end user and the various GitHub contributors who support the development of our software. This would include user guides.

We will only be accepting feature issues for deficiencies that are obviously lacking in the apps. These are things that make it very difficult to operate the apps. Even so, the PRs will still require you to understand testing as stated before.

Cosmetic changes that require only a few lines of code, or relate to screen sizes unlikely to be used are not acceptable under this policy.

Closing