Add new table ce_discovery_promotions
Closed, InvalidPublic
Actions

Assigned To

None

Authored By

	cmelo
	Tue, Apr 14, 5:39 PM

Description

NOTE: Remove sections that are not needed. Instead, leave the section and write NOT NEEDED as its content.

Background: The event discovery feature needs to track which users have been shown a promotion for a given event, to avoid showing the same promotion repeatedly. We are going to use mainstache to store this date as needed.

Type of story

Backend

Acceptance criteria

TDB

Testing required?

Yes
Minimum testing to pass QA: The table schema is verified end-to-end by the frontend task that exercises the discovery promotion flow.
Tested end-to-end in: task-14 (EventDiscoveryDialog)

Technical details

Split patches suggestion

Gherkin scenarios

NOTE: This are all drafts and we will refine them

Related Objects
Search...

		Status	Subtype	Assigned	Task
		Open		None	T412860 [EPIC] Worklists for collaboration tracking and event discovery MVP
		Invalid		None	T423322 Add new table ce_discovery_promotions

Event Timeline

cmelo created this task.Tue, Apr 14, 5:39 PM

cmelo mentioned this in T423334: Implement mainstash storage to store event promotions.Tue, Apr 14, 7:51 PM

Have alternative storage solutions been considered? It looks like none of this was discussed in advance. Given that the data is non-critical, and also bound to expire, and a general argument in favour of simplifying the storage layout, I would consider other storage solutions before the database; at least mainstash or user preferences. Session storage might be interesting too, but that's more short-lived and probably not what we want.

cmelo updated the task description. (Show Details)Thu, Apr 16, 8:23 AM

Prototyperspective unsubscribed.Thu, Apr 16, 10:11 AM

cmelo updated the task description. (Show Details)Thu, Apr 16, 5:03 PM

cmelo updated the task description. (Show Details)Thu, Apr 16, 5:07 PM

In T423322#11826932, @Daimona wrote:

Have alternative storage solutions been considered? It looks like none of this was discussed in advance. Given that the data is non-critical, and also bound to expire, and a general argument in favour of simplifying the storage layout, I would consider other storage solutions before the database; at least mainstash or user preferences. Session storage might be interesting too, but that's more short-lived and probably not what we want.

Great, thanks mainstash sounds a good option, let's go with it, I will update the AC.

cmelo closed this task as Invalid.Thu, Apr 23, 1:36 PM

Add new table ce_discovery_promotionsClosed, InvalidPublicActions