Custom realm emoji #543

blablacio · 2016-03-17T11:04:16Z

Adding some functionality to allow for managing custom realm emoji from admin.

smarx · 2016-03-17T11:04:19Z

Automated message from Dropbox CLA bot

@blablacio, it looks like you've already signed the Dropbox CLA. Thanks!

timabbott · 2016-03-18T05:22:23Z

zerver/models.py

-    name = models.TextField()
-    img_url = models.TextField()
+    name = models.TextField(validators=[MinLengthValidator(1), RegexValidator(regex=r'^[0-9a-zA-Z_\-\.]*$')])
+    img_url = models.URLField()


What happens to existing instances of a model when you change the type of a field from TextField to URLField? Seems like this may involve a messy migration.

Well, on the database the field is changed from text to character varying(200) as URLField enforces a max_length=200 by default. Other than that there should be no problems as values are still retained, even if they don't represent valid URLs.

Interesting, so you're saying that either Django or Postgres retains the value in the existing column even when its type is changed from text to varchar(200)? Seems worth testing.

Yes, that's the case here in particular and in most (if not all) cases when changing from text to character varying and vice versa. I think it would only be a problem if we already have URLs longer than 200 characters in existing databases. If you think this is worth testing or even extending the migration in order to handle such cases, let me know.

Maybe I should rather set a bigger max_length to the URLField in order to avoid such problems? A perfect solution would be to also check the existing URLs in the database against the URLValidator that Django provides.

I think there aren't a ton of these in existence, and a 200 character URL is pretty long, so I think it's OK -- just wanted to make sure we're not setting ourselves up for an unpleasant migration.

timabbott · 2016-03-18T05:34:58Z

Thanks for working on this @blablacio!

I posted a bunch of comments (mostly on small style issues); you'll also want to fix the lint/test errors.

blablacio · 2016-03-21T14:39:29Z

Fixed issues and squashed commits. There was a problem with the lint script, I'll push a fix in the openbsd-compat branch. I'll also commit the indentation changes separately in master.

timabbott · 2016-03-22T04:48:49Z

zerver/models.py

@@ -214,8 +215,8 @@ def remote_user_to_email(remote_user):

 class RealmEmoji(models.Model):
    realm = models.ForeignKey(Realm)
-    name = models.TextField()
-    img_url = models.TextField()
+    name = models.TextField(validators=[MinLengthValidator(1), RegexValidator(regex=r'^[0-9a-zA-Z_\-\.]*$')])


Can you add a comment describing the logic behind why this is the right Regex to user here?

I will add a comment, even though I'm not sure this is the best regex. That's what we initially discussed, but I think it doesn't make much sense to allow punctuation at the end of the name and I think that would cause some issues with the requests in the frontend too (I think we don't encode the name of the emoji when deleting).

OK, probably makes sense to harden the regex then. Ideally we wouldn't accept names that are going to cause problems with the frontend (though arguably that should be fixed by encoding the name properly?).

timabbott · 2016-03-22T05:07:31Z

I took a deeper look at the implementation and posted a few comments; I also played around with the feature, and have a few thoughts on how to improve up the design (screenshot here for others following along).

We should display the existing custom emoji at a fixed size with the same dimensions ratio as what you'll get as the actual emoji (it's possible we should to show it at e.g. 2-4x magnification from how it'll appear in messages, so it's easier to see what you'll actually get?)
The spacing of the columns looks kinda funny -- if we add a fixed display size for the emoji I'd probably make the columns sit more tightly next to each other rather than having a huge space between the second and third columns.
I think it'd be good to have more of a separation from the previous section. I think the mechanism we used pre 62d021f of making a new gray block to set aside the section with e.g. "Custom emoji" as the heading and a nice icon would work pretty well.
Adding more visual offset for the "create a new one" section, similar to how the bots UI on /#settings would I think also make it more clear what's going on.

What do you think of those ideas @blablacio ?

blablacio · 2016-03-22T09:05:35Z

Added Node tests in templates.js, so build should be working now.

blablacio · 2016-03-22T11:31:41Z

You comments about the visual improvements are spot on, will make the needed changes.

