Origami_Wiki - User contributions [en]

Smart Trivandrum GPS future data removal query

2025-06-11T06:56:56Z

Midhungirish: Query to delete future data

Sometimes GPS devices sends future data to the server and there will be request from the agencies to delete such data. Following query can be used to clear the data:
<code>

DELETE FROM st_water_gps_data WHERE sgd_imei='865006046684263' AND sgd_time>'2025-06-11 11:19:00'

</code>

Replace the sgd_imei and sgd_time fields with relevant values.

GIT Branching Guidelines

2024-04-22T03:40:45Z

Midhungirish: /* 7.1 Branching for Hotfixes: */

== Git Branching Guidelines ==
=== 1. General Setup ===
==== 1.1 Production Branch (master): ====
The primary branch reflecting the production-ready state.
Deployment: Directly from this branch to the production server.
==== 1.2 QA Branch (dev): ====
Used for staging and testing before production.
Deployment: To the sandbox server for testing.
=== 2. Branch Protection ===
Protected Branches: Both master and dev.
No direct pushes allowed; changes must be made via pull requests.
Pull Requests: Require reviews and approvals from at least one developer other than the author.
=== 3. Branching for Development ===
==== 3.1 Sprint Branches: ====
Naming: sprint-X where X is the sprint number.
Based on: Created from dev at the start of each sprint.
==== 3.2 Feature Branches: ====
Naming: Using the Jira ticket number, e.g. JIRA-123-<branchname>.
Based on: Branched off from the respective sprint-X branch.
Purpose: Development of individual features or main tickets.
Maintenance: May be maintained by one or more developers.
=== 3.3 Subtask Branches: ===
Optional: Depending on the scale of subtasks and the number of developers.
Based on: Optionally branch off from the associated feature branch using the same naming convention.
== 4. Development Workflow ==
=== 4.1 Daily Commits: ===
Developers must commit changes to their respective feature branches on a daily basis
=== 4.2 Completing a Feature: ===
Merge completed feature branches back into the respective sprint-X branch via pull requests
=== 4.3 Merging to QA (dev branch): ===
Post-development, sprint-X branches are merged into dev.
Any number of merges can be done during the lifecycle of a sprint
Requires a pull request and approval from a developer not involved in the pull request.
Approver must do code review and can approve or reject the code with relevant comments
== 5. QA and Bug Fixes ==
=== 5.1 QA Testing: ===
Features merged into dev are moved to QA for testing.
=== 5.2 Handling Bugs: ===
Bugs are fixed within the original feature branch and merged back into dev as described above.
== 6. Release Preparation ==
End of Sprint: Post QA approval, dev is merged into master for production deployment.
== 7. Hotfix Workflow ==
=== 7.1 Branching for Hotfixes: ===
'''Naming:''' ''hf-JIRA-XXX-<branchname>''‎<br />
'''Based on:''' Created from master.‎<br />
'''Purpose:''' Immediate repairs to production issues.

== 7.2 Development and Testing: ==
Focus on quick resolution; includes thorough testing and review.
== 7.3 Review and Approval: ==
Requires pull request and approval from another developer.
== 7.4 Merging and Deployment: ==
Hotfixes are merged into master and immediately deployed.
== 7.5 Propagate Hotfixes: ==
Merge changes into dev and any active sprint-X branches to maintain consistency.

GIT Branching Guidelines

2024-04-22T03:39:02Z

Midhungirish: /* 7.1 Branching for Hotfixes: */

== Git Branching Guidelines ==
=== 1. General Setup ===
==== 1.1 Production Branch (master): ====
The primary branch reflecting the production-ready state.
Deployment: Directly from this branch to the production server.
==== 1.2 QA Branch (dev): ====
Used for staging and testing before production.
Deployment: To the sandbox server for testing.
=== 2. Branch Protection ===
Protected Branches: Both master and dev.
No direct pushes allowed; changes must be made via pull requests.
Pull Requests: Require reviews and approvals from at least one developer other than the author.
=== 3. Branching for Development ===
==== 3.1 Sprint Branches: ====
Naming: sprint-X where X is the sprint number.
Based on: Created from dev at the start of each sprint.
==== 3.2 Feature Branches: ====
Naming: Using the Jira ticket number, e.g. JIRA-123-<branchname>.
Based on: Branched off from the respective sprint-X branch.
Purpose: Development of individual features or main tickets.
Maintenance: May be maintained by one or more developers.
=== 3.3 Subtask Branches: ===
Optional: Depending on the scale of subtasks and the number of developers.
Based on: Optionally branch off from the associated feature branch using the same naming convention.
== 4. Development Workflow ==
=== 4.1 Daily Commits: ===
Developers must commit changes to their respective feature branches on a daily basis
=== 4.2 Completing a Feature: ===
Merge completed feature branches back into the respective sprint-X branch via pull requests
=== 4.3 Merging to QA (dev branch): ===
Post-development, sprint-X branches are merged into dev.
Any number of merges can be done during the lifecycle of a sprint
Requires a pull request and approval from a developer not involved in the pull request.
Approver must do code review and can approve or reject the code with relevant comments
== 5. QA and Bug Fixes ==
=== 5.1 QA Testing: ===
Features merged into dev are moved to QA for testing.
=== 5.2 Handling Bugs: ===
Bugs are fixed within the original feature branch and merged back into dev as described above.
== 6. Release Preparation ==
End of Sprint: Post QA approval, dev is merged into master for production deployment.
== 7. Hotfix Workflow ==
=== 7.1 Branching for Hotfixes: ===
Naming: ''hf-JIRA-XXX-<branchname>''
Based on: Created from master.
Purpose: Immediate repairs to production issues.

