Andras/BoundlessFlowCampus2K
3
6
Fork 0
Code Issues 143 Pull requests 14 Projects Releases Packages Wiki Activity Actions 2

Mockup generation taskforce consensus of architecture and development patterns #191

New issue
Closed
opened 2026-04-08 13:47:40 +00:00 by b24johka · 12 comments
b24johka commented 2026-04-08 13:47:40 +00:00
Collaborator
Copy link

We'll have a meeting with all of the developers that is working on the mockup generation to make sure that we have a uniform standard in the pattern.
This might be a base to form the guidelines regarding mockup generation.
Related to issue: #126 #52 #127 #142

We'll have a meeting with all of the developers that is working on the mockup generation to make sure that we have a uniform standard in the pattern. This might be a base to form the guidelines regarding mockup generation. Related to issue: #126 #52 #127 #142
a24sakma commented 2026-04-09 08:50:50 +00:00
Collaborator
Copy link

The result from this meeting can you find here: https://git.webug.se/Andras/BoundlessFlowCampus2K/wiki/Mock-Api-Documentation
closing this issue.

The result from this meeting can you find here: https://git.webug.se/Andras/BoundlessFlowCampus2K/wiki/Mock-Api-Documentation closing this issue.
b24johka commented 2026-04-09 09:29:25 +00:00
Author
Collaborator
Copy link

This has been approved without review, i will reopen the issue.

This has been approved without review, i will reopen the issue.
b24johka 2026-04-09 09:29:26 +00:00
a24hirsa commented 2026-04-09 10:18:55 +00:00
Collaborator
Copy link

This seems to be more of a guide to how we create our mock API's then documentation about how to use them for future developers. This is not an actual issue as it is the intended purpose of this wiki section AND the project plans on swapping over to intended API's in the future. But i would suggest changing the name of the wiki page away from "mock API documentation" to something more similar to "rules of creating mock API" or "mock API creation guidelines" as documentation is a key word for finding information about how to use a tool in the future.

The emphasis on the existence of unique functionalities between sensors and the need to create README files is good and will make it easier for future developers to understand and use the mockup API's. But the guidelines seem vague for new developers in case they want to or need to create their own mockup API in the future. Include some examples of code and structure for future developers.

Additionally, i don't know if this is necessary, but we might want to include some form of guidelines or documentation about how the mockup's store information so it can be either uniform between mockup API's or match the JSON file structure of the intended API the mockup is currently representing, and thus make it easier to fetch data for different data handlers and swapping over to intended API's in the future.

This seems to be more of a guide to how we create our mock API's then documentation about how to use them for future developers. This is not an actual issue as it is the intended purpose of this wiki section AND the project plans on swapping over to intended API's in the future. But i would suggest changing the name of the wiki page away from "mock API documentation" to something more similar to "rules of creating mock API" or "mock API creation guidelines" as documentation is a key word for finding information about how to use a tool in the future. The emphasis on the existence of unique functionalities between sensors and the need to create README files is good and will make it easier for future developers to understand and use the mockup API's. But the guidelines seem vague for new developers in case they want to or need to create their own mockup API in the future. Include some examples of code and structure for future developers. Additionally, i don't know if this is necessary, but we might want to include some form of guidelines or documentation about how the mockup's store information so it can be either uniform between mockup API's or match the JSON file structure of the intended API the mockup is currently representing, and thus make it easier to fetch data for different data handlers and swapping over to intended API's in the future.
c24danli commented 2026-04-10 12:18:22 +00:00
Collaborator
Copy link

Having some stadards for how to create mockup data might be sound but each mockup will still need documentation about how to use that API and what is returned.

The rules:

  • Every micro service shall have a database. At the moment we use sensor database until the investigation about the database structure is done.
    This might need some talk with teamleaders, personally i dont think a database for each is nessasary as we would just create manny dbs with one table each, insted we can just add a table to the postgreSQL that exist. This fuctionality is implimented in the middleware as functions witch gets called with MQTT using this would also make the data uniform as it gets saved the same way

  • Map Structure shall follow Object oriented (use of classes) check out the parking service structure.
    This seem good to me, and makes it easy to use.

  • Every micro service has unique functionalities such as electricity and sensor then some parts may not be similar.

  • Having a README: What to include:- How it integrates from frontend and back

  1. How we reach the data and having proper comments
  2. In the pr having a label about testing
  3. How to build the project and make it run
  4. The decision and why
    This is in my oppinion the only really important part documentation as wiki and readme, Other classmates will use the data so how we create the data isnt that important as its just a mockup the important part is that others know how to use this API and know what gets returened for the views that will be created and that the data created is "realistic".
