Add option to purge only deleted messages

[multiwebinc]

Related bug report: #525

I've added another checkbox in the scanner window that when checked will purge only the messages that the scanner was unable to find. For the life of me I couldn't figure out how to add a column to the list view to indicate that the string couldn't be found in the project anymore to give the translator an idea which strings can be safely deleted.

It is also missing a migration to add a boolean column to rainlab_translate_messages called found. I'm not exactly sure how that should be handled since you need to increment the version.

[mjauvin]

Thanks a lot!
I'll take a look on how we could add those columns to the messages list.

[mjauvin]

I had a quick look and I didn't see where the messages actually get purged... what am I missing?

[multiwebinc]

I missed uploading the controller.

[mjauvin]

@multiwebinc for the migration, just create the update_messages_table.php migration file and I'll take care of the version.yaml file.

[mjauvin]

update_messages_table.php:

<?php namespace RainLab\Translate\Updates;

use Schema;
use October\Rain\Database\Updates\Migration;

class UpdateMessagesTable extends Migration
{
    public function up()
    {   
        Schema::table('rainlab_translate_messages', function($table)
        {   
            $table->boolean('found')->default(1);
        });
    }       

    public function down()
    {   
        Schema::table('rainlab_translate_messages', function($table)
        {   
            $table->dropColumn('found');
        });
    }
}

[mjauvin]

LGTM! I ran a few tests and it seems to be working as expected!

[multiwebinc]

@mjauvin How hard would it be to put a small exclamation mark type icon on the message list page for translations marked as not found? I couldn't easily figure that out the other day.

[mjauvin]

The markup for this is rather alien to me, couldn't figure it out either.

[mjauvin]

@multiwebinc I am slowly making progress at adding a column to show the "found" db field...

[mjauvin]

@multiwebinc I'll let you play with this, but so far I did the following:

In controllers/messages/config_table.yaml modify columns as below:

columns:
    from:
        title: From
    to: 
        title: To
    found:
        title: Found
        type: checkbox
        width: 100px

And in controllers/Messages.php add the found column data in processTableData() as below:

$data[] = [
    'id' => $message->id,
    'code' => $message->code,
    'from' => $message->forLocale($fromCode),
    'to' => $toContent, 
    'found' => $message->found
];

checkbox column type should be able to be marked "readOnly" but it's not working.

It's currently rendering as below:

[multiwebinc]

@mjauvin I couldn't find any documentation for the backend table widget, however the supported column types are "string", "checkbox", "dropdown" and "autocomplete". These are all rendered client-side with JS and the data is pulled using AJAX. If the "string" column type is chosen, it is HTML entity encoded, so it doesn't look like there's a straightforward and easy way to do what I was thinking. Using a read-only checkbox would be my second choice, however the read-only attribute has no effect for the checkbox column type. In fact, selecting/unselecting the checkbox does not update the value in the database either. Looks like a possible bug to me.

[multiwebinc]

Ok, this is how it is rendering now. I put the info icon with a title attribute explaining what this means in the table header:

[mjauvin]

@multiwebinc I finally had time to test this and it works well.

I think the column header would make more sense being "notes" rather than "found" since the later sounds more like it should say it was found (yes) or not (no)... only marking the records that have not been found is confusing when using that column header in my opinion (especially if there are no missing translations).

Other that that, it looks great!

[multiwebinc]

@mjauvin The thing is that if it wasn't found with the scanner, I would like to be able to provide a slightly more descriptive feedback to the user than just "Not found" since I would guess the majority of users wouldn't know what that means exactly. What if we call it "Scan errors", or "Scan result"?

[mjauvin]

@mjauvin The thing is that if it wasn't found with the scanner, I would like to be able to provide a slightly more descriptive feedback to the user than just "Not found" since I would guess the majority of users wouldn't know what that means exactly. What if we call it "Scan errors", or "Scan result"?

Whatever makes sense, I was just saying "Found" didn't make sense here.

[multiwebinc]

@mjauvin Take a look now. Let me know if the wording sounds good to you now.

[mjauvin]

Looks good @multiwebinc!