== 7.2 Development and Testing: ==
Focus on quick resolution; includes thorough testing and review.
== 7.3 Review and Approval: ==
Requires pull request and approval from another developer.
== 7.4 Merging and Deployment: ==
Hotfixes are merged into master and immediately deployed.
== 7.5 Propagate Hotfixes: ==
Merge changes into dev and any active sprint-X branches to maintain consistency.

GIT Branching Guidelines

2024-04-22T03:37:53Z

Midhungirish:

== Git Branching Guidelines ==
=== 1. General Setup ===
==== 1.1 Production Branch (master): ====
The primary branch reflecting the production-ready state.
Deployment: Directly from this branch to the production server.
==== 1.2 QA Branch (dev): ====
Used for staging and testing before production.
Deployment: To the sandbox server for testing.
=== 2. Branch Protection ===
Protected Branches: Both master and dev.
No direct pushes allowed; changes must be made via pull requests.
Pull Requests: Require reviews and approvals from at least one developer other than the author.
=== 3. Branching for Development ===
==== 3.1 Sprint Branches: ====
Naming: sprint-X where X is the sprint number.
Based on: Created from dev at the start of each sprint.
==== 3.2 Feature Branches: ====
Naming: Using the Jira ticket number, e.g. JIRA-123-<branchname>.
Based on: Branched off from the respective sprint-X branch.
Purpose: Development of individual features or main tickets.
Maintenance: May be maintained by one or more developers.
=== 3.3 Subtask Branches: ===
Optional: Depending on the scale of subtasks and the number of developers.
Based on: Optionally branch off from the associated feature branch using the same naming convention.
== 4. Development Workflow ==
=== 4.1 Daily Commits: ===
Developers must commit changes to their respective feature branches on a daily basis
=== 4.2 Completing a Feature: ===
Merge completed feature branches back into the respective sprint-X branch via pull requests
=== 4.3 Merging to QA (dev branch): ===
Post-development, sprint-X branches are merged into dev.
Any number of merges can be done during the lifecycle of a sprint
Requires a pull request and approval from a developer not involved in the pull request.
Approver must do code review and can approve or reject the code with relevant comments
== 5. QA and Bug Fixes ==
=== 5.1 QA Testing: ===
Features merged into dev are moved to QA for testing.
=== 5.2 Handling Bugs: ===
Bugs are fixed within the original feature branch and merged back into dev as described above.
== 6. Release Preparation ==
End of Sprint: Post QA approval, dev is merged into master for production deployment.
== 7. Hotfix Workflow ==
=== 7.1 Branching for Hotfixes: ===
Naming: hf-JIRA-XXX-<branchname>.
Based on: Created from master.
Purpose: Immediate repairs to production issues.
== 7.2 Development and Testing: ==
Focus on quick resolution; includes thorough testing and review.
== 7.3 Review and Approval: ==
Requires pull request and approval from another developer.
== 7.4 Merging and Deployment: ==
Hotfixes are merged into master and immediately deployed.
== 7.5 Propagate Hotfixes: ==
Merge changes into dev and any active sprint-X branches to maintain consistency.

GIT Branching Guidelines

2024-04-22T03:35:18Z

Midhungirish:

