devarno88 / newcal-issues Goto Github PK

Build upon Booking Suite functionality to allow users to book Space@105. Check with Ashmita for specific details before starting.

Allow NewCal Management to add/update/remove residents as application users to remove the need for development to perform these actions individually.

In the long run, Management should also be allowed to control site admins as well as residents.

Check with Ashmita for details.

Scrutinise the existing functionality and check for each of the following:

• User session via the useSession() hook
• Page loading: isolate API loaded blocks to individual spinners for each component rather than one spinner appearing before the entire page is loaded
• setAlert() hook: ensure that app alerts appear wherever necessary and add alerts for missing items

Build upon existing functionality allowing users to modify their own profile information, where a page will essentially exist for the basic details of each app user. Each profile page will also include a link to start a new chat with the profile owner (or be linked to an existing one).

Other potential profile content can include:

• Profile picture
• Short bio
• Interests/hobbies

Incorporate and improve main landing page based on content found at newcaledonianwharf.com

Currently the MyCal data fetch is performed in one large fetch identical to each user type, and the content shown is based specifically on the user type. This should be corrected to fetch data specific to each user type to reduce the server-side impact.

For example, the residents data fetch should only require Warnings, Bookings, Tickets and Posts, whereas the management data fetch requires practically everything.

Currently residents are sent email notifications for the following events:

• Booking confirmed
• Mailbox updated
• Warning posted
• Resident registration
• Resident details updated

Allow users to opt out of these emails if desired (check with Ashmita).

Currently a user can only book one Pool/Gym/Table slot at a time, granted that the booking is later than the current hour. Check with management whether residents should be allowed to book multiple slots per day, even if there is already one slot pending.

Currently, all resident management is handled by the NewCal Management account. If desired, residents can be permitted to update their own details (name, email) and adjust additional details such as profile picture, hobbies etc.

This can also apply to admin accounts (Management, Concierge and Development).

Check with Ashmita.

Currently posts and tickets are set to register whenever a resident has viewed the item once. If this is updated to point out each time an item is viewed regardless of the resident, this could give a clear indication of the popularity of the item at hand. Check with Ashmita.

However this is already partially reflected by the residents ability to like/comment items, and the downside is the server-side impact: if a view is registered every time an item is viewed this means more requests sent to the server. This is generally an issue for larger scale applications experiencing thousands/tens of thousands of views at a time, but this should be less of an impact for an application on the NewCal scale.

Allow users to filter posts and tickets by:

• Post/ticket type
• Flat number
• Date (most recent/oldest)

Incorporate Dashboard area where content is specific to user type, linking the user to each site section with an overview of the section analytics. This should give site admins a clear overview of admin-specific sections, which should be hidden to residents.

Would be ideal to include a space where residents can suggest enhancements to the NewCal application. Within LEAN startup practices, customer feedback is essential to the ongoing success of the application (as long as customers are happy, the product is thriving).

Ideally this should include the functionality to be reviewed by site admins, where residents can not only see the review but also the progress that is being made with regards to the suggestion (check with Ashmita for specifics). Ticket status should be controlled by Management/Development only.

This ticket should be cross-populated with [#4 App Updates Notifications]

From my experience, both swimmers and gym users enjoy occupying early morning sessions. There is the potential to allow users to book shared sessions for both pool and gym (I personally would not be opposed to sharing either if it means the earlier slots can be booked), however this should obviously be checked with Ashmita / Management.

A nice idea in the long run would be a shared space somewhere along the river patio/terrace for community gardening, where residents can engage in growing plants/fruits/vegetables.

Ideally a number of sizeable planters could be provided by building management, and willing residents could be assigned to planters (shared or individual) to grow items of their choice. This could all be handled within the NewCal system (perhaps within a subsection called "MyFarm" or "Planting@NewCal").

This section could also identify what each person is growing in case residents want to branch out and grow items that don't already exist within the space.

Number of total tickets is incorrect, as total should show sum of open and closed tickets which it currently doesnt.

This shall be investigated further ASAP.

UPDATE: Fixed with Promise.all(x => fetch(x)), ticket numbers now represented correctly.

Currently all documents are shared within Google Drive, this could easily be handled through a documents space within the NewCal application for simplicity.

Check with Ashmita for specific details.

Another interesting idea (speaking from experience here) would be to include an emergency contacts space to deal with critical situations that require immediate attention (that have ideally been reviewed by existing residents).

Some examples here may include:

• Plumbers
• Carpenters
• Pest-control
• Electricians
• Heating engineers
• General maintenance

etc.

Ashmita has pointed out that a handover section would be useful to management and concierge accounts. This means that a concierge is able to log in and list all transactions and notable events that have happened during their shift, so that the next concierge on shift is able to see clearly what has happened. As well as this, Ashmita should be able to log in and see a history of all handovers that have occurred (potentially could be filtered by date?).

Similar to the upcoming events space, this should be a dashboard section visible to both concierge and management accounts (the dashboard panel itself should show the last handover that was posted), and when this section is clicked it will link the concierge/manager to an individual page that displays the full history of handovers.

Build upon existing Admin-Chat functionality to allow residents to create individual chats as well as group chats.

Ashmita has specified that it would be useful to include an events section, where both management and concierges can have a clear view of the events occurring over a given timeframe (contractors, building workers etc).

I think the best approach is (similar to other site sections) to include an 'Events' section of the MyCal dashboard for management and concierge accounts, showing a summary of the events of the week as soon as they log in. Clicking on that section would then link them to an 'Events Page' where they can scroll through a calendar to see a complete log of building events (past and upcoming).

Check with Ashmita about what to include as options when a new events is registered:

• Event type
• Event date and time
• Organisation/contractor name?
• Phone number/email?

Currently the Enquiries Space allows NewCal Management to handle enquiries from external site visitors (ie. not residents).

Residents are provided with a 'Contact Management' link within the site that directs them to an automated email addressed to [email protected], where they fill in their enquiry details themselves.

The enquiries space can be modified to allow residents to send enquiries to management which can be viewed and handled by management within the site for simplicity, rather than through a collective string of emails.

Check with Ashmita for details.

Ensure that residents can only create bookings within a given timeframe, otherwise everyone will be able to book any given amount of time in the future which will undoubtedly spark some tension.

Build upon existing functionality with an AWS bucket that will allow users to upload and attach images for the following events/items:

• Posts
• Tickets
• Warnings (management/development only)
• Profile pictures (if desired)

Include an Admin-Development chat so that site admins can directly communicate issues/suggestions/general queries with the site developer. This will make it much easier than having to email/call me for any small enquiry.

Allow users to opt in and out of receiving updates about planned updates to application or building operations. Essentially this will simply allow residents to view permitted sections of the Development Backlog list and receive email notifications (or stop receiving them) when major application updates are pushed to production.

Some examples of content to include for major updates (check with Ashmita):

• Site development roadmap/updates
• Building management roadmap/updates
• Issue logs/resolutions

Currently the table booking suite is set up like the pool and gym bookings - a user can book a single pre-defined slot granted they have no pending bookings for the same day. This should be corrected to allow the following:

• Users should be able to select one from a collection of tables.
• Users should be able to book a desired time range (from XX:00 to YY:00).

URGENT: Update the application Navbar to be compatible with tablets and smartphones as well as just a desktop browser. This will undoubtedly provide a huge level of convenience for Management/Concierge when they need to carry out small-scale tasks on the fly (add a resident, update the mailbox, respond to an enquiry).