Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should be able to delete location type when no locations of that type exist #1290

Closed
mahalakshme opened this issue Jul 23, 2024 · 7 comments
Closed
Assignees

Comments

@mahalakshme
Copy link
Contributor

mahalakshme commented Jul 23, 2024

As is:

Currently when a location type once created in App designer cant be deleted

Need:

For someone who is new, when they have set the hierarchy incorrectly when newly trying to setup, it becomes irreversible for them and leads to confusion

AC:

Screenshot 2024-08-05 at 5 21 08 PM
  • DELETE icon needs to be enabled always.
  • When no locations of that type exists, user should be able to delete that location type.
  • When locations exist, show error message(toast message in the bottom) stating that 'Locations of this type exists. Delete them to proceed further.'
@mahalakshme mahalakshme converted this from a draft issue Jul 23, 2024
@mahalakshme mahalakshme changed the title Creation of duplicate concept not handled Should be able to delete location type when no locations of that type exist Jul 23, 2024
@mahalakshme mahalakshme moved this from In Analysis to In Analysis Review in Avni Product Aug 5, 2024
@1t5j0y 1t5j0y self-assigned this Aug 21, 2024
1t5j0y added a commit that referenced this issue Aug 22, 2024
1t5j0y added a commit to avniproject/avni-server that referenced this issue Aug 22, 2024
@1t5j0y 1t5j0y moved this from In Progress to Code Review Ready in Avni Product Aug 22, 2024
@petmongrels petmongrels moved this from In Code Review to QA Ready in Avni Product Aug 30, 2024
@dinesh2096
Copy link

  • When we added the parent type for the location type and try to delete it we are getting a error

Image

  • And also if we deleted the location type by mistaken if the user want to readd the error is displayed

Image

@dinesh2096 dinesh2096 moved this from In QA to QA Failed in Avni Product Oct 1, 2024
1t5j0y added a commit to avniproject/avni-server that referenced this issue Oct 3, 2024
@1t5j0y
Copy link
Contributor

1t5j0y commented Oct 3, 2024

Fixed 2nd issue by renaming address level type on deletion so same name can be used again for a new address level type.

Unable to simulate the 1st issue - was able to delete child type when it did not have any children or levels of that type. The error message in the screenshot is not the latest so perhaps there was incorrect version of server deployed while testing.

@1t5j0y 1t5j0y moved this from In Progress to QA Ready in Avni Product Oct 3, 2024
@dinesh2096
Copy link

dinesh2096 commented Oct 16, 2024

Click here to watch video

@dinesh2096 dinesh2096 self-assigned this Oct 16, 2024
@dinesh2096 dinesh2096 moved this from In QA to QA Failed in Avni Product Oct 16, 2024
1t5j0y added a commit to avniproject/avni-server that referenced this issue Oct 16, 2024
1t5j0y added a commit to avniproject/avni-server that referenced this issue Oct 16, 2024
…dress level types so names can be reused

(cherry picked from commit 26e5fda)
@mahalakshme mahalakshme moved this from In Code Review to QA Ready in Avni Product Oct 24, 2024
@mahalakshme
Copy link
Contributor Author

mahalakshme commented Oct 24, 2024

@1t5j0y good to mention last_modified_by_id(using superadmin of yours) also I think, Previously when something via migrations have gone wrong it was with this, able to find a pattern and identified the root cause. Let me know if you think otherwise.

@mahalakshme mahalakshme moved this from QA Ready to Code Review with Comments in Avni Product Oct 24, 2024
@1t5j0y
Copy link
Contributor

1t5j0y commented Oct 24, 2024

good to have but not necessary for this particular one in my opinion since we are only touching already voided entities. Also, migrations should use last_modified_by_id 1 to differentiate migrations from manual fixes.

Maybe we need manual_update_history column for non transactional tables too.

@mahalakshme
Copy link
Contributor Author

yeah agreed

@mahalakshme mahalakshme moved this from Code Review with Comments to QA Ready in Avni Product Oct 24, 2024
@dinesh2096
Copy link

QA References :

Click here to watch the video

@dinesh2096 dinesh2096 moved this from In QA to Done in Avni Product Oct 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Archived in project
Development

No branches or pull requests

4 participants