Having some stadards for how to create mockup data might be sound but each mockup will still need documentation about how to use that API and what is returned. The rules: - Every micro service shall have a database. At the moment we use sensor database until the investigation about the database structure is done. **This might need some talk with teamleaders, personally i dont think a database for each is nessasary as we would just create manny dbs with one table each, insted we can just add a table to the postgreSQL that exist. This fuctionality is implimented in the middleware as functions witch gets called with MQTT using this would also make the data uniform as it gets saved the same way** - Map Structure shall follow Object oriented (use of classes) check out the parking service structure. **This seem good to me, and makes it easy to use.** - Every micro service has unique functionalities such as electricity and sensor then some parts may not be similar. - Having a README: What to include:- How it integrates from frontend and back 1. How we reach the data and having proper comments 2. In the pr having a label about testing 3. How to build the project and make it run 4. The decision and why **This is in my oppinion the only really important part documentation as wiki and readme, Other classmates will use the data so how we create the data isnt that important as its just a mockup the important part is that others know how to use this API and know what gets returened for the views that will be created and that the data created is "realistic".**
a23timgu commented 2026-04-13 05:40:04 +00:00
Collaborator
Copy link

@a24hirsa wrote in #191 (comment):

This seems to be more of a guide to how we create our mock API's then documentation about how to use them for future developers. This is not an actual issue as it is the intended purpose of this wiki section AND the project plans on swapping over to intended API's in the future. But i would suggest changing the name of the wiki page away from "mock API documentation" to something more similar to "rules of creating mock API" or "mock API creation guidelines" as documentation is a key word for finding information about how to use a tool in the future.

I agree 100%, and this was briefly discussed with the leaders as well. We'll have to discuss this during the meeting to make the overall task a bit less fuzzy.

@c24danli wrote in #191 (comment):

  • Every micro service shall have a database. At the moment we use sensor database until the investigation about the database structure is done.
    This might need some talk with teamleaders, personally i dont think a database for each is nessasary as we would just create manny dbs with one table each, insted we can just add a table to the postgreSQL that exist. This fuctionality is implimented in the middleware as functions witch gets called with MQTT using this would also make the data uniform as it gets saved the same way

This was discussed with team leaders as well, and it also makes sense for each service to have its own database as we're working with the microservice architecture and therefore want to emphasize on loose coupling as much as possible so different people/teams can work on the different services without stepping on each other's toes. Furthermore, should there be issues with one database it won't affect the other services.
One could argue that having a single shared database is fine for a very quick prototype(especially when our database is as sparse as it is now), but the question is how much technical debt we want to leave for future developers.

@a24hirsa wrote in https://git.webug.se/Andras/BoundlessFlowCampus2K/issues/191#issuecomment-1558: > This seems to be more of a guide to how we create our mock API's then documentation about how to use them for future developers. This is not an actual issue as it is the intended purpose of this wiki section AND the project plans on swapping over to intended API's in the future. But i would suggest changing the name of the wiki page away from "mock API documentation" to something more similar to "rules of creating mock API" or "mock API creation guidelines" as documentation is a key word for finding information about how to use a tool in the future. I agree 100%, and this was briefly discussed with the leaders as well. We'll have to discuss this during the meeting to make the overall task a bit less fuzzy. @c24danli wrote in https://git.webug.se/Andras/BoundlessFlowCampus2K/issues/191#issuecomment-1981: > * Every micro service shall have a database. At the moment we use sensor database until the investigation about the database structure is done. > **This might need some talk with teamleaders, personally i dont think a database for each is nessasary as we would just create manny dbs with one table each, insted we can just add a table to the postgreSQL that exist. This fuctionality is implimented in the middleware as functions witch gets called with MQTT using this would also make the data uniform as it gets saved the same way** This was discussed with team leaders as well, and it also makes sense for each service to have its own database as we're working with the microservice architecture and therefore want to emphasize on loose coupling as much as possible so different people/teams can work on the different services without stepping on each other's toes. Furthermore, should there be issues with one database it won't affect the other services. One could argue that having a single shared database is fine for a very quick prototype(especially when our database is as sparse as it is now), but the question is how much technical debt we want to leave for future developers.
a24sakma commented 2026-04-13 07:53:54 +00:00
Collaborator
Copy link

