Skip to content

Interaction between users from different Time Banks #789

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
gmartincor opened this issue Apr 3, 2025 · 2 comments
Open

Interaction between users from different Time Banks #789

gmartincor opened this issue Apr 3, 2025 · 2 comments

Comments

@gmartincor
Copy link
Collaborator

Currently, although there is functionality for transfers between organizations (as seen in #638 and #639), a complete system for interaction between users from different Time Banks has not been implemented. This proposal seeks to expand on that initial functionality.

To enable this broader interaction, I think we might consider updating the application's terms and conditions. Users who previously accepted the terms might need to explicitly accept the new terms upon logging in again. These new terms would include the possibility that other users can view their profile.

Additionally, I believe it would be a good idea to add a new option in "Modify my profile" (below the "Accounts" card) for each user to decide if they want to be visible to people from other time banks.

To carry this out, I would approach it through progressive phases:

Phase 1: Acceptance between administrators

I was thinking we could implement a friendship request system between administrators of different banks. The idea would be that only when both administrators accept would their banks be considered "friendly organizations."

We could create a new "Organizations" section in the administration panel with views for accepted, rejected, and pending requests, similar to the current requests section. I also think adding a link to "Search organizations" that would take us to the organizations view (to the right of the requests) would be useful.

In the organizations view, we could include an "Organizations" column that would only be visible to administrators. I imagine the action buttons could be something like: "Request union", "Pending", and "Delete union".

Phase 2: Visibility of offers between users from different banks

Once the relationship between banks is established, I think the offers search view could be modified. The idea would be to add a multi-selection dropdown to filter by time bank (placed to the left of the category filter), maintain the free text search bar, and allow all these filters to be combined.

The order of elements would be: first the free text search bar, then the time bank dropdown, followed by the category dropdown, and finally the "Search" button. I also consider it important to add security validations to verify the relationships between banks.

Phase 3: Contact between users from different banks

I've been thinking about this, and I believe there are two alternatives we could explore:

  • Idea 1: When selecting an offer from another bank, the offerer's data would not be initially visible and the "Transfer time" button would be locked. Instead, we could add a "Send acceptance request" button. Upon sending the request, this button would change to "Acceptance request pending" and a notice about the visibility of personal data would be displayed. The offerer would receive an email notification to accept or reject, and only upon acceptance would access to their data and the transfer button be unlocked.

  • Idea 2: Perhaps a simpler implementation would be to place a "Send request" button next to the transfer button. When clicked, a confirmation would open warning about sending personal data. After confirming, the button would change to "Message sent" and an email would be automatically sent to the offerer with the contact details. The important thing here is that personal data would never be directly visible in the interface.

In both cases, if a user has decided not to be visible to other banks, the view would be similar to when the user is not logged in.

Phase 4: Transaction model between users from different banks

For this part, I think the most sensible approach would be to follow a scheme similar to that established in issues #638 and #639. Transactions would be carried out automatically and time transfers would be publicly reflected as shown in the video of issue #639. An important detail: when making a transfer to a user from another bank, the user could be redirected to their own profile.

@sseerrggii
Copy link
Contributor

sseerrggii commented Apr 8, 2025

Thanks @gmartincor for the proposal.

Some feedback:

  • Offers/Demands are public, so we can keep it that way without changing terms and conditions if we find some way to interact without share your profile info with other organizations
  • I agree allow exchanges between Organizations need some kind of approval between both organizations
  • We don't need to disable transfer time button, if organizations agree on exchanges between them, then you can transfer time to anyone, at your organizations or at others organizations, I think we don't need to limit that
  • To Contact between users may be could be by mail (easiest way I think) For example if you want to contact the owner of an offer that belongs to another organization you can have a button to "send email requesting this service" and in the email we can send your contact info, we need some altert like "Are you sure? you will send to an user from organization X your contact data (email and telephone)?"

@gmartincor
Copy link
Collaborator Author

Perfect, @sseerrggii .

Yes, when the requester clicks the button to request an offer and send an email to the provider, a confirmation alert will appear asking them to confirm they agree to share their contact details before the email is sent.

I'm starting to work on the proposal, I’ll be on the lookout for any feedback. Thanks for your attention.

Cheers!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants