Skip to content
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

[WIP] threads review/adjustments #572

Closed
wants to merge 90 commits into from

Conversation

ggazzo
Copy link

@ggazzo ggazzo commented Feb 13, 2019

I have opened that PR to show/share the modifications I made to be able to merge on rocketchat core (:

Copy link
Member

@mrsimpson mrsimpson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ggazzo Great! I don't fully understand why you removed the entry-options or how you're going to replace them, but of course: Feel free to merge it.

@@ -226,7 +226,6 @@ rocketchat:slackbridge@0.0.1
rocketchat:slashcommands-archive@0.0.1
rocketchat:slashcommands-asciiarts@0.0.1
rocketchat:slashcommands-create@0.0.1
rocketchat:slashcommands-create-thread@0.0.1
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you not like the slash command? I use it frequently myself

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will reinsert :)

});
});
Tracker.autorun(() => {
if (RocketChat.settings.get('Thread_from_context_menu') !== 'button') {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

much better... Kind-of-ashamed...

@@ -2,9 +2,6 @@
<aside class="sidebar sidebar--{{sidebarViewMode}} {{#if sidebarHideAvatar}}sidebar--hide-avatar{{/if}}" role="navigation">
{{> sidebarHeader }}
{{#if loggedInUser}}
{{#if threadingFromSidebar}}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I absolutely understand you didn't like that button - I don't like it either. But: Is there a replacement for that? I believe there should be an option to start a thread without opening the room first.

@@ -68,10 +64,6 @@ Template.sideNav.events({
'dropped .sidebar'(e) {
return e.preventDefault();
},

'click .js-create-thread'() {
return FlowRouter.go('create-thread');
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you left the route, as far as I can see. 👍

@ggazzo
Copy link
Author

ggazzo commented Feb 19, 2019

@mrsimpson I'm afraid I didnt finish yet, I realize I removed your "cloud tags", actually I couldnt open/find on https://threads-qa.rocket.chat...

I had to change some "internal things(popover/modal)" to fit the forms inside popups... and some "props names" we are trying to "normalize"... there are some bugs I didnt fix yet(remove parent thread), but I will :)...

@mrsimpson
Copy link
Member

@mrsimpson I'm afraid I didnt finish yet,

Of course - there's a lot to do if you want to catch all the details. I "approved" it just to signal "if you want to, just merge it any time. Since you are a maintainer, I'll (have to) accept it anyway ;) "

I realize I removed your "cloud tags", actually I couldnt open/find on https://threads-qa.rocket.chat...

Ah, yes. We tried a word cloud for selecting the parent channel. However, this didn't work out as we wanted to, so we thought a normal autocomplete should do as well. I have hidden it from the UI (might be only a display: none), but it's not a big loss if you deleted the wordcloud.

I had to change some "internal things(popover/modal)" to fit the forms inside popups... and some "props names" we are trying to "normalize"

I still think that the DB should be responsible for compression and thus preferred parentRoomId instead of prid (see here and particularly here ), but well - most of the DB prop names are cryptical as well...

there are some bugs I didnt fix yet(remove parent thread), but I will :)...

Cascading delete might be hard to understand in the context of heavy threading, since the rooms are only very loosely coupled. What about an option to keep the threads or at least a warning when deleting a room with threads?

In general, it sounds as if you do have a plan - which is good ;)
Have you seen my open questions in RocketChat#11803 (comment) ?

Copy link
Member

@mrsimpson mrsimpson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ggazzo I had a look at your re-write enhancements ;)

All looks excellent. I voiced doubts where I have them, just for your consideration.

},
condition({ rid, u: { _id: uid } }) {
condition({ rid, u: { _id: uid }, attachments }) {
if (attachments && attachments[0].fields && attachments[0].fields[0].type === 'messageCounter') {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cascading question:
Is this you validation for ensuring the parent room is not a "thread started" message?
If so: Do you want to revert this being a system message?
If so: You'll be able to (and need) to handle the events like updating or deleting the origin message.

this.threadSubscriptions.set(ChatSubscription.find(query, { sort }).fetch());
});
query.prid = { $exists: true };
return ChatSubscription.find(query, { sort });
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There was a reason why I opted for an own reactive collection - if only I knew what it was, long time ago... Anyway, this is comparatively easy to test

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

let me know if you remember why you choose that way :)

this._parentRoom = ThreadBuilder.getRoom(this._parentRoomId);
this.rocketCatUser = RocketChat.models.Users.findOneByUsername('rocket.cat');
}
// export class ThreadBuilder {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Feel free to delete this.
We've had quite some evolution on this and various types of threads which is why we implemented a factory.
With the current functionality, this is definitely over-engineered.

const name = getName({ t_name, p_name: p_room.name, message: message.msg });

const thread = RocketChat.createRoom(t_type, name, user.username, users, false, {
description: message.msg, // TODO threads remove
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ggazzo agreed we should not utilize another field for this. What's important: The initial question needs to visualized in the thread even when scrolling. with a custom header, this should be manageable though.

import { Template } from 'meteor/templating';
let oldRoute = '';
const parent = document.querySelector('.main-content');
// import { Blaze } from 'meteor/blaze';
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you going to remove this completely?

RocketChat.models.Messages.removeFilesByRoomId(rid);
RocketChat.models.Messages.removeByRoomId(rid);
RocketChat.models.Subscriptions.removeByRoomId(rid);
RocketChat.callbacks.run('afterDeleteRoom', rid);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if one thread cannot be deleted (e. g. since the owner has changed)? May this result in a situation where you cannot delete the parent room while having it deleted for the biggest part?
You wouldn't even see the parent room anymore if this fails since the subscription will be gone.
What about triggering afterDeleteRoom as first step in the chain?

}

addRoomAccessValidator(function(room, user) {
return room.prid && canAccessRoom(Rooms.findOne(room.prid), user);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, nice. I thought about this too. This makes it optional to invite users to the thread, which was a major flaw in the current implementation.

However, we got feedback that some users shall be able to join a thread while not being able to see the parent. Is this possible?

ggazzo and others added 16 commits February 20, 2019 15:29
* Move mongo config away from cors package

* Remove TLS fix
… login via email/crowd_username (#12981)

* Fix to close issue #12979

- Enable custom rocketchat usernames for crowd users
- Enable login via rocketchat username, crowd_username and email address
- Don't authenticate local users against crowd
- Allow/Disallow resyncing/overwride of local usernames with crowd usernames in crowd options
- Consistent user sync on login and on cron sync

* Fix to close issue #12979

Integrate PR suggestions/improvements

* Change mongodb queries

* Access settings directly via imported settings object
@ThomasRoehl
Copy link

comes with RC 1.0

@engelgabriel engelgabriel deleted the threads branch April 7, 2019 00:58
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

Successfully merging this pull request may close these issues.