We had a pair review with @c24danli and clarified some of the points.

  • Database is another team that work on and we can give input to the team that they do the research but for now we wait for the final research
  • The other points as we are still in the beginning of deciding how the communication architecture works. We will adjust the wiki and add more information in the readme when we are done with the final architecture.
  • We will make a re review request when this is done .
  • Await for the updates.
We had a pair review with @c24danli and clarified some of the points. - Database is another team that work on and we can give input to the team that they do the research but for now we wait for the final research - The other points as we are still in the beginning of deciding how the communication architecture works. We will adjust the wiki and add more information in the readme when we are done with the final architecture. - We will make a re review request when this is done . - Await for the updates.
a24timsv commented 2026-04-20 13:03:58 +00:00
Collaborator
Copy link

Is this being documented/worked with? Just asking for an update

Is this being documented/worked with? Just asking for an update
a24sakma commented 2026-04-20 13:05:42 +00:00
Collaborator
Copy link

Yeah, we said will update thie wiki when we are done with overall structure of the mockups. This can be kept open for not forgetting

Yeah, we said will update thie wiki when we are done with overall structure of the mockups. This can be kept open for not forgetting
👍 1
b24johka commented 2026-04-30 09:06:18 +00:00
Author
Collaborator
Copy link

Meeting held 30/04 about architecture, these are the decisions:

  1. Refactoring of directories in services
  2. Convert roombooking to not use MQTT
  3. Refactor parking service to be sensor structure
  4. Disable update/delete in middleware (Only for censors)
  5. Wiki page on all of the decisions of the mockup architecture
  6. Every service needs to be updated to the new structure
  7. Create diagrams of the new architecture before implementation
### Meeting held 30/04 about architecture, these are the decisions: 1. Refactoring of directories in services 2. Convert roombooking to not use MQTT 3. Refactor parking service to be sensor structure 4. Disable update/delete in middleware (Only for censors) 5. Wiki page on all of the decisions of the mockup architecture 6. Every service needs to be updated to the new structure 7. Create diagrams of the new architecture before implementation
a23timgu commented 2026-05-04 07:54:57 +00:00
Collaborator
Copy link

@b24johka wrote in #191 (comment):

Meeting held 30/04 about architecture, these are the decisions:

  1. Refactoring of directories in services
  2. Convert roombooking to not use MQTT
  3. Refactor parking service to be sensor structure
  4. Disable update/delete in middleware (Only for censors)
  5. Wiki page on all of the decisions of the mockup architecture
  6. Every service needs to be updated to the new structure
  7. Create diagrams of the new architecture before implementation

We'll need new issues for the following points here:
-1: one new issue for roombooking,
one for parking,
one for energy.
-2: one new issue.
-3: one new issue.
-4: one new issue.
-5: Probably one new issue that the people in the mockup group will have to cooperate on?
-6: This probably goes hand-in-hand with 1. Doesn't seem like they need to be separate issues as they will both happen at the same time in the same task.
-7:
one for room booking
one for power
one for parking.

@b24johka wrote in https://git.webug.se/Andras/BoundlessFlowCampus2K/issues/191#issuecomment-6873: > ### [](#meeting-held-30-04-about-architecture-these-are-the-decisions)Meeting held 30/04 about architecture, these are the decisions: > 1. Refactoring of directories in services > 2. Convert roombooking to not use MQTT > 3. Refactor parking service to be sensor structure > 4. Disable update/delete in middleware (Only for censors) > 5. Wiki page on all of the decisions of the mockup architecture > 6. Every service needs to be updated to the new structure > 7. Create diagrams of the new architecture before implementation We'll need new issues for the following points here: -1: **one** new issue for roombooking, **one** for parking, **one** for energy. -2: **one** new issue. -3: **one** new issue. -4: **one** new issue. -5: Probably **one** new issue that the people in the mockup group will have to cooperate on? -6: This probably goes hand-in-hand with 1. Doesn't seem like they need to be separate issues as they will both happen at the same time in the same task. -7: **one** for room booking **one** for power **one** for parking.
a24sakma commented 2026-05-04 10:18:14 +00:00
Collaborator
Copy link

