Any side effects to using custom topic archetypes?

Dev
1

For a project I am working on, I am storing data as topics with their own special archetype. They’re not really topics, the category and body don’t matter and the important information is held in custom fields. I went with this design to avoid dealing with database migrations and the like. This is a private plugin that won’t be disabled except during A/B testing. Are there side effects to this? Am I doing it completely wrong?

2

Is your code open source? At the very least some actual code examples would go a long way here.

If the code works you’re probably not doing it terribly wrong :wink:

3 Likes
3

I can’t make the code open source right now for legal reasons, sorry…(the code isn’t on any public facing site right now either).

As for code examples, there’s not much to show. I Archetype.register in an initializer, then use the following:

TopicQuery.results_filter_callbacks << Proc.new do |_, result, user|
	result.where.not(archetype: 'the_archetype')
end

I then have the following guardian (with a TODO to fix the DRY):

	module FoobarGuardian
		def can_edit_topic?(topic)
			topic.archetype != 'the_archetype' && super
		end

		def can_create_post_on_topic?(topic)
			topic.archetype != 'the_archetype' && super
		end
	
		def can_create_post_on_topic?(topic)
			topic.archetype != 'the_archetype' && super
		end

		def can_see_topic?(topic)
			topic.archetype != 'the_archetype' && super
		end
	end

	require_dependency 'guardian/topic_guardian'
	::TopicGuardian.prepend FoobarGuardian
4

I’d be hesitant to create a new archetype value for that field. I’d be concerned that it might break code that was written with the assumption there would be only certain possible values. eg.

where topic archetype not equal to private message

Might it not be better to work with topic custom fields?

1 Like
5

I was concerned about this as well, but built into Discourse is another archetype (I don’t remember, but I think it’s banner?) so this shouldn’t be the case. Everything I read uses .private_message? anyhow, which may be making these assumptions I don’t want, though.

I do use custom topic fields, but these aren’t normal topics and shouldn’t be able to be accessed as such.

6

I just looked at this code. The word “default” suggests it should be OK to create non-default values
https://github.com/discourse/discourse/blob/master/lib/archetype.rb#L40-L45

1 Like
7

I understand that, I’ve seen other plugins use it to create pseudo-topics, I’m just wondering if there’s any side effects to it that I should be aware of (e.g. that they show up in the topics list and I have to manually filter that out).

8

I think that will depend on how the conditionals are written. There is a not always so obvious difference between “is regular” and “is not private message”.

I’m assuming that Core Discourse code is written correctly. What would be more a possible problem is third party code.

1 Like
9

The only case I know if where a custom archetype has been used is Babble, and I know that has taken a LOT of development and maintenance work over the years.

If they’re not really topics, maybe you would be better off with using the PluginStore system. As @erlend_sh said it’s very hard to give advice if we don’t know what you’re trying to achieve.

3 Likes