== Git Branching Guidelines ==
=== 1. General Setup ===
==== 1.1 Production Branch (master): ====
The primary branch reflecting the production-ready state.
Deployment: Directly from this branch to the production server.
==== 1.2 QA Branch (dev): ====
Used for staging and testing before production.
Deployment: To the sandbox server for testing.
=== 2. Branch Protection ===
Protected Branches: Both master and dev.
No direct pushes allowed; changes must be made via pull requests.
Pull Requests: Require reviews and approvals from at least one developer other than the author.
=== 3. Branching for Development ===
3.1 Sprint Branches:
Naming: sprint-X where X is the sprint number.
Based on: Created from dev at the start of each sprint.
3.2 Feature Branches:
Naming: Using the Jira ticket number, e.g. JIRA-123-<branchname>.
Based on: Branched off from the respective sprint-X branch.
Purpose: Development of individual features or main tickets.
Maintenance: May be maintained by one or more developers.
3.3 Subtask Branches:
Optional: Depending on the scale of subtasks and the number of developers.
Based on: Optionally branch off from the associated feature branch using the same naming convention.
4. Development Workflow
4.1 Daily Commits:
Developers must commit changes to their respective feature branches on a daily basis
4.2 Completing a Feature:
Merge completed feature branches back into the respective sprint-X branch via pull requests
4.3 Merging to QA (dev branch):
Post-development, sprint-X branches are merged into dev.
Any number of merges can be done during the lifecycle of a sprint
Requires a pull request and approval from a developer not involved in the pull request.
Approver must do code review and can approve or reject the code with relevant comments
5. QA and Bug Fixes
5.1 QA Testing:
Features merged into dev are moved to QA for testing.
5.2 Handling Bugs:
Bugs are fixed within the original feature branch and merged back into dev as described above.
6. Release Preparation
End of Sprint: Post QA approval, dev is merged into master for production deployment.
7. Hotfix Workflow
7.1 Branching for Hotfixes:
Naming: hf-JIRA-XXX-<branchname>.
Based on: Created from master.
Purpose: Immediate repairs to production issues.
7.2 Development and Testing:
Focus on quick resolution; includes thorough testing and review.
7.3 Review and Approval:
Requires pull request and approval from another developer.
7.4 Merging and Deployment:
Hotfixes are merged into master and immediately deployed.
7.5 Propagate Hotfixes:
Merge changes into dev and any active sprint-X branches to maintain consistency.

GIT Branching Guidelines

2024-04-22T03:34:15Z

Midhungirish: Created page with "== Git Branching Guidelines == === 1. General Setup === 1.1 Production Branch (master): The primary branch reflecting the production-ready state. Deployment: Directly from thi..."

== Git Branching Guidelines ==
=== 1. General Setup ===
1.1 Production Branch (master):
The primary branch reflecting the production-ready state.
Deployment: Directly from this branch to the production server.
1.2 QA Branch (dev):
Used for staging and testing before production.
Deployment: To the sandbox server for testing.
2. Branch Protection
Protected Branches: Both master and dev.
No direct pushes allowed; changes must be made via pull requests.
Pull Requests: Require reviews and approvals from at least one developer other than the author.
3. Branching for Development
3.1 Sprint Branches:
Naming: sprint-X where X is the sprint number.
Based on: Created from dev at the start of each sprint.
3.2 Feature Branches:
Naming: Using the Jira ticket number, e.g. JIRA-123-<branchname>.
Based on: Branched off from the respective sprint-X branch.
Purpose: Development of individual features or main tickets.
Maintenance: May be maintained by one or more developers.
3.3 Subtask Branches:
Optional: Depending on the scale of subtasks and the number of developers.
Based on: Optionally branch off from the associated feature branch using the same naming convention.
4. Development Workflow
4.1 Daily Commits:
Developers must commit changes to their respective feature branches on a daily basis
4.2 Completing a Feature:
Merge completed feature branches back into the respective sprint-X branch via pull requests
4.3 Merging to QA (dev branch):
Post-development, sprint-X branches are merged into dev.
Any number of merges can be done during the lifecycle of a sprint
Requires a pull request and approval from a developer not involved in the pull request.
Approver must do code review and can approve or reject the code with relevant comments
5. QA and Bug Fixes
5.1 QA Testing:
Features merged into dev are moved to QA for testing.
5.2 Handling Bugs:
Bugs are fixed within the original feature branch and merged back into dev as described above.
6. Release Preparation
End of Sprint: Post QA approval, dev is merged into master for production deployment.
7. Hotfix Workflow
7.1 Branching for Hotfixes:
Naming: hf-JIRA-XXX-<branchname>.
Based on: Created from master.
Purpose: Immediate repairs to production issues.
7.2 Development and Testing:
Focus on quick resolution; includes thorough testing and review.
7.3 Review and Approval:
Requires pull request and approval from another developer.
7.4 Merging and Deployment:
Hotfixes are merged into master and immediately deployed.
7.5 Propagate Hotfixes:
Merge changes into dev and any active sprint-X branches to maintain consistency.