Scenario: I received an error message: Bad Request.
When I asked for details, I received: Item cannot be deleted because it is associated with one or more elements. (delete_item_referenced).
Question: What does this mean? What am I doing wrong?
The Fast Answer: It means that you can't delete the item because it's associated with something called a "child" database object and that you'll probably want to "archive" whatever it is that you're trying to delete rather than try and delete it.
If you're interested in more of an explanation than this (also known as the longer version), choose the item that you were trying to delete from the following list:
Clients
CLIENTS - The Longer Version: XPunch enforces something called "referential integrity" concerning the relationships between data. The purpose of using referential integrity is to prevent orphan records and to keep references synchronized so that you don't have any records that reference other records that no longer exist.¹
In this scenario, someone specified the client you're attempting to delete in one or more of their projects. To use technical terms, we say that the client in this case is the "parent" and that the project is the "child." Imagine what would happen if you deleted the client (not the project). The question becomes what should happen in case like this? People have differing opinions, so the safest thing to do is to not allow clients to be deleted if they're associated with a project.
So, that begs the question what users should do when they don't want to see a client anymore in their list of clients. Well, they could locate every single project that contains the client in question and point the project to a different client (or to no client at all) and then delete the client. That's a lot of work and it seems that it would be much easier to simply archive the client instead. This removes it from view, and it also ensures that projects associated with the client remain unaffected. The client can always be returned to view by unarchiving it.
Projects
PROJECTS - The Longer Version: XPunch enforces something called "referential integrity" concerning the relationships between data. The purpose of using referential integrity is to prevent orphan records and to keep references synchronized so that you don't have any records that reference other records that no longer exist.¹
In this scenario, someone specified the project you're attempting to delete in one or more of their tasks. To use technical terms, we say that the project in this case is the "parent" and that the task is the "child." Imagine what would happen if you deleted the project (not the task). The question becomes what should happen in case like this? People have differing opinions, so the safest thing to do is to not allow projects to be deleted if they're associated with a task.
So, that begs the question what users should do when they don't want to see a project anymore in their list of projects. Well, they could locate every single task that contains the project in question and point the task to a different project (or to no project at all) and then delete the project. That's a lot of work and it seems that it would be much easier to simply archive the project instead. This removes it from view, and it also ensures that tasks associated with the project remain unaffected. The project can always be returned to view by unarchiving it.
Tasks
TASKS - The Longer Version: XPunch enforces something called "referential integrity" concerning the relationships between data. The purpose of using referential integrity is to prevent orphan records and to keep references synchronized so that you don't have any records that reference other records that no longer exist.¹
In this scenario, someone specified the task you're attempting to delete in one or more of their punches. Imagine what would happen if you deleted the task (not the punch). The question becomes what should happen in case like this? People have differing opinions, so the safest thing to do is to not allow tasks to be deleted if they're associated with a punch.
So, that begs the question what users should do when they don't want to see a task anymore in their lists of tasks. Well, they could conceivably track down every single punch that contains the task in question and delete those punches (or change the task for a different task in those punches) and then delete the task. That's a lot of work but, if your XPunch group is fairly new, this is fairly pain free. However, it seems that it would be much easier to simply archive the task instead. This removes it from view, and it also ensures that punches associated with the task remain unaffected. The task can always be returned to view by unarchiving it.
Members
MEMBERS - The Longer Version: XPunch enforces something called "referential integrity" concerning the relationships between data. The purpose of using referential integrity is to prevent orphan records and to keep references synchronized so that you don't have any records that reference other records that no longer exist.¹
In this scenario, the member has performed punches and these punches still exist. To use technical terms, we say that the member in this case is the "parent" and that the punches are the "children." Imagine what would happen if you deleted the member (not the punches). The question becomes what should happen in case like this? People have differing opinions, so the safest thing to do is to not allow members to be deleted if they're associated with punches.
So, that begs the question what users should do when they don't want to see a member anymore in their list of members. Well, they could locate every single punch that the member ever made and delete those punches and then delete the member. That's a lot of work but, if your XPunch group is fairly new, this is fairly pain free. But, it seems that it would be much easier to simply archive the member instead. This removes them from view, and it also ensures that punches associated with the member remain unaffected. The member can always be returned to view by unarchiving them.
Roles
ROLES - The Longer Version:XPunch enforces something called "referential integrity" concerning the relationships between data. The purpose of using referential integrity is to prevent orphan records and to keep references synchronized so that you don't have any records that reference other records that no longer exist.¹
In this scenario, someone assigned the role you're attempting to delete to one or more members. To use technical terms, we say that the role in this case is the "parent" and that the member is the "child." Imagine what would happen if you deleted the role (not the member). The question becomes what should happen in case like this? People have differing opinions, so the safest thing to do is to not allow roles to be deleted if they're associated with a member.
So, that begs the question what users should do when they don't want to see a role anymore in their list of roles. Well, they could locate every single member that contains the role in question and point the member to a different role and then delete the role. That's a lot of work and it seems that it would be much easier to simply archive the role instead. This removes it from view, and it also ensures that members associated with the client remain unaffected. The role can always be returned to view by unarchiving it.
Permission sets
PERMISSION SETS - The Longer Version: XPunch enforces something called "referential integrity" concerning the relationships between data. The purpose of using referential integrity is to prevent orphan records and to keep references synchronized so that you don't have any records that reference other records that no longer exist.¹
In this scenario, someone assigned the permission set you're attempting to delete to one or more members. To use technical terms, we say that the permission set in this case is the "parent" and that the member is the "child." Imagine what would happen if you deleted the permission set (not the member). The question becomes what should happen in case like this? People have differing opinions, so the safest thing to do is to not allow permission sets to be deleted if they're associated with a member.
So, that begs the question what users should do when they don't want to see a permission set anymore in their list of permission sets. Well, they could locate every single member that contains the permission set in question and point the member to a different permission set and then delete the role. That's a lot of work and it seems that it would be much easier to simply archive the permission set instead. This removes it from view, and it also ensures that members associated with the permission set remain unaffected. The permission set can always be returned to view by unarchiving it.
Comments
0 comments
Please sign in to leave a comment.