beat.web issues
https://gitlab.idiap.ch/beat/beat.web/-/issues
2017-09-28T08:43:21Z
https://gitlab.idiap.ch/beat/beat.web/-/issues/476
C++ environment has no documentation
2017-09-28T08:43:21Z
André Anjos
C++ environment has no documentation
The current version of the C++ environment at the production platform has no associated documentation.
We should explain there what it is and maybe have links to the different software toolkits and instructions on how to produce a binar...
The current version of the C++ environment at the production platform has no associated documentation.
We should explain there what it is and maybe have links to the different software toolkits and instructions on how to produce a binary that is compatible with it.
Philip ABBET
Philip ABBET
https://gitlab.idiap.ch/beat/beat.web/-/issues/455
Documentation/comments of the frontend
2017-08-06T16:44:51Z
Jaden DIEFENBAUGH
Documentation/comments of the frontend
There is basically no documentation (either in-line or in separate documents) of the nearly **20,000LOC** of JS.
This leads to developers having to go as far as reverse-engineering the application whenever they are not familiar with a c...
There is basically no documentation (either in-line or in separate documents) of the nearly **20,000LOC** of JS.
This leads to developers having to go as far as reverse-engineering the application whenever they are not familiar with a certain piece of functionality, which increases the overhead of starting work on new code and slows onboarding new developers.
https://gitlab.idiap.ch/beat/beat.web/-/issues/306
Sharing behaviour
2019-07-04T08:37:02Z
André Anjos
Sharing behaviour
As per discussion at today's meeting, we decided to open a ticket to:
1. Define what is/should be the sharing behavior on the platform
2. Assert the tests we have are catching errors on this
3. See if there would be any way we could...
As per discussion at today's meeting, we decided to open a ticket to:
1. Define what is/should be the sharing behavior on the platform
2. Assert the tests we have are catching errors on this
3. See if there would be any way we could simplify the logic as to make the check faster and more
programatically evident
### Current situation
As indicated by our discussion, here is what I understood:
1. The permissions are organized in levels (from the most private to the least): `Private`, `Usable`, `Shared`, `Public`.
2. If the object is `Public`, then any user can view the object. Logged in users can use them in experiments. The contents of the 4 lists of users and teams (`shared_with`, `shared_with_team`, `usable_by` and `usable_by_team`) are ignored.
3. If the object is `Private` the lists are also ignored. Only the user, when logged in, can view and use the object in question.
4. If the object is `Usable` the lists for `usable_by` and `usable_by_team` are looked up. If they are empty, then the object is **usable** by all users and all teams available in the platform. If the lists are not empty, they implement a restriction saying "only" those have the `Usable` permission. Combinations of empty/having contents on any of those lists should be supported.
5. If the object is `Shared`, the lists of `shared_with` and `shared_with_team` are looked up in the same fashion as for `Usable`. The only exception here is that an object may be shared with some users/teams and usable other users/teams. So, if the object is `Shared`, authorization should look-up for viewing using the `shared_with` and `shared_with_team` attributes whereas for using only, with the `usable_by` and `usable_by_team` attributes. If these lists are empty, here is the expected behavior:
1. If `shared_with` and `shared_with_team` are empty, then the object is shared with everyone.
In this case, it should be made `Public` instead. I.e., there shouldn't be any case where
an object has a `Shared` permission with empty `shared_with*` attributes.
2. If `usable_by*` attributes are empty, then everybody on the platform will be able to use the
contribution. (Comment: so, basically, if we want to share an algorithm we have to copy-n-paste the user list from `shared_with*` to `usable_by*`?)
6. Sharing is an irreversible procedure (`+=`)
### Impossible states:
1. Object is `Shared` but `shared_with*` attributes are empty
2. Object is `Private` but `shared_with*` or `usable_by*` attributes are non-empty
3. Object is `Public` but `shared_with*` or `usable_by*` attributes are non-empty
4. Object is `Usable` but `shared_with*` attributes are non-empty
### Requirements
From the above state, I tried to extract the requirements:
1. Objects start their life time on the platform as `Private`. Only the author has view/use access on it.
2. It must be possible to make an object (algorithm, library, plotter and database) `Usable`, meaning users/teams in a list can use it (not view it).
3. It must be possible to make an object (algorithm, library, plotter and database) `Usable` to all users of the platform.
4. It must be possible to make an object `Shared`, meaning users/teams in a list can use **and view the said object**. Note that "sharing" with all is the same as making it `Public`.
5. If an object is `Shared`, the author may optionally decide if it is still `Usable` by other users and teams. In this case, the platform should restrict the access accordingly.
6. Sharing shall be reversible, for as long as the object in question is not being used by anyone (`deletable()` answers `True`). This is, effectively, the same as forking, deleting the existing object and renaming the new object to the old name, which should certainly be possible for as long as nobody is using it. If the object is being used, then the sharing permissions cannot be lowered, only raised. I.e., if the object is `Usable`, it can always be made `Shared` with the same or more users. If the object is `Shared`, it can always be made public. In summary, the currently implemented `+=` rule applies.
Does that look reasonable?