The issues to the diagrams are created. Don't create any new issues on those.

The issues to the diagrams are created. Don't create any new issues on those.
a24sakma commented 2026-05-12 09:12:17 +00:00
Collaborator
Copy link

we have left the documentation which will be done in this issue. #910. I close this issue now

Good job everyone.!

we have left the documentation which will be done in this issue. https://git.webug.se/Andras/BoundlessFlowCampus2K/issues/910. I close this issue now Good job everyone.!
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
#964-Implement-Meue-Service
#1057-navbar-color-change
team_1_week_7
909-Save-PDFs
1072-update-support-page
#1073-remove-bottom-border
team_2_week_7
1052-UnixRebuild.sh-run-in-paralell
#1021-Missing-icons-in-add-new-cards-menu
1044-&-987-Create-script-expansion
write-in-wiki-about-the-playwrite-#1043
#1069-search-for-swedish-cards
1032-Better-and-X-for-the-cards
991-frontend-sign-up
#1033-fix-button-translate-view
#1030-landscape-view-bug
#1055-Add-Todolists/Translation-Tooltip-in-correct-file
1061-Rebuild-script-improvements
#1045-fix-shmi-temp-view
1064-todo-checkbox-enable-all-time
#1001-cleanup-middleware
1012-update-the-boundlessflowCampus2k-readme
765-fix-visible-rows-edit-mode
#1047-fonts-uniform-in-views
vasttrafik-clean
#934-solar-panel-mockup-v2
#900-logger-middleware-new
#1046-Fix-broken-localization-in-settings
#1039-dependencies-with-mid-vulnerabilities
#900-logger-for-middleware
#989
1008-localization-on-views-part-1
715_Create_tests_roomBooking
temp_branch_week_7
#1027-move-footer-down
1037-missing-login-functionality
1023-The-clock-pulsates-after-each-second
#1015-button-visibility
1029-fix-preview
#1027-fix-footer-bug
#961-new-card-design
fix-manage-toolbar-button
team_2_week_6
team_1_week_6
541-implement-vasttrafik-card
1006-update-css-in-frontend-pages
748_change_creation_endpoint_roomBooking
#977-Translator-API
#845-new-energy-endpoints
#937-Personal-to-do-list
#935-clock-view-expansion
991-login-and-signup
635-Sub-compose-files-re-branch
988-different-passwords-for-databases
#920-change-password
#934-solar-panel-mockup
946-Implement-the-new-settings-page-design
#967-implement-new-main-design
945-change-position-empty-card
#996-dependencies-with-high-vulnerabilities
1000_Fix-pg_cron-sql-setup-for-postgres-image
955-fix-mapview-responsiveness
982-enhance-toggle-toolbar
#861-localization-change-all-printed-text-Part-2
938-fix-view-button-mobile
#924-implement-new-add-card-menu
Add---remove-orphans-to-the-rebuild-script-#983
UnixRebuildDebug.sh
835-loginService-JWT-v2
962-new-button-temperatureView-sensors
#893-Create-test-in-frontend-for-responsiveness
933-water-sensor-mockup
#305-fileService
#949-fix-cards-in-alphabetical-order
#954-mobile-card-stack-bug
894-tempservice-class-diagram
934-solar-panel-mockup
Temp-Main-Week-5
915-Windows-deployment-script
835-loginService-JWT
#908-new-logo
#952-Center-Temperature-graph
team_2_week_5
#658-Options-dependenacy
team_1_week_5
873-implement-logger-for-tempservice
#921-login-logout-in-settings
#786-parkingApiMockup-unit-tests-are-broken
919-dark-mode-settings
#442-temp-month-and-year-styling
issue-836-add-card-placeholders
905-enhance-color-themes-settings
#922-Implement-a-fucntion-to-delete-a-account-
707-update-css-files-frontend-features
Remove-sudo-from-MD-installation-#877
#920-possibility-to-change-password
#47-Testing-SMHI
#885-new-login-page
#861-Localization-change-all-printed-text
#899-Implement-logger-for-energyService
#859-Create-Smooth-Transition-For-Dashboard
889-turn-off-season-themes
879-season-themes-functinality
737-Parking-restructure-re-branch
#876-logger-loginService
Enhance-logging-deploy-#838
#724-restructuring-of-roombooking-service-code
853-change-hamburger-menu-to-buttons
#752-implement-automatically-cards-update
866-views-get-scrollbars-eaven-when-they-fit
727-calculate-average-temperature-and-store-the-result
847-enhance-settings
803-update-css-files-frontend-components
798-add-card-horizontal-fix
731-Service-creation-script
837-temperature-error-messages-team1
662-solution-file-is-not-up-to-date
603-sort-cards-alphabetically
741-improve-text-view-card
#797-Restructuring-energy-service
840-move-logo-navbar
807-fix-button-layout
833-change-temperature-error-messages
#429-select-year-temperature
772-fix-localization-context
#799-Fix-mobile-preview-header
color-tech-test
#659-grid-cell-dimensions
#789-Socials-Page
Change-title-Description-#815
779-fix-scaling-map-view
Old-Navbar-On-Refresh-#770
#804-fix-preview-size
#778-default-card-sizes
800-enhance-toolbar-phone
#768-404-error-in-temp-sensor
#787-tempSesnorMockupTests-outdated-unit-tests
766-fix-preview-for-clock-view
788-footer-links-fix
776-hide-toolbar-button
643-Create-titles-for-all-cards
749-create-job-api
#762-refactor-the-function-GetLayoutNameAndID(int-userID)
#607-auto-view-registry
780-add-card-descriptions
767-error-add-no-card-selected
741-textview-card-improvements
fixes/solution-room-booking
#769-add-energy-view
temp_branch_week_5
team_2_week_4
#654-flashes-on-refresh
team_1_week_4
#691-move-ITempService-to-a-separate-file
#733-smhi-forecast-design
#709-unit-tests-for-layoutService
#730-energy-view
745-text-footer-fix
Deployment-script-#701
743-fix-position-logo-phone
722-fix-year-month-api-connection
#723-clcok-view
708-hamburger-position
#690-Implement-password-hashing
#703-missing-required-packages-in-install-scripts
#732-footer-centered
729-textview-cant-make-new-rows
#541-Västtrafik-card
#697-remove-mqtt-from-roombooking
#702-auto-update-temperature
693-fix-temperature-graph-preview-centering
649-Footer-not-moving-with-grid
673-fix-respond-remove-phone
feature/501-implement-loginservice-api
#620-update-prettier-config
#664-Logo-change-depending-on-device
663-responsive-add-card-modal
#672-centering-spans
#661-remove-header-zoomed-in-phone
week_4_temp_branch
667-fix-resize-textview
657-Code-cleanup-after-merge
#659-Grid-cells-should-have-the-same-dimensions-when-zooming-in/out
#628-Fix-team-2-tmp-service-V4
API-Calls-gets-resent-alot
#652-fix-scrollbars-on-cards
602-new-file-structure
#640-hamburger-bug
temp-branch-week-3
#628-Fix-team-2-tmp-service-V2
#477-Update-Electricity-Data
team_2_week_3
team_1_week_3
#459-TempratureGraph-Fix-and-APIhook
625-increase-size-URL-schedule
#628-Fix-team-2-tmp-service
#369-implement-hamburger-menu
#585-Implement-Mobile-toolbar
feature/expand-parking-#254
570-Add-weather-symbols
#630-add-max-sizes-view-config
#608-fix-tempreture-graph
544-fix-tooltip-styling
#610-reset-modal-background-not-displaying
539-add-card-modal
#578-Implement-navbar-to-be-responsive
616-fix-tooltip
#617-values-for-month-week-year
613-fix-logo-chrome-edge
#573-add-enough-grid-rows
#605-new-custom-button
#377-Implement-Sudoku-View
567-installation-script-missing-dotnet-dependency
#351-roombooking-functionality-and-restructuring
#552-Settings-Skeleton-page
551-add-new-logo
#484-weekly-aggregated-temperature
#507-breakout-danger-modal
AddNewView-Faulty-Parameter-564
#547-fix-schedule-card-resize
531-break-out-new-card-functionality
533-config-tooltip
525-fix-booking-card
#538-Footer-scale-bug
516-grid-background-update
527-stay-edit-mode-refresh
506-mode-and-style-bug
513-cards-button-panel
521-footer-is-too-far-up
483-temperature-latest-return-error
#377-sudoko-view
#500-fix-card-enlargement
fixes/parking-service-#478
forecastview-weather-fix
#499-Missing-unit-tests-for-tempService
#508-break-out-toggle-from-dashboard-with-css
#380-new-cards-with-doNotCompact-grid-setting
Remove-dropshadow-arrows-#510
#497-reset-layout-btn-in-edit-mode
Fix-empsensorMockup-WorkWhithMiddleware
#494-fix-map-view-scaling
#493-Optimize-build-script
492-standards-card-errors
team_2_week_2
team_1_week_2
#376-SMHI-forecast-view-design
#19-dynamic-table-database
469-bigger-resize-closing-buttons
#126-ElectricityDataMockup
#406-tempSensorMockup-fix
#452-Grid-background-does-not-expand-with-grid
#458-Cleanup-exports
#464-Saving-card-content
#335-empty-card
428-text-card-to-notes
#311-fix-outlines-when-moving-cards
263-show-grid-when-in-grid-mode
424-create-seperate-css-files-for-components
Change-tab-icon-to-new-logo-#446
feature/room-booking-#43
modalCard
#339-Big-card-for-all-temperature-sensors
#386-Xunit-tests-for-for-parkingApiMockup-roomBookingMockup
hotfix/parking-api-dependecy-issue-build-#378
#279-Grid-layout-breakout
392-edit-language-standards-all-files
#369-Implement-hamburger-menu-in-the-navbar-
#289-fix-interactivity-with-cards
#399-tempSensorMockupTest-stopped-working-after-weekly-merge
#341-add-cards-to-error-views
374-card-scales-when-moved-bug
#375-Change-background
#345-update-logo-homepage
#319-Add-test-directories-to-all-C#-dirs
Fix-tempSensor-fel-HTTP500
TEMP-Testing-script
#315-build-script-fix-team-2
#312-fix-btn-css-team-2-fix
#313-404-routing-fix-team-2
temp-week-2-merge-branch
team_2_week_1
feature/#127-parking-api-databas-connection
team_1_week_1
#295-fixed-bugs-on-cards
#266-make-a-footer
#219-&-#208-Build-script-optimization
#20-aggregated-temp-for-month-year
#228-parking-frontend
199-research-grid-opening-closing-cards
#221-User-tables-for-future-database
#161-Integrate-Jest-testing-framework-to-project
fixes-issues-132
#107-Create-front-end-component-for-dynamically-changing-graph
#173-Save-User-Settings
#202-local-server-solution
No results found.
Labels
Clear labels   
_CRITICAL_

Only use this label for critical tasks that are project-scope,and must be addressed ASAP.

  
API

   
app

   
backEnd

   
Blocked-waiting-for-further-changes

   
bug

Something is not working

  
bug-only-on-server-for-mobile-not-webpage

   
Bug-Report-After-Merge

   
cleanup

Issues to cleanup the codebase (restructure folders, remove deprecated or smelly code)

  
close

Issue to close

  
design

   
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
feature request

   
frontEnd

   
further-changes-needed

   
future-problem-not-fixint-this-period

   
help wanted

Need some help

  
invalid

Something is wrong

  
last-week-issue-to-fix

   
library

   
low-priority

   
needs input

Issue needs input from product owner or customer

  
needs review

issue is in need of review

  
not-implemented.

   
project documentation

   
question

More information is needed

  
research

   
reviewed

This Issue has been reviewed

  
Script

   
security

use this for security-related issues

  
SQL

  
style

   
Team 1

Team 1 is responsible for this issue

  
Team 2

Team 2 is responsible for this issue

  
team leaders

   
test-creation

   
testing

   
topLevel

Reserved for top-level, project-wide issues.

  
unassigned

   
Under-review

   
wontfix

This won't be fixed

No labels
_CRITICAL_
API
app
backEnd
Blocked-waiting-for-further-changes
bug
bug-only-on-server-for-mobile-not-webpage
Bug-Report-After-Merge
cleanup
close
design
duplicate
enhancement
feature request
frontEnd
further-changes-needed
future-problem-not-fixint-this-period
help wanted
invalid
last-week-issue-to-fix
library
low-priority
needs input
needs review
not-implemented.
project documentation
question
research
reviewed
Script
security
SQL
style
Team 1
Team 2
team leaders
test-creation
testing
topLevel
unassigned
Under-review
wontfix
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
a23timgu
a24antej
a24sakma
f21marfo
a24hirsa
c24danli
6 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
Andras/BoundlessFlowCampus2K#191
No description provided.