blablacio · 2016-03-23T20:03:19Z

Just addressed style issues, here's a preview:

timabbott · 2016-03-23T20:06:42Z

As a quick thought, I think we should have the 3 columns of the table next to each other rather than having that huge space between "name" and "image"

blablacio · 2016-03-23T20:16:19Z

@timabbott So, basically leaving the empty space after the third column?

timabbott · 2016-03-28T05:27:50Z

Yeah. I think it might make sense to also think about making the overall widget have more of a margin on the left side (though if we do that we should do something that looks consistent with the other pages, so probably that would mean adding margin for this category of widget; looking at the other similar pages, I think it'd probably make them all look better)...

timabbott · 2016-03-28T05:28:03Z

(And sorry for the slow reply! Last week was very busy)

timabbott · 2016-03-28T05:30:36Z

static/styles/zulip.css

+.admin_emoji_table th.image {width: 80px;}
+
+.emoji_image {width: 50px; display: block;}
+.emoji_image img {max-width: 100%;}


I think stylistically our CSS always has a newline after the {, so probably should do that here too for consistency.

timabbott · 2016-04-20T19:02:04Z

@blablacio it'd be great if you could focus on getting this one finished, since I think it's almost done!

blablacio · 2016-04-26T17:59:16Z

Sorry for the late response, last couple of weeks were really busy. All issues have been addressed and code rebased, you can take a look at the emoji table and let me know if I should wrap the tables on other admin tabs similarly.

timabbott · 2016-04-26T18:11:29Z

Cool, thanks @blablacio! The new changes are definitely an improvement, and I think the new admin page form looks pretty good.

I noticed this issue while playing with this:

If one adds a realm emoji with a capital letter in the name (e.g. "Cowboy"), I can't get the new realm emoji to show up in the autocomplete in the compose box, even after reloading -- I'm not sure what the issue is there but it seems worth debugging. Seems likely to have been a preexisting bug.

timabbott · 2016-04-26T18:12:41Z

static/js/admin.js

+                        $("<p>").addClass("text-error").text($.parseJSON(xhr.responseText).msg)
+                    );
+                } else {
+                     btn.text("Failed!");


Would it make sense for this to use Zulip's standard ui.report_error mechanism?

It would probably make sense, but I think this is the "canonical" way to do it (at least looking at admin.js). It sounds reasonable to me as we denote the table row within which the error occurs. I could change it if you think it makes sense, but I guess it would be a good idea to change the other few occurrences of this pattern in admin.js too.

Hmm, so it is. We should probably switch these but maybe makes sense to do in a separate commit / PR -- doesn't seem super important. Can you open an issue and label it with "refactoring"?

Sure, will do.

timabbott · 2016-04-26T18:19:44Z

Oh one more note on the Emoji creation form: we should probably give a wider text box for the URL field since many URLs will probably not fit there.

blablacio · 2016-04-26T18:20:14Z

Okay, I'll investigate what is the case with the capital letters in the name and address the other issues you've pointed.

blablacio · 2016-04-26T18:38:19Z

Okay, so here's the deal with the capital letters: in composebox_typeahead.js we have query_matches_emoji function that converts input to lower case like this return (emoji.emoji_name.indexOf(query.toLowerCase()) !== -1);

If I remove the toLowerCase() call, it works as expected, but I'm not sure if that's going to break anything. Any ideas about the purpose of converting to lower case?

timabbott · 2016-04-26T18:40:25Z

My guess is that code's purpose is to make emoji names case-insensitive, which is probably a pretty reasonable way for them to work. Maybe try making it emoji.emoji_name.toLowerCase().indexOf(query.toLowerCase()) ?

blablacio · 2016-04-26T18:41:45Z

Yep, that would make sense. Will change it as suggested and run tests.

blablacio · 2016-04-26T19:19:56Z

I fixed all the stuff, but would like you to okay the width change of the URL field as I had to tweak the whole form a bit (otherwise the label would stick on one row and the input on the next one). Attaching a preview here:

timabbott · 2016-04-26T19:21:27Z

Yeah that seems reasonable

blablacio · 2016-04-26T19:31:52Z

All done, I unified the regexes in models and urls too.

timabbott · 2016-04-26T19:44:33Z

Great! Looks like there are some issues with narrow screens; I think it's reasonable for the text box to shrink in that case but probably not great for it to stick out over the border area.

Oh, one more thing -- ideally, the Zulip tests would work without Internet access, so maybe the example image URL used in the tests should be something included in the Zulip distribution (e.g. a "jenkins" emoji that points to /static/images/integrations/logos/jenkins.png).

blablacio · 2016-04-26T19:48:43Z

Okay, I'll set the input width in percents, so it shrinks with the screen size. I'll also look into making tests run without an internet connection.

API call to delete_emoji removed as realm emoji are already populated in page_params. Realm emoji name validation regex changed to disallow names ending with punctuation. do_add_realm_emoji renamed to check_add_realm_emoji. Fix a problem with capital letters in emoji names. Make tests run with locally hosted images. Tweaking emoji table style.

blablacio · 2016-04-26T20:06:44Z

Done.

timabbott · 2016-04-26T20:09:50Z

Probably should rename MouseFace to jenkins in the test?

timabbott · 2016-04-26T20:12:08Z

Otherwise lgtm, I'll just fix that and merge. Thanks @blablacio!

timabbott · 2016-04-26T20:18:08Z

I split out f5fe2d4 into its own commit, since it's in some ways an unrelated bug fix, and then merged this. Thanks @blablacio!

timabbott reviewed Mar 18, 2016
View reviewed changes

blablacio force-pushed the custom-realm-emoji branch 3 times, most recently from 6ef4a2b to 310c0f5 Compare March 21, 2016 14:37

blablacio force-pushed the custom-realm-emoji branch from 8116987 to e4e563d Compare March 21, 2016 22:59

timabbott reviewed Mar 22, 2016
View reviewed changes

blablacio force-pushed the custom-realm-emoji branch from e4e563d to 2249ba3 Compare March 22, 2016 09:02

timabbott reviewed Mar 28, 2016
View reviewed changes

timabbott force-pushed the master branch from 9846caa to 35b0af2 Compare April 22, 2016 00:55

Add custom realm emoji feature to admin

bc6b89e

Fix style issues

1781010

blablacio force-pushed the custom-realm-emoji branch from 14ad252 to 524f188 Compare April 26, 2016 17:56

timabbott reviewed Apr 26, 2016
View reviewed changes

blablacio force-pushed the custom-realm-emoji branch from 524f188 to 233bc73 Compare April 26, 2016 19:30

blablacio force-pushed the custom-realm-emoji branch from 233bc73 to c2233e1 Compare April 26, 2016 19:43

blablacio force-pushed the custom-realm-emoji branch from c2233e1 to d3e35ea Compare April 26, 2016 20:05

timabbott closed this Apr 26, 2016

timabbott added this to the 2016 roadmap milestone Apr 29, 2016

Custom realm emoji #543

Custom realm emoji #543

Conversation

blablacio commented Mar 17, 2016

smarx commented Mar 17, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timabbott commented Mar 18, 2016

blablacio commented Mar 21, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timabbott commented Mar 22, 2016

blablacio commented Mar 22, 2016

blablacio commented Mar 22, 2016

blablacio commented Mar 23, 2016

timabbott commented Mar 23, 2016 via email

blablacio commented Mar 23, 2016

timabbott commented Mar 28, 2016

timabbott commented Mar 28, 2016

Choose a reason for hiding this comment

timabbott commented Apr 20, 2016

blablacio commented Apr 26, 2016

timabbott commented Apr 26, 2016

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

timabbott commented Apr 26, 2016

blablacio commented Apr 26, 2016

blablacio commented Apr 26, 2016

timabbott commented Apr 26, 2016

blablacio commented Apr 26, 2016

blablacio commented Apr 26, 2016

timabbott commented Apr 26, 2016

blablacio commented Apr 26, 2016

timabbott commented Apr 26, 2016

blablacio commented Apr 26, 2016

blablacio commented Apr 26, 2016

timabbott commented Apr 26, 2016

timabbott commented Apr 26, 2016

timabbott commented Apr 26, 2016