Closed Bug 1009550 Opened 10 years ago Closed 7 years ago

[Messages] Support sharing URLs to a specific phone number

Categories

(Firefox OS Graveyard :: Gaia::SMS, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: azasypkin, Assigned: borjasalguero)

References

Details

Attachments

(1 file)

46 bytes, text/x-github-pull-request
Details | Review
*** Follow-up from bug 895484 ***

See more details on that starting from bug 895484 comment 24.
Flags: in-moztrap?
feature-b2g: --- → 2.0
Assignee: nobody → borja.bugzilla
Target Milestone: --- → 2.0 S3 (6june)
Whiteboard: ft:loop
The goal of this bug is to add the support to share a *URL to a specific phone number*.

We will open a discussion with the rest of members of SMS Team in order to define if we need to add more features as extending this to 'MMS', and supporting an array of phone numbers instead of just one. We will work on it in a follow up.
Attached file WIP
Before fixing the tests, I would like to check if this approach is fine with you. Could you take a look Julien? Thanks!
Attachment #8432594 - Flags: feedback?(felash)
Comment on attachment 8432594 [details] [review]
WIP

I added some comments on github.

The "number" property is already used for the "share" activity... we need another property name. This shows quite well that we need to ask the people from the dev-webapi mailing list about the intended changes...
Attachment #8432594 - Flags: feedback?(felash)
Summary: [Messages] Support sharing of Loop Client call URLs → [Messages] Support sharing URLs to a specific phone number
Hi Julien,
I posted this topic to the mailing list group but it's not published yet...

I was explaining that we could start adding the phone number handling when sharing an URL (this bug), and move forward step by step spreading this to the rest of types (media types), and mixed content.

Probably changing the param to 'tel' or 'phonenumber' would be enough plus your suggestions added in the PR. Do you think is worthy to move forward with this fist step? Or should we wait until getting the topic published in the mailing list (I was publishing it with my personal gmail account, and probably that's why its slower that usual...)?

If we have no 'share' we will use the 'new' activity, which should be the one to deprecate for this type of scenarios once we have 'share' (because actually, for Loop or other apps, it's a 'share' action).
Flags: needinfo?(felash)
I just answered your mail, let's see if we have an answer before tomorrow.
Flags: needinfo?(felash)
I think that we need to think more on the 'share' activities, and once we have a clear solution for Gaia activities in the webapi group we will come back to implement it in SMS App.
As Loop is in our side as well, I'll update the activity to 'share' when available, but I would like not to block on this because In this case I think it's better to collect all feedback first. We will use 'new' activity for v2.0 in Loop.

Could we update the scope of this bug (currently is v.2.0)? I've added the dependency in order to track it properly. Thanks!
Depends on: 1016554
Flags: needinfo?(oteo)
Removing the feature-b2g:2.0 flag. In case there is an agreement about "share" activity and the patch is uplifted to v2.0 we will use it for mobile Loop client. Otherwise, as Borja says, we will use "new" activity instead.
feature-b2g: 2.0 → ---
Flags: needinfo?(oteo)
Borja, it seems we can just add a "phoneNumber" property to the share activity, for now. Ehsan seemed "quite" open about it.
Flags: in-moztrap?
Whiteboard: ft:loop
Target Milestone: 2.0 S3 (6june) → ---
Blocks: 1088993
No longer blocks: loop_gaia_change
No longer blocks: 1088993
So, why is the "new" activity not enough for this, already ?

Note that I fix one of the issue we have with this activity in bug 1190276.
Mass closing of Gaia::SMS bugs. End of an era :(
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Mass closing of Gaia::SMS bugs. End of an era :(
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: