Add dashboard content
|Assignee:||Sarah Stoffels||% Done:|
|Category:||-||Estimated time:||1.00 h|
|Target version:||Repertoire 1) Testing phase I||Spent time:||34.50 h|
- dummy intro text
- dummy intro picture
- important objects
- content with errors
- orphaned content (unassinged to a creation)
- uncommited metadata objects
#6 Updated by Alexander Blum over 3 years ago
- Description updated (diff)
change of 'duplicates' to more general 'rejected' content (name not defined yet, should be short and easily understandable). content might have numerous rejection reasons (dupliacte, quality, ...), wich all have the same workflow (deletion after ~7 days, user should be able to stop deletion by starting a dispute).
new widget "orphaned content" (name also not defined yet), which is important for the user to track the "todos". Content objects without a relation don't have any purpose in our system.
#7 Updated by Alexander Blum over 3 years ago
I replaced Content.user with the entity creation workflow (entity_origin, entity_creator). Further I changed the entity_creator foreign table to party.party instead of res.user. This might brake your code. For the changes, see
#9 Updated by Alexander Blum over 3 years ago
One need to be cautious with putting objects within the registry, as deepcopies are made to merge the tree of registry nodes into the final registry. If instances of classes with complex things in it (like the whole request or references to tryton models) need to be put into the registry, there's a possibility to define a function deepcopy within the class, which is called on a deepcopy and should return the new object.
By saving the whole request into an object put into the registry, a recursion is triggered, as request.context contains the registry again, which includes the object containing the registry, ect.
For now, I defined a new request method (request.party) to easily retrieve the current party from any request and saved only the request.party.id within the instance, circumventing the problem.