Messages
Messages copied to clipboard
FossifyOrg
Spam folder for messages
Checklist
- [X] I made sure that there are no existing issues - open or closed - to which I could contribute my information.
- [X] I made sure that there are no existing discussions - open or closed - to which I could contribute my information.
- [X] I have read the FAQs inside the app (Menu -> About -> FAQs) and my problem isn't listed.
- [X] I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
- [X] This issue contains only one feature request.
- [X] I have read and understood the contribution guidelines.
- [ ] I optionally donated to support the Fossify mission.
Feature description
I know its an initial release and i am sorry to requesting a feature too early, Only issue with the fossify sms is there isn't a spam folder or a way to retrieve accidentally blocked sms
Why do you want this feature?
I accidentally blocked an sms , i couldn't find an spam folder or anything like that, as a temporary solution i installed another sms app and retrieve that blocked message from there
Additional information
Even there won't be a spam folder ,please add any way to retrieve blocked messages
I was looking for this as well. Having a way to see blocked messages is necessary especially for unintended keyword blocks. Also, google messages has a notification feature for blocked messages. When it blocks a message it sends a notification without showing the message body by saying new spam or blocked message. having that as an option would be nice too.
Idk I think having notification about that would be against its purpose imo (but maybe opt in option wouldnt hurt)
I also meant it as an opt-in option. The case that I needed it was when I got an OTP sms from a number that I had blocked because of their promotional adverts. If there isn't a Spam folder in this case you can't login obviously. and the notification would help to not miss it.
On Wed, Feb 21, 2024 at 1:01 PM inson1 @.***> wrote:
Idk I think having notification about that would be against its purpose imo (but maybe opt in option wouldnt hurt)
— Reply to this email directly, view it on GitHub https://github.com/FossifyOrg/Messages/issues/59#issuecomment-1956234000, or unsubscribe https://github.com/notifications/unsubscribe-auth/AMCOQ3NIJ3I457KSUDPCMRLYUW5HPAVCNFSM6AAAAABCOHZ4NKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJWGIZTIMBQGA . You are receiving this because you commented.Message ID: @.***>
Just like an email service there will be messages falsely detected for spam and we always check spam folder next if we didn't received the message, so an spam folder can be considered as basic feature for any messaging app, hope we get that in future
I wanted this too :)
IIRC MMS isn't even saved if the sender is blocked.
I also want this! I am paranoid that I might have accidentally blocked a message unintentionally. I really just want the keyword blocking to avoid spamming of notifications, not to never have access to the message.
A Spam folder seems similar to the Archive and Recycle folders that already exist, so it doesn't seem like a huge ask to me.
any news on this? Google messages has two functions, mark messages as Spam and Block numbers.
I reverted needs triage because after investigation we've found out, that SMS from a blocked number doesn't get through to the app, so even if we create a spam folder it doesn't show anything. We need to check it further, how to bypass it, and then we can think of creating a spam folder.
It most likely also affects this issue: https://github.com/FossifyOrg/Messages/issues/237.
qksms has its own blocking manager and user can achieve blocked sms inside the app.
Please implement this. i believe this is much needed to view blocked sms's. I just moved from QKSMS, though many features are missing here. I request this one to be completed.
I'm thinking about using an internal blocking list in both Phone and Messages but it's not exactly a 'simple to explain' solution.
Perhaps this can be done in two parts with #271 being the first one (including pattern blocking).
That way, we'll have the UI/UX clarified before we attempt to use an internal list.
Hello everyone,
I have begun developing a new feature/fix and am currently stuck. I would greatly appreciate your technical comments and guidance on how to proceed. Below is a detailed explanation of the feature, its motivation, the high-level plan, what is working so far, and the issues encountered.
Feature Description
-
User Story:
As a user, I want messages containing blocked keywords or numbers to be sent to the recycle bin instead of being permanently dropped, so I can review them later if necessary. -
Current State:
If a message contains a blocked keyword or number, it isn’t saved on the device at all, and no notification is received. -
Expected Behavior:
If a message matches a blocked keyword/number, it should be saved as usual but then moved directly to the recycle bin without notifying the user.
Motivation
-
User Control:
Simply dropping messages isn’t ideal because the user loses control over what was filtered out. Saving them in the recycle bin allows the user to review and decide on further action. -
Optimized Filtering:
Without visibility into blocked messages, users can’t refine their blocklist effectively. Saving these messages provides insight into what’s being blocked, enabling better filter optimization.
Why Not a Dedicated Spam Folder?
A dedicated spam folder would be the best solution (I think), but implementing it involves complex changes (database schema modifications, UI work, and other under-the-hood adjustments) that are beyond my current expertise. Using the recycle bin as an interim solution still offers value to the user by allowing access to blocked messages without cluttering the main view.
High-Level Plan
-
Ensure Recycle Bin Feature is Enabled
Verify that the recycle bin functionality is active before processing messages. -
On Receiving a Message (SMS/MMS)
- Check if the message matches any keywords or numbers in the blocklist.
-
If No Match
- Process the message normally as it is today.
-
If There Is a Match
- Save the message to the database and add it to the app.
- Do not send a notification or increase the unread messages count.
- Move the saved message to the recycle bin.
Focus on SMS Flow
I’m starting with the SMS flow. See updates to SmsReceiver.kt here:
package org.fossify.messages.receivers
import android.content.BroadcastReceiver
import android.content.Context
import android.content.Intent
import android.os.Handler
import android.os.Looper
import android.provider.Telephony
import org.fossify.commons.extensions.baseConfig
import org.fossify.commons.extensions.getMyContactsCursor
import org.fossify.commons.extensions.isNumberBlocked
import org.fossify.commons.helpers.SimpleContactsHelper
import org.fossify.commons.helpers.ensureBackgroundThread
import org.fossify.commons.models.PhoneNumber
import org.fossify.commons.models.SimpleContact
import org.fossify.messages.extensions.*
import org.fossify.messages.helpers.ReceiverUtils.isMessageFilteredOut
import org.fossify.messages.helpers.refreshMessages
import org.fossify.messages.models.Message
class SmsReceiver : BroadcastReceiver() {
override fun onReceive(context: Context, intent: Intent) {
val messages = Telephony.Sms.Intents.getMessagesFromIntent(intent)
var address = ""
var body = ""
var subject = ""
var date = 0L
var threadId = 0L
var status = Telephony.Sms.STATUS_NONE
val type = Telephony.Sms.MESSAGE_TYPE_INBOX
val read = 0
val subscriptionId = intent.getIntExtra("subscription", -1)
val privateCursor = context.getMyContactsCursor(false, true)
ensureBackgroundThread {
messages.forEach {
address = it.originatingAddress ?: ""
subject = it.pseudoSubject
status = it.status
body += it.messageBody
date = System.currentTimeMillis()
threadId = context.getThreadId(address)
}
if (context.baseConfig.blockUnknownNumbers) {
val simpleContactsHelper = SimpleContactsHelper(context)
simpleContactsHelper.exists(address, privateCursor) { exists ->
if (exists) {
handleMessage(context, address, subject, body, date, read, threadId, type, subscriptionId, status)
}
}
} else {
handleMessage(context, address, subject, body, date, read, threadId, type, subscriptionId, status)
}
}
}
private fun handleMessage(
context: Context,
address: String,
subject: String,
body: String,
date: Long,
read: Int,
threadId: Long,
type: Int,
subscriptionId: Int,
status: Int
) {
// Step 1: Perform Keyword Check
val messageShouldBeBlocked: Boolean = (isMessageFilteredOut(context, body) || context.isNumberBlocked(address))
// Set read to 0 if the message should be blocked
val effectiveReadStatus = if (messageShouldBeBlocked) 1 else read
val photoUri = SimpleContactsHelper(context).getPhotoUriFromPhoneNumber(address)
val bitmap = context.getNotificationBitmap(photoUri)
Handler(Looper.getMainLooper()).post {
val privateCursor = context.getMyContactsCursor(favoritesOnly = false, withPhoneNumbersOnly = true)
ensureBackgroundThread {
val newMessageId = context.insertNewSMS(address, subject, body, date, effectiveReadStatus, threadId, type, subscriptionId)
val conversation = context.getConversations(threadId).firstOrNull() ?: return@ensureBackgroundThread
try {
context.insertOrUpdateConversation(conversation)
} catch (ignored: Exception) {}
if (!messageShouldBeBlocked) {
try {
context.updateUnreadCountBadge(context.conversationsDB.getUnreadConversations())
} catch (ignored: Exception) {}
}
val senderName = context.getNameFromAddress(address, privateCursor)
val phoneNumber = PhoneNumber(address, 0, "", address)
val participant = SimpleContact(0, 0, senderName, photoUri, arrayListOf(phoneNumber), ArrayList(), ArrayList())
val participants = arrayListOf(participant)
val messageDate = (date / 1000).toInt()
val message =
Message(
newMessageId,
body,
type,
status,
participants,
messageDate,
messageShouldBeBlocked,
threadId,
false,
null,
address,
senderName,
photoUri,
subscriptionId
)
context.messagesDB.insertOrUpdate(message)
if (context.config.isArchiveAvailable) {
context.updateConversationArchivedStatus(threadId, false)
}
// Step 3: Send to recycle bin if blocked
if (messageShouldBeBlocked) {
context.moveMessageToRecycleBin(newMessageId)
refreshMessages()
} else {
refreshMessages()
context.showReceivedMessageNotification(newMessageId, address, body, threadId, bitmap)
}
}
}
}
}
What Is Working
- The SMS is received and saved properly.
- Blocked messages appear in the recycle bin and are not visible in the main inbox.
- Users are not notified about blocked messages:
- No notifications are sent.
- Unread message badges are not increased.
- Conversations do not appear bolded.
Known Issue
- Scrolling Issue in Recycle Bin showing legitimate messages as well:
When viewing a conversation in the recycle bin that contains blocked messages, scrolling a bit causes the conversation to load all messages, including legitimate ones. This behavior needs to be addressed.
Next Steps
- Resolve the scrolling/loading issue where legitimate messages appear unexpectedly in the recycle bin.
- In the future, enable the recycle bin by default when blocked keywords are added to the blocklist.
Thank you for taking the time to review this (and maintaining the app in general @naveensingh @Aga-C ). Any insights, feedback, or suggestions on how to address the current issue and proceed further would be greatly appreciated! I will submit a PR once this works and tested.
@MGidnian
Please do not work on issues with needs triage label and please be concise with your messages. Consider reading the contribution guidelines.
Also, that whole code block ~isn't~ wasn't formatted properly, it seems like you used some LLM (AI studio?) to format it and it messed it up. AI is good but it's not THAT good.
Using the recycle bin as an interim solution still offers value to the user by allowing access to blocked messages without cluttering the main view.
This is not the way.
@naveensingh ,
I reviewed the guidelines once more, thanks! I know I'm new but trying to be helpful so sorry for any mistakes.
Althoguh it has needs triage label, I saw this is old and it didn't seem to be in work. As I have a personal need for this, I went ahead and suggested to work on this.
- Why it's not the way? I would be glad to work the details to get this going. The reason I put such an elaborate message was to clarify why I think it's good to start with a solution and how would I go about implementing it.
- Can you explain what needs triage and where can I help? (if at all)
I agree, AI is not THAT great - but I actually wrote everything myself! I just used GPT to make it markdown compliant. The issue wasn't with GPT, I used a single line code formatting instead of multiline by mistake :P
I saw this is old and it didn't seem to be in work.
Maybe it wasn't as much visible, but there was some work. We did the first prototype for internal investigation a few months ago, which resulted in my comment from November, that there are problems with utilizing the current global block list. And the latest idea how to bypass the limitations is just from a week ago.
Why it's not the way?
Putting blocked messages inside a recycle bin doesn't make sense. Whenever this is implemented, it will be its own option like 'Blocked messages'.
Can you explain what needs triage and where can I help?
The needs triage label is removed once all the if/when/what/how questions regarding an issue are cleared.
Thanks for the effort!
Maybe it wasn't as much visible, but there was some work.
Thanks, yes I saw the conversation up as well @naveensingh suggested recycle bin (or as I understand now a "spam bin") can be the first phase, with no many details following. That's why I picked it up and suggested my code.
Putting blocked messages inside a recycle bin doesn't make sense
Several users mentioned here/reddit it would be a fine solution, me including. IMHO it's better than just dropping messages today which is not straightforward UX.
Maybe it's too complex to explain(?), but if not - can you please share a little bit so I can work on it? If not and you are kind enough - can you explain or set me on the right direction to why legitimate messages will appear in the recycle bin for my code? so at least I or others can create some local build until you/we get this feature right 🙏
why legitimate messages will appear in the recycle bin for my code
I don't see anything wrong with the code. It's probably something subtle or it maybe something you changed in the recycle bin activity or related code.
Thanks 🙏 I have performed multiple tests with: Master, clean v1.1.3 and with my own code. They all reproduce. this is a bug 🤷 I'll open a ticket about it later
I'll open a ticket about 🪲 later
Don't bother, the recycle bin will probably be removed in favor of the archive feature.
In my view, the best behaviour would be to move the "blocked" messages to a spam folder combined with an 'automatically delete' feature for that folder after x days (where x is chosen by the user and can also be 'never'). In addition, "blocked" messages should prompt a generic notification like 'A suspicious spam message has been received'. The user should be able to turn off this notification, if she/he likes so. I think this design should give a reasonable good behaviour for most people. I understand it might not be that simple to implement. Perhaps the 'automatically delete' feature could be implemented at a later stage.
PS This might be an additional feature called "Spam messages", to be added to the current blocking feature that would remain unchanged as it is now.
Okay, how about making it optional?
A 'spam' folder that is enabled by default but can be disabled in settings. When disabled, the app will drop all blocked messages as it does now.
@naveensingh If you ask @Candlemass the “natural” answer will be that he does not understand why he/she should bother with an additional button just because a few are so idiot that cannot use their phones properly or are worried that others may loose important messages. Maybe he/she could receive a malware message that steals his/her secrets just before he/she pushes that button. Clearly, the default behavior should be what he/she likes. Want to bet?
One more possibility would be to keep blocking the messages as it is now, but to show somewhere the list of phone numbers that sent blocked messages. This way, one can call/message back a phone number if he/she is interested in it. In addition/alternative, one can (try to) modify the blocking rules accordingly. This is how it works now in the Phone app. Unwanted phone calls are blocked, but the calling numbers still appear in the call list.
@Candlemass Have you ever thought that there are cases in which you do not know in advance that you are about to receive an important message? It could happen that the school of your kid is trying to contact you for some reason. Or an hospital is sending you an information you were waiting for months. Or the government send you an sms alert because a tsunami is coming. Or, even simpler, it could happen that someone makes a mistake (not you, of course) and unintentionally blocks the number of a friend. Hope these (rather obvious) examples explain why temporarily disabling/enabling the block could be unpractical for some people (again, not you).
Second remark. If you look at the first post in this discussion, the "handful of users" are 14-2 in favour of a spam folder. This is not to say that you do not have good points. I myself disabled all phone calls from people not included in my contacts because I was so annoyed by commercial calls. Still, that 14-2 score should give you the right perspective of where your user experience ranks with respect to the others.
Finally, I think there is still a question by @naveensingh above waiting for an answer from you, if you could kindly grant it.
I won't add a lot as anything @antodc said is true and logical, I just want to mention that the accepted best practice UX is to have a folder with periodic release or manual delete.
- Email (Gmail, etc) - spam folder with periodic delete.
- QUIK SMS (Android OSS) - spam folder with periodic delete.
- iOS - Spam folders (categorized: ads, junk, etc) with manual delete. The list goes on, and still there is no system out there that just 'drops' messages of any kind
Don't want periodic delete? actually the ability to discard a message immedietly is also not an issue from a technical perspective, it would just be another (ugly IMHO) setting.
Secondly, all your examples outside of the weather alert are poor because these would all be communicated by phone call and a voicemail left if not answered, not a text message. Major weather alerts such as a tsunami are forecasted several days in advance. If you require that a government send you a notice at the last minute to be aware and haven't been keeping track of a potentially deadly weather event via alternate means then you deserve a Darwin Award. Regarding "accidentally blocking a number" that's clearly a user error...
Glad to see that you know how schools, hospitals and governments use messages all around the world.
I saw @naveensingh post. The problem is that I know how development cycles work. They always start off with good intentions attempting to accomplish said tasks and implement all caveats. However, almost always do the caveats fall off the priority list either due to time or the amount of effort in refactoring and iteration work it takes to make all cases function correctly. This results in the priority dropping to the bare minimum which effects all users instead of a niche use case. It's human nature to always take the easiest route to acconplish a task and there's already a perfect example on display in this thread in how implementing this as you suggest isn't going to be simple.
He kindly asked your opinion about an option, nothing more nothing less. To use your words, "you're fabricating things that he didn't say". I understand you like to say that because you are used at it. And, for the records, I interpret your delirium as me having won my virtual bet.
Either way, none of thiis addreses my core point. That being that the strict blocking feature "messages" has is unique to this sms app. It's the only feature that differentiates it from the million other open source sms apps that users are giving up tons of other features exclusively for. If you eliminate the strict blocking feature then "messages" is now exactly the same as every other sms app while being far less feature rich. Build on the strengths that make it stand out rather than dumbing it down to be a copy of every other project.
I think that it would be much more appreciated by everyone if instead of saying that what many other people would like to have is pointless you could provide concrete suggestions to improve this app for all. And, by the way, suggesting to use other apps in my view does not fall in that field.
Anyway, I am much more confident than you are that @naveensingh and the other developers will find a nice solution to satisfy all user needs.