View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 5118 | Composr alpha bug reports | General / Uncategorised | public | 2022-12-02 19:47 | 2025-02-13 02:09 |
| Reporter | PDStig | Assigned To | Chris Graham | ||
| Priority | normal | Severity | trivial | ||
| Status | resolved | Resolution | fixed | ||
| Summary | 5118: Privacy policy: last modified considerations | ||||
| Description | We need to consider the "last revised" date on the Privacy Policy page. Currently, it pulls from either the modified or created metadata, but this only tracks manual edits to the privacy page. However, by default, the privacy page uses the auto-generating main_privacy_policy_auto block to create a privacy policy. If the information in this block changes, realistically the revised date should also change. But we should maintain the ability for the revised date to also change if the page is manually edited. | ||||
| Additional Information | Perhaps: a) When main_privacy_policy_auto is generated, hash all its data and store in a database value. b) If the hash changes, update the hash in the database and update the modified metadata for whichever Comcode page is using the block. Another idea (since the above could get tricky messing with Comcode page meta)... since we can reasonably assume main_privacy_policy_auto will never contain more than one privacy policy (it does not use a param): a) When main_privacy_policy_auto is generated, hash all its data and store in a database value. b) If the hash changes, update the hash in the database and also maintain a revised timestamp for the block c) Create a new Tempcode symbol that outputs either the Comcode page creation date, the Comcode page modified date, or the main_privacy_policy_auto modified date... whichever is most recent. Use this on the default Privacy Policy page. | ||||
| Tags | No tags attached. | ||||
| Attach Tags | |||||
| Sponsorship open | |||||
|
|
Second idea makes sense. |
|
|
v11 beta7: Original hashing did not work because it considered whole Tempcode objects, which have unique IDs, resulting in the time always updating. I fixed this; the hash is generated from evaluated Tempcode now. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2022-12-02 19:47 | PDStig | New Issue | |
| 2022-12-02 19:47 | PDStig | Status | Not Assigned => Assigned |
| 2022-12-02 19:47 | PDStig | Assigned To | => Chris Graham |
| 2022-12-02 19:51 | PDStig | Relationship added | parent of 5119 |
| 2022-12-02 19:52 | PDStig | Relationship deleted | parent of 5119 |
| 2022-12-02 19:52 | PDStig | Relationship added | related to 5119 |
| 2022-12-02 21:11 | Chris Graham | Note Added: 0007768 | |
| 2022-12-02 22:16 | Chris Graham | Status | Assigned => Resolved |
| 2022-12-02 22:16 | Chris Graham | Resolution | open => fixed |
| 2023-02-26 18:29 | Chris Graham | Category | General => General / Uncategorised |
| 2025-02-13 02:09 | PDStig | Note Added: 0009806 |
