Calednder

• Unified Schedule View: A full-screen calendar and list view lets users see all scheduled, pending, and completed jobs.
• Role-Based Views: The schedule is filtered based on who is viewing it (a client sees their jobs, a gardener sees their assigned jobs, an admin sees all jobs).
• Service Request Flow: A multi-step modal allows users to easily request new services, specifying the location, spaces, and preferred time.
• Service Management (Admin): Admins can define all the services the company offers, including setting commission rates and assigning qualified gardeners to each service type.

warning

These details are only updated with each release, for more acurate updates and keeping track of progress, see the task in GitHub.

Task Chat Launch

---

View Details

Description

Authentication will inicaly be handled by Firecase and later we will switch over to Colibri.

---

Status

Doc Status	Product Status	Last Update	Version	Release	Phase
In Progress	Up Next	04.03.2024	0.01	Internal	Alpha

Team

Owner	Lead
Mendy	-

---

Reminders

• Keep code lean and clear
• follow the outlined arcetecture
• write commetes in your code
• update the staus in the docs and in GitHub
• try not to recreate functions we alredy have, rather update exsiting functions to support your needs
• Be sure to follow the release guidelines
• Update Documentation
• keep API docs up to date each time you update or add endpoints

Links & Resources

• Task
• Chat
• [Main Branch]
• [Alpha]
• [Beta]
• [Production]
• BackBone Docs

Research

Research

note

The research listed in this document is sepsofct to the Splash, for a wide scope of the Eden research see the Research document.

Question - Answer -

User Details

User Stories

Persona One

Update Coming Soon

User Flows

Personas

Features

Features

Below is a list of features that will be utilized in order to deliver the best account features and functionalities. The details bellow are not comprehensive feature details but rather, describe how the features will be utilized within the account, for further details, please see the individual feature documentation.

• [Anonumus Auth]

• [Number Auth]

• [Keypass]

• [Social Auth]

Data

note

You can find the Data Structure.

On the document we want to keep all the important data, the first fetch and fast to access.

Auth

Not all accounts will need auth, primaraly accounts will be accessed by other accounts however, indeviduals will need to authenticate. If auth is not reqried than access is reqied and vs.

Data Structure

    - auth
    - - method 1
    - - - method (social, local, keypas)
    - - - created (date)
    - - - email
    - - - password
    - - - status
    - - - expried 

    - - method 2
    - - - method (pin)
    - - - created (date)
    - - - pincode (******)
    - - - status
    - - - expried (date)

Data Model

Here is what the model might look like, this should be a sub collection within the account document, each method will have its own document and the fields might vary based on the method.

class AuthMethod {
  final String method;
  final DateTime created;
  final String? email;
  final String? password; // Store securely or hash
  final String? status;
  final String? pincode; // Store securely or hash

  AuthMethod({
    required this.method,
    required this.created,
    this.email,
    this.password,
    this.status,
    this.pincode,
  });

    Map<String, dynamic> toMap() {
    return {
      'method': method,
      'created': created.toIso8601String(),
      'email': email,
      'password': password,
      'status': status,
      'pincode': pincode,
    };
  }

  factory AuthMethod.fromFirestore(Map<String, dynamic> data) {
    return AuthMethod(
      method: data['method'],
      created: DateTime.parse(data['created']),
      email: data['email'],
      password: data['password'],
      status: data['status'],
      pincode: data['pincode'],
    